HAL Id: hal-01292300https://hal-enac.archives-ouvertes.fr/hal-01292300

Submitted on 22 Mar 2016

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Joint model-driven design and real experiment-basedvalidation for a secure UAV ad hoc network routing

protocolJean-Aimé Maxa, Mohamed-Slim Ben Mahmoud, Nicolas Larrieu

To cite this version:Jean-Aimé Maxa, Mohamed-Slim Ben Mahmoud, Nicolas Larrieu. Joint model-driven design andreal experiment-based validation for a secure UAV ad hoc network routing protocol. ICNS 2016,2016 Integrated Communications Navigation and Surveillance Conference, AIAA/IEEE, Apr 2016,Herndon, United States. pp 1E2-1 - 1E2-16 /, �10.1109/ICNSURV.2016.7486324�. �hal-01292300�

JOINT MODEL-DRIVEN DESIGN AND REAL EXPERIMENT-BASEDVALIDATION FOR A SECURE UAV AD HOC NETWORK ROUTING

PROTOCOL

Jean-Aimé Maxa1 2 , Mohamed Slim Ben Mahmoud1 and Nicolas Larrieu1

1 ENAC, TELECOM/Resco, F-31055 Toulouse, France2 Univ de Toulouse, F-31400 Toulouse, France

AbstractUAV Ad hoc Network (UAANET) is a wireless

ad hoc network composed of Unmanned Aerial Ve-hicles (UAVs) and Ground Control Station (GCS).Compared to the standard Mobile Ad hoc NETworks(MANETs), the UAANET architecture has somespecific features that brings exciting challenges tocommunication architecture design. One of them isthe design challenge of a UAANET routing protocols.It must find an accurate and reliable route betweennodes in a timely manner to exchange data traffics.It must also be secured to preserve efficiency in thepresence of malicious attackers and provides dataintegrity and authentication.

Furthermore, UAANETs must be certified inthe near future to act as autonomous systems with-out a dedicated safety pilot and to be authorizedto fly in the national airspace. In such a context,in this paper, we contribute to the certification ofthe secure UAANET communication system softwareusing a Model-Driven Development (MDD) approachand real experiments based validation. The validationprocess followed uses sequentially formal verificationmethods and real-world experimental results. Theobjective is to evaluate the routing protocol efficiencyto a set of unexpected hazardous issues that come withthe real environment.

IntroductionUAVs investigations began after the first world

war with preliminary prototypes. Since then, techno-logical and research advances in embedded systemshelp to produce small UAVs with highly effectivecapacities. A small UAV is a pilot-less aerial vehiclethat has a set of micro electromechanical systems. Itcan be controlled either autonomously by on-boardcomputers or remotely controlled by a distant op-

erator. When several UAVs are communicating witheach other via wireless links, they dynamically forma temporary multi-hop radio network called UAV Adhoc NETwork (UAANET). Compared to the standardMobile Ad hoc Network (MANETs), UAANETs havesome specific features (3D mobility model, low nodedensity, intermittent network connectivity) that bringsinteresting challenges to the communication architec-ture design. Indeed, in order to achieve UAANETmissions (for instance surveillance and reconnais-sance [1]), UAVs must relay network and payloadpackets between them to the Ground Control Sta-tion(GCS). Since the existing routing protocols de-signed for MANETs fail in tracking network topologychanges [2], adapted routing protocols are requiredto establish an accurate and reliable route betweennodes.

Furthermore, the routing protocol also needs tobe secured as it relay critical data traffics ( com-mand/control (c2) traffics, payload 1 traffic and therouting protocol traffic). This is because, in a wire-less ad-hoc environment in which there is no fixedinfrastructure, the wireless links are prone to linkattacks, which consist of passive eavesdropping andactive interfering. As a result, routing control packetneeds to be authenticated to verify both the identityof the message originator and the message integrityto avoid data tampering and modification.

Likewise, UAANETs applications offers a largepossible civil and public domain applications in whichone or several UAVs may be deployed [3]. One ofthe obstacle that stands for its deployments lies oncertification restrictions. Indeed, UAANETs must becertified to act as autonomous systems without a

1In order to avoid misunderstanding, note that the payload froman UAS point of view is quite different from the network payloadtraffic, which is the amount of additional data required by trafficcontrol.

dedicated safety pilot or to be simply authorized to flyin the general airspace. On a regional French scale,such a system needs to be fully compliant with theDGAC2 regulations.

In such a context, the UAANET communicationsystem must satisfy both UAANET network (routingand security) and validation requirements. Accord-ingly, in this paper, we provide a case study ofdesigning a secure UAV Ad hoc routing protocolapplying Model Driven Development (MDD). Ourobjective is twofold: on the one hand, to minimizecertification and evaluation efforts by providing a for-mal verification capability which ensures quality andconformance of the routing protocol, and on the otherhand, to validate the efficiency of the routing pro-tocol through real UAANET test experiments. Thisvalidation process is complementary of the formalvalidation step in order to assess how our softwaresolution behave in real outdoor experiments. It shouldbe noted that this paper is part of the Secure UAV Adhoc Network ( SUANET ) project presented in [4].

The paper is organized as follows. In section2, we describe the UAANET communication archi-tecture, routing and security requirements. Section 3highlights the current UAS certification state of theart. The model driven design of our secure UAANETrouting protocol will be detailed in section 4. Then,we will describe in section 5 and section 6, thereal-word experiments validation and performanceevaluations of our routing protocol. Finally, in Section7, we provide our conclusions and an overview of ourfuture research perspectives.

UAANET communication architectureIn [5], survey of communication networks of

small UAVs are presented. The authors characterizedifferent network architectures: direct communica-tion, cellular and ad hoc networking. Direct commu-nication scheme and cellular networks have severalflaws. They require a certain amount of bandwidthfor each UAV to support a high node density in thenetwork. Specifically in the direct-link architecture,UAV-to-UAV communications are not possible as datatraffic must be routed to the GCS. In regards tothe cellular architecture, the existing mobile phone

2DGAC: "Direction Générale de l’Aviation Civile" which isequivalent to the American FAA (Federal Aviation Administra-tion)

infrastructure is not intended for air-to-ground com-munication. Since a single UAS transmitter can sweepa wide area with its signal, a UAS deploymentsmay need a dedicated cellular infrastructure. But, theexpensive implementation of these base stations is afinancial handicap.

In order to address the weaknesses of thecommunication architectures discussed above, aUAANET can be used for UAV swarm (depicted inFigure 1) in which UAVs and GCS are communicat-ing between each other without the need for a fixedinfrastructure. Compared to other communication net-works cited above, UAANETs have several advan-tages. The scalability is ensured thanks to the fastmobility of UAVs to cover a vast area rapidly. Also,the reliability is improved because the failure of oneUAV does not affect the whole network. As regardsthe bandwidth, it can be reused more often and thusmore efficiently due to the multi-hop communication.From a security viewpoint, the absence of a centralnode within the network decreases the risk of attackon a single point of failure. Each end system (UAVSand the GCS) is responsible for the network integrityand authentication.

These features make UAANET the most appro-priate solution for UAVs communication. However, itraises a challenging networking problem.

Routing Protocol Challenges in UAANETSeveral dynamic routing mechanisms are avail-

able for UAANETs [6]. Topology-based mechanisms,such as proactive, reactive and hybrid routing are thebasis of numerous protocols. Nonetheless geographi-cal routing could also be efficient in specific contexts.

In [7], we introduced an emulation-based perfor-mance evaluation of MANETs routing protocols forUAANETs. This realistic study considers the Linuxkernel networking stack requirements, the protocolimplementations, background traffics, real time exe-cution features and a realistic mobility model. Theexperimental results showed that AODV [8] routingprotocol suits better in UAANET compared to OLSR[9] and DSR [10]. As AODV being the protocolthe most reactive to topology changes and havinga limited overhead, we concluded that AODV wasthe most suitable routing protocol for our scenario.As several studies proved that AODV can be out-performed by proactive protocols with a large num-

Figure 1. UAANET Architecture

ber of nodes, its on-demand mechanism allows afaster response during UAANETs disconnection. Ourmobility pattern and our emulation system certainlyaffected the measures, but we found similar resultsto those exposed in [11]. Accordingly, in [12], weintroduce the model design of SUAP (Secure UavAd hoc routing Protocol) which is a secure UAANETrouting protocol based on AODV.

Security Challenges in UAANET

The ultimate objective of a routing protocol isto find an accurate and reliable route while assumingthat nodes in the network are friendly and cooperative.However, such assumption might not always be trueas UAANET use an unprotected wireless medium andlack of fixed infrastructure to separate inside nodesfrom the outside (the attackers). Also, because of thecritical level of c2 traffic exchanged, its security mustbe insured at all cost. Note that there can be differentmotivations for attackers to breach UAANET. Forinstance, an attacker may attempt to take control ofUAVs by capturing the control and command traffics.This can be achieved through eavesdropping andpacket forwarding attacks [13].

Generally, securing UAANET is a challengingtask due to its cooperativeness characteristic and itsuncontrollable environment. Unlike wired networkswhere attackers need to gain access to the physicalmedium to execute any types of attacks, in UAANET,an intruder can easily eavesdrop the exchanged trafficthrough the unprotected wireless links. From ourbest knowledge, only few secure UAANET routingprotocol [4] has been proposed. It can be either anew routing protocol that is designed from scratch

with the security as one of its goals or a secureextension of an existing routing protocol. The latterapproach is the most used one as it uses a routingprotocol like AODV, DSR and OLSR, considered bythe IETF MANET group for standardization. Thus,securing those routing protocols requires assessingattacks specific to that protocol and securing themaccordingly. This latter approach is used in this paperto create the SUAP routing protocol.

UAS Certification ChallengesTo apply for a certificate, UAS is divided into

several parts ranging from electronic components,hardware components to software components thatneed to possess an airworthiness approval [14]. Theadvantage of evaluating these components separatelyis two fold: first, it allows the manufacturer of thedifferent UAS components (engines, propellers) todesign components that can be used in several UASdesigns. Second, it allows the UAS assembler (in ourcase Delair Tech company [15]) to be involved onlywith the certification of the system, not with eachcomponent itself. This reduces the effort needed bythe UAS designer to apply for a certificate. Note thata UAS can only be certified by the aviation authoritiesof the country where the principal place of businessof the designer is located. Accordingly, on a regionalFrench scale, our UAS communication system needsto be validated by the DGAC. Although the FrenchUAV professional civil federation3 is yet to proposea specific validation and certification standards forUAANETs, the process and safety standards depicted

3The French organization responsible for UAS certificationwithin DGAC: http://www.federation-drone.org/ certification

within the DO 178C [16] can be applicable forUAANETs [17]. DO-178 is a commercial aviationstandard used to certify aeronautical systems whosefocus lies on Model Based Development and verifi-cation supplement with formal verification methods.

Note that, Delair Tech company has previouslycertified its DT-18 UAV to fly out of sight of the GCS(i.e, the operator). However, the UAANET architec-ture induces a modification of the existing commu-nication system. As a result, a new validation andcertification process is required. Consequently, thesecure routing protocol that we are currently buildingmust be the subject of strict validation process. Weconsidered such requirements by using a qualifiedsoftware development processes using model drivendevelopment.

Model driven development of secureUAANET routing protocol

The most used current Linux implementation ofAODV (AODV-UU) is a source code that has notbeen carefully validated and certified. Also, thereis no guarantee that all the functional requirementsspecified by the IETF standards have been imple-mented. Thus, there is no conformance testing be-tween specification requirements and source code.Consequently, its direct deployment into UAANET isnot advisable as it might fail during flight operationsand cause meaningful damage. Different compliancetesting methods have been developed for distributedcommunication systems [18]. However, most of themare goal-oriented testing techniques which consist ofchoosing a specific property of the target system thatis likely to be faulty. One way to overcome this issueis to use MDD approaches that can automaticallygenerate, deploy and verify code by taking as inputsa high-level model.

MDD claims the use of models as primary ar-tifacts in the development process. A system modelcomposed of block diagrams and state charts is thefocus of the development process, from requirementspecifications to simulation testing and integration.When used with a qualified code generator, it gen-erates a high level codes which facilitate the earlyverification of the design through formal verificationtools. It also execute model-and-code consistencychecking for system verification purposes.

Design methodologyOur design is based on Matlab Simulink and

Stateflow frameworks. Simulink is composed of ablock-diagram environment which allows us to accu-rately design the routing protocol while the stateflowframeworks allow us to define a finite number ofstates in the algorithm which are changed based on adefined condition.

Figure 2 represents the model driven develop-ment workflow and schematizes the integration pro-cess. It is composed of the seven different steps.In the first step, the specification is validated andpartitioned into several subsets of the requirements.Each subset has its own unit test objectives. Then,in the second steps, each partition is designed into ahigh-level model using graphical descriptive languageprovided by Simulink and stateflow tools. To meetthe SUAP security requirements and routing features,we used both security block architectures depicted inFigure 5 and generic routing protocol architecture asshown in Figure 6. The network layer is divided intoseveral blocks exchanging messages between themand adjacent layers. Each block is designed as astate machine which analyzes incoming requests, thensends them in each iteration. The description of thesedesign architectures is detailed in the next section .

Then, during the third step, each block model isconverted into C library source code by MathworksEmbedded coder. Note that these source codes areindependent of any operating system or hardwarearchitecture. The next step (called glueing) consistsof linking the generated code to the kernel spaceof our target operating system (Embedded Linuxgenerated from OpenEmbedded). In the fifth step,the library code and glueing code are combined intobinary files. The next step consists of aggregating theprevious binary files with our target operating systemto provide a final binary image. The last step is theexecution of binary image into the target hardware forverification and validation.

Secure routing protocol design architectureThere have been several proposals to ensure the

security of AODV [19]. They provide message au-thentication and integrity by means of cryptographictechniques for route discovery and route mainte-nance packets. However, most of them are vulner-able against wormhole attacks [20]. The wormhole

Figure 2. Set of MDD Tools Used to Design ThisSecure Routing Protocol

attack involves two attackers who perform a colludingattack. One attacker record packets at a particularlocation and replay them at another attacker by usinga high-speed private network. This tunnel betweentwo colluding attackers is referred to as a worm-hole. Because of the broadcast nature of the radiochannel, attackers are able to receive data packetsnot addressed to them. Figure 3 demonstrates anexample scenario of this attack within UAANETs,where A1 and A2 are the colluding attackers whilethe GCS is the victim node. Even though, each nodeencapsulates each packet with cryptographic keys,wormhole attackers can breach UAANET securityas there is no key required to process wormhole

attacks. It should also be noted that wormhole attackis easy to execute as a commercial high-gain antennasconfigured in specific frequencies can eavesdrop thefrequency and receive the signals send by the GCSand the UAVs.

Furthermore, the following assumption is con-sidered in our network and attacker model:

• UAVs and GCS are coming from the samemanufacturer which allows us to put aside thesecurity issue from selfish nodes. Apart frombeing captured or controlled by an attacker, anode will not change its behavior and will alwayscooperate with its neighbors;

• Nodes have sufficient energy power and networkresources (i.e bandwidth) to perform crypto-graphic computation;

• All UAVs utilizes omnidirectional antennas.Communication range is r and cannot exceedDmax ( r < Dmax ). Dmax is a maximum one-hop range;

• Nodes rely on efficient symmetric and asym-metric cryptography algorithm for encryp-tion/decryption, authentication and hashing. Weenvision to use RSA algorithm for message au-thentication and SHA-256 as a hash algorithm.

• All nodes are clocks synchronized. This is possi-ble with the presence of GPS on-board of UAVsand GCS;

• We assume that there is an efficient and reliablekey management within the network to share, tomanage and to revoke node cryptographic keys;

• Routing control packet confidentiality is not in-sured. Indeed, routing packets are processed inreal time by the flying UAVs. As such, even ifan attacker is able to eavesdrop the message, itsaction is limited in passive mode because in thefuture, the past information is no longer valuable.

• Hash function H is only known by legitimatenodes and pre-loaded with keys at the bootstrap-ping;

• In regards to attackers capabilities, we considerthe work of Cordasco et al. in [21] based onDolev-Yao model in which they present a topol-ogy and protocol agnostic model that takes intoaccount a real-world scenario. Accordingly, weconsidered that the following attacks are possi-ble: data traffic disclosure, routing informationdisclosure, performance degradation and topol-

Figure 3. Illustration of Wormhole Attack in UAANETs

ogy modification.

By taking into account, those requirements, wepropose the SUAP routing protocol which is a se-curity extension of the AODV protocol, based onpublic key cryptography, hash chains and geograph-ical leashes [22]. It uses digital signatures for non-mutable fields4 and hash chains for mutable fields(i.e the hop count). A node that generates a routingmessage signs it with its private key, and the nodesthat receive the message verify the signature using thesender’s public key. The hop count cannot be signedby the sender, because it must be increased at everyhop. Therefore, a mechanism based on hash chainsis used. As such, SUAP is vulnerable against worm-hole attacks. Accordingly, a version of geographicalleashes is used to estimate the correlation between thetravelled distance and the hop count value. In order todo so, SUAP requires each node in the network to betightly synchronized and maintain a local connectivitywith its direct neighbor.

Moreover, two distinct mechanisms are usedto protect against wormhole attacks. The first oneis used for hello and route error messages. In ournetwork model, we make the assumptions that, at thebootstrapping, nodes directly send hello messages inbroadcast to reckon their directors (one hop) neigh-bors and detect link breaks. To protect these packetsfrom wormhole attacks, we use a mechanism that an-alyzes the correlation between hop count and distancetraveled by the packet. When sending messages, eachnode includes its actual location information. To pro-tect from malicious modification, message fields are

4Routing message fields that does not change throughout thenetwork. For instance, Destination IP Address, Source IP address,destination sequence number, etc.

Table I. Notation Table

Paremeter Descriptionhc Hop countDmax One hop distance maximumRij Distance between nodes i and j

d(No, A1) Distance between the first targetand the first attacker

d(A1,A2) Distance between the two attackers

d(No, A2) Distance between the first targetand the second attacker

d(A2,D) Distance between the second targetand the second attacker

Pi The amount of distance traveledby a packet at the time t

T The total distance of the legitimate route

Dw The total length of the path throughthe wormhole link

signed (including the geographical position). Figure4 illustrates the format of modified beacon messages.

To illustrate our proposition, we considered theFigure 3 and the notation in table I. The connectivitybetween two legitime nodes can be expressed by (1),with Ri, j is the current communication range.

c(i, j) ={

1 si Ri, j ≤ Dmax0 si Ri, j > Dmax

}(1)

The presence of wormhole link modify this con-dition to (2).

c(i, j) ={

1 si Ri, j ≥ Dmax1 si Ri, j > Dmax

}(2)

Figure 4. Format of SUAP Modified Hello Message

Furthermore, we have :

d(No,A1)≤ Dmax

d(A2,N3)≤ Dmax

d(No,A2)> Dmax

d(A1,N3)> Dmax

It results that.

d(No,A1)2 +d(A1,A2)2 > Dmax2

thus,d(A1,A2)> Dmax−d(No,A1)

We have (3) :

Dw = d(A1,A2)+d(No,A1)+d(A2,N3)

Dw > Dmax (3)

Knowing that

T =n

∑i=0, j=0

Ri, j

• When the node N0 send the packet, To = Ro1that corresponds to hc = x + 1 with x ∈ N;

• When the node N1 send the packet, T 1 = To+R12 that corresponds to hc = x + 2;

• When the node N2 send the packet, T 2 = T 1+R23 that corresponds to hc = x + 3;thus,

TDmax

−1≤ hc <T

Dmax+1 (4)

By taking into account the inequality (3), we cancompare the hop count value present in the packet andthe hop count value computed on the traveled distanceby following the corresponding value depicted in the

Table II. Mapping Table Between the DistanceTraveled and Hop Count

T Hop count (hc)0 < To≤ Dmax 0Dmax < T 1≤ 2Dmax 1..... .....(n−1)Dmax < Tn−1 ≤ (n+1)Dmax n-1

Table II and the formula (4). If there is a difference,the wormhole link is detected, and the packet isrejected. Otherwise, the link is considered as freeof wormhole and the signature verification processbegins. Note that because of the position informationincluded in the packet, it is possible to compute therelative distance between 2 neighbor nodes using 3DEuclidean distance.

Table III. SUAP Request Packet SignatureExtension Fields

Field ValueType 64Hash

function hash function selected by the sender node.It is used to compute the hash chain field

Signature The signature of all the non-mutable fields

Hashnew

Hashnew = H [CurrentNode, NextNode, Hashold]

CurrentNode is the address of nodesending the request packet. It can beits public key or its IP Address.The Nextnode is the next node public key or IPAddress.Hashold is the previous chain element receivedfrom the previous node

HasholdIt is the previous chain element received from theprevious node. When receiving packets, nodeschange the value of Hashnew into Hashold

Hop Count The actual hop count of the packet.It is the number of times the hash is performed

The second mechanism is used during the routediscovery process in which request and responsemessages are exchanged. In this mechanism, nodesdo not need to send its geographical position. Instead,each node assumes that its local connectivity is securethanks to the neighbor information provided by theprevious mechanism. Each node then send in unicastall route discovery packets to its direct neighbors.Each node also includes the address of the next hopto which the message is forwarded and apply a hashchain to the packet mutable fields. The non-mutablefields are signed as stated previously. An illustrationof the request message is shown in Table III. Thesource node appends its own address and the nextnode address to the hash chain called Hashnew. It alsoincludes the Hashold (which is the previous Hashnew)within the packet. When an intermediate node says Nireceives a request, it checks its signature and verifythe Hash chain. It re-computes the Hash chain withH [previousnode, MyIPAddress, Hashold] and verifyif it has the same result as the one included in thepacket.

Considering the Figure 3, we compute the hashchain as the following:

The GCS node executes the following operation:• Select a H hash function;• Compute Oldhash = H(seed), seed is a value

selected randomly by the sender;• Compute Hashnew = H(GCS, N0, Oldhash), N0

is the next node address;• Compute message S to N0: [64, H, signature,

Hashnew, Oldhash]When the node N0, receives the packet, it pro-

cesses the following operation:• Integrity verification by computing Hashverifier

= H [previousnode, actualnode, Oldhash] andverify the result compared to Hashnew. Since,we use a one way hash function, the slightestchange would lead to difference. Besides, thehash function is only known by legitimate node.

• If Hashverifier = H[GCS, N0,Oldhash] = Hash-new, it indicates that the link is free of wormholeattack. Otherwise, it means that the packet hasbeen transmitted via a wormhole link. The packetis then rejected.

• Assign the new Oldhash = Hashnew• Compute the new Hashnew with Hashnew =

H[N1, N2, Oldhash]

Figure 5. Secure UAANET Routing Protocol De-sign Architecture

The operation is repeated until the packet reachesthe destination. The same mechanism is also used forthe response packet. As regards the exact value of thehop count values, it can be inferred from the numberof times that the hash was used for verification. It canalso include in the hash chain computation. Note thatthis mechanism can also be efficient against wormholeattacks involving only one attacker [23].

Security block design architectureIn order to specify our specification into high-

level models, we use a dedicated security designarchitecture for the security part (depicted in Fig-ure 5) and a dedicated generic routing architecturefor the routing part (shown in 6). The specifica-tion follows the IETF draft [8] in which each re-quirement (messages, tables, parameters, extensionspecification) has been meticulously respected. Oursystem includes several blocks transmitting signalsbetween them denoting the security and networkrequirements specifications. They also contain severalinstances of stateflow graphic representation. Theseblocks describe the possible protocol behavior as willdetail in the following. To give a general idea ofthe complexity of the SUAP model specification, wepresent in the Table IV some significant metrics ofthe global system.

In the security architecture design, each packetreceived from the link layer must be verified by a

Table IV. Metrics of the SUAP ProtocolSpecification

Code lines 6236Blocks 30Procedures 188States 30Signals 36Macro definitions 14

module called "Packet identifier" to check whether ornot the packet has a security extension. In case, itdoes not contain a sufficient security extension, thepacket is rejected by the Packet rejector module.

The packet rejector module role is to deletesuspicious packets. If the packet has its securityextension activated, its content is extracted from theContent extractor module. This module explicitlyidentified which part contains the signature, the hashchains and the location information for the wormholedetector.

Then, the packet is verified by the wormholetester module which mainly compute either the as-sociation between the hop count and the distancetraveled by the packet (if beacon and route errormessages are exchanged), or compute the actual hashchains for the message. In this step, if the packet failsto prove its required security level against wormholeattacks, it is redirected to the packet rejector module.Otherwise, it is sent to Authentication and Integritytester module. In this block, the authentication ofnon-mutable fields and integrity of mutable fields isverified. If all the information within the securityextension is valid, the packet is directed to the routingmodule to check whether or not the packet hasreached its final destination.

Regarding routing blocks, The basic routing pro-cess is modeled as follows:• Demux block accepts packet from transport layer

(when the actual node needs to search a routetowards a given destination) or the link layer.Then, the Demux block verifies the type field ofthe packets to determine if the packet is for routediscovery block or route maintenance block.

• Route discovery and Route maintenance block:Upon the reception of a packet from the "De-mux" block, "Route Discovery" and "RouteMaintenance" process the same operation. Theyanalyze the encapsulated routing information

within the packet to determine its type: RREQ,RREP, HELLO, or RERR packet.

• RREQ Mgmt, Hello Mgmt, RREP Mgmt, RERRMgmt: These blocks determine if the packet car-ries sufficient routing information and reached itsfinal destination. Based on this result, the packetis transmitted, to the "Packet send handler.”

• Packet send handler: The "Packet send handler"block is used to retrieve the packet and to updateits fields according to its destination, whetherto the transport or access layer depending onwhether or not the current node is the finaldestination node. In case the packet has reachedits final destination, it is transmitted to theapplication layer through a user-space daemon.Otherwise, it is forwarded to the next node inthe routing table.It is important to underline that some function-

alities described in the AODV specification has beenomitted (e.g. multicast support, gratuitous RREP mes-sages or packet extension) as they are not necessarilyneeded in our network model.

Figure 6. UAANET Routing Protocol Design Ar-chitecture

Formal verification processA key benefit of MDD is early verification.

Verification begins when block models are createdand simulated using unit tests based on high-level re-quirements. In our case, this verification is processedby additional tools as shown in Figure 2:• Simulink Code Inspector: it is processed to

perform model-and-code consistency checking.It examines blocks, state diagrams, parameters,and settings in the model to determine whether

they are structurally equivalent to the operations,operators, and data in the generated code. Thenit generates a traceability documentation withrespect to the DO-178C reference document thatcan be used for certification purposes.

• Simulink Design Verifier: it uses formal check-ing tools to identify model design errors. Itdetects, blocks that lead to errors, such as deadlogic, integer and fixed-point overflows, divisionby zero.

• Model coverage tool: it gives line coverage in-formation. It indicates which part of the modelis depicted by a given line of code. This isuseful when an error has been identified by theSimulink Design Verifier to locate which part ofthe model is faulty.

UAANET real-world experimentsRouting Implementation details

To execute the source code obtained throughMDD approach, it is necessary to cross-compile andcross link the embedded Linux C code into thetarget hardware, which is an ARM board5. Thiscross-compilation is executed with OpenEmbeddedframework [24] which also generates6 a lightweightand efficient Linux distribution for the ad hoc net-work communication. It should be noted that ourimplementation is mainly based on the Linux Netfilterpackage through a kernel module. We attach each en-try and output of our model to the set of hooks pointswithin the Linux protocol stack. Compared to kernelmodification methodologies [25], our implementationdoes not necessitate unnecessary communication (forinstance the exchange of ARP packet) and can be in-stalled and initialized through the user-space daemonas in AODV-UU.

Experimentation detailsThe UAANET architecture that has been set

up is shown in Figure 8. The network is composedof 3 nodes, including 2 fixed wing UAVs (DT 18[14] developed by the Delair Tech company) andone GCS (also from Delair Tech). The DT-18 is a

5This is because, the unit test of the routing protocol hasbeen processed with a X86 architecture. As a result, the crosscompilation is necessary to add the missing headers required bythe cross compiler and the cross linker

6configure and build

Table V. Main Characteristics of DT-18 UAVs

Characteristic ValueModel DT-18Payload 250 gRange 100 kmCruise speed 50 km/hWind up to 45 km/hreal-time payloadtransmission

up to 15 km. Extension to100 km

Autopilot Delair-Tech technology

Onboard computer payload and communication control,1 GHz

Experiment duration 30 minutes

lightweight UAV capable of long-range flight whosecharacteristics are detailed in Table V. The firstUAV called Dr1 is flying at a distance of 250-500meters from the GCS whereas the second UAV Dr2flies at a distance 1500-2000 meters from the GCS.Hence, the distance between the two flying UAVs isapproximately 1500m. The average altitude of UAVsis estimated at 1127 feet (345 m).

Furthermore, regarding the different types oftraffics exchanged between nodes, there are 5 typesof data traffics (depicted in the table VI) including:• Heartbeat traffic: It is a 100 Bytes data packet

sent both by the GCS and by each UAVs at 1Hz frequency. Each node keeps sending heartbeatpacket to find out whether or not it is connectedto its associated neighbor. If a number of heart-beats messages are missing, the UAV failsafe(can be) is triggered to land the UAVs at thelaunch point.

• Geographical reference: It is a 80 bytes packetfor determining UAVs positions. It is sent fromthe UAVs to the GCS. 3 packets are sent persecond

• Command and control traffics sent to each UAVfrom the GCS. 80 Bytes sent per second. It con-sists of a flight configuration and waypoint sentby the operator through GCS desktop software.

• Network traffic: It consists of routing controlpackets exchanged between nodes for route dis-covery and route maintenance.

• Payload traffic (video traffic) exchanged fromDr2 to the GCS through Dr1. We sent 25 UDPpackets (each packet has 1400 Bytes) per second.On each UAV, we mount an ARM-based

computer-on-module produced by Phytec Inc. It runs

Table VI. The Different Flows Exchanged During the Flight Test

Type of traffic Source —- Destination Size Flow rate

Heartbeat or Tick GCS —- Dr1GCS —- Dr2 64 Bytes 1 packet/s

Geographical Reference (Georef) Dr1 —– GCSDr2 —– GCS 80 Bytes 3 packets/s

C2 GCS—- Dr1GCS —- Dr2 80 Bytes 1 packet/s

Video Dr2 ——Dr1—– GCS 1400 Bytes 25 UDP packets/secondwidth=720,height=576

Network Exchanged between Dr1, Dr2and the GCS

Request: 66 bytesResponse: 62 bytesHello : 62 bytesError: 54 bytes

1 packet/s for the helloRequest and Response andError packets are exchangedduring disconnection (route loss)

a customized Linux distribution compiled and builtwith OpenEmbedded framework. We also attacheda HD camera and a Wi-Fi radio interface module.The Wi-Fi radio interface being used is the Mikrotik7

using 802.11n. During the experiments, we enabledspace-time block coding to exploit channel diversityin order to avoid interference.The transmission band-width was set to 5 MHz and provides half duplexcommunication.

Each UAV is remotely controlled through a dedi-cated GCS (Desktop and Infrastructure) as depicted inFigure 8. However, they do not take part in the routingprocess. Their role is to provide safety links to eachUAVs for failsafe management. This is part of DGACregulation to have at least each UAV connected toa station control via a dedicated links. Each UAVhas therefore two links. The first link is either 868MHz or 900 MHz obtained through XBEE devices8.The second link called safety link is a mandatoryspecification that must be set up to provide recoveryassistance when the communication link through theXbee is not efficient. Figure 7 illustrates the differenttypes of data link deployed.

Test scenario and nodes mobility

During the experiment, Dr2 is firstly launchedto a 800 meters distance from the GCS. When itreaches its predilection position, we launched the Dr1to extend the mission coverage. Dr1 is used as a nodeforwarder (its payload is not activated) by forwarding

7can be seen in http://www.mikrotik.com/8We have set 868 MHz for the Dr2 (the UAV that goes furthest)

and 900 MHz for Dr1 (the nearest UAV) to avoid interference

Figure 7. Communication Links Between Nodes

each data packet it receives. This allowed us to sendthe Dr2 UAV to a 2 km distance from the GCS.

Furthermore, their mobility consists of rectilinearand circular movement remotely executed on-demandby the operator through the GCS desktop. The fluc-tuation between these mobility creates disconnectionfrom time to time and decrease the performanceaccordingly.

Experimental resultsOverhead

The overhead represents the amount of controlpacket sizes added to data packets. Within UAANETs,despite the constant mobility of nodes, the signaling(size of network control packets) cost of reactiveprotocols is significantly lower than payload sizes (seetable VI). The overhead performance evaluation isshown in table VII

The protocol does not generate a significantamount of overhead. Thus, it does not perturb the

Figure 8. UAANET Real World Experiment Scenario

Table VII. Protocol Overhead over 30 minutestest

Overhead ProtocoleControl packets 352 koTraffic % (bytes) 2.15 %

transfer of payload (video) packets. This good over-head results can be explained by the non-requirementsto acknowledge each packet sent compared to DSRprotocol and the no need to update an already estab-lished route. Indeed, once a route between GCS andDr2 (through DR1) is computed and established, theprotocol no longer seeks the complete topology of thenetwork. Each node only checks its direct neighborthrough periodic exchanged of beacon messages.

Route stabilityThis metric evaluates the delay during which the

connectivity is uninterrupted. The result is depictedin Figure 9 and table VIII

0

5

10

15

20

25

30

35

12mn 16mn 20mn 24mn

aver

age

lifet

ime

(sec

ond)

Delay (minutes)(number of occurrences of route loss)

Route stability

’restablish.out’

Figure 9. Route Stability Between GCS and DR2

Table VIII. Route Stability over 30 minutes Test

Metric ValueAverage route lifetime 14.328955 sMaximum route lifetime 34.853527 sMinimum route lifetime 4.600461 s

These results show that on average over 30minutes test, there is a route loss every 14.5 seconds.This is explained by the node mobility that createsdisconnections. One important aspect that must benoted is the stability fluctuation which is caused bythe difference in the radiation plane and the polariza-tion plane of the transmitting and receiving antennawhich generates a signal attenuation. Indeed, becauseof the 3D mobility, each UAV has its relative positionslightly tilted compared to its direct neighbors posi-tion. By comparing the Wireshark trace to the mobil-ity log of each UAV, we noticed a group maintenancepacket being transmitted when UAVs mobility modetransition (For instance, from rectilinear waypoint tocircular). Consequently, there is a strong likelihoodthat the combination of the propagation loss andthe signal attenuation cause those momentary linkbreakages.

Moreover, apart the difference at the antennalevel, it is important to mention that the introductionof real parameters in real situations impacts the per-formance. For example, it is noticed in the movementlog that when the UAV is cornering, the inner wingmask the modem radio as it is located under the drone.Generally, nodes mobility and antenna polarizationissues make it difficult to maintain communicationfor a long time.

Nonetheless, despite the presence of these inter-mittent connectivity, the recovery delay is relativelylower (order of 1 milliseconds), thus, the communi-

−80

−75

−70

−65

−60

−55

−50

−45

−40

−35

−30

8mn 12mn 16mn 20mn 24mn

sign

al s

tren

ght

(dbm

)

Delay (minutes)

Dr2 reception signal variation

’signal.dat’

Figure 10. Variation of Reception Signal of DR2Strength During the Mission

−75

−70

−65

−60

−55

−50

−45

−40

−35

−30

0 5 10 15 20 25 30 35

Sig

nal s

tren

gth

(en

dbm

)

Times ( minutes)

Variation of route lifetime depending on signal strength

’puissanceetstability.dat’ using 2:3

Figure 11. Average Route Stability Between DR2and GCS

cation performance is not decreased and the payloaddata are correctly transmitted. As we will see in thenext metric, the difference lies in the payload sizebeing transmitted.

In the following, we will analyze the power ofthe Dr2 received signal to have a clear idea on routeloss.

Overview of the variation of reception signalstrength of Dr2 during the mission

Figure 10 shows a combination of constant andpeak oscillations during the mission. It shows that thesignal power fluctuates during the mission and causeslink breakages when it is under -60 dbm. On the one

0.0005

0.001

0.0015

0.002

0.0025

0.003

0.0035

0.004

0.0045

0.005

12mn 16mn 20mn 24mn

Del

ay (

in s

econ

ds)

Delay (in minutes)(number of occurrences of route re−establishment)

Average delay to re−establish route

’recup.dat’

Figure 12. Average Delay for Route Establish incase of Route Loss

hand, the constant oscillation is due to the unstablemovement of each UAV during its execution of c2traffics. On the other hand, the important oscillationpeak is caused both by the part of the region thatpresents a high attenuation and by the signal atten-uation (caused by antenna polarization) as explainedpreviously.

Additionally, based on Figure 11, which showsthe correlation between signal strength and routelifetime, we can see that the route lifetime tends toincrease (higher quality of service) when the signalquality increases. Since the bandwidth allocated forthe data is unchanged over the whole test period, wecan conclude that the noticeable fluctuation comesfrom other physical and topological factors.

Average delay for route establish in case ofroute loss

Table IX. Average Delay to Re-establish Route incase of Route Loss

Re-establish delay ValueAverage delay 0.001098 sMaximum delay 0.004646 sMinimum delay 0.000519 s

This metric computes the recovery time to re-store from route loss. It is equal to the time intervalbetween the sender of route request (identified witha given sequence number) and the arrival of routeresponse to restore a route. Network connectivity

Table X. End to end delay summary

Delay ValueAverage delay 0.000153 sMaximum delay 0.00297 sMinimum delay 0.000100s

may be determined through the reception of broadcasthello messages. If any hello message is received froma neighbor for a given time, it indicates that neighborsare no longer within transmission range, thus, theconnectivity has been lost.

Figure 12 and Table IX shows the results. Wecan notice that the delay is quite low given thedynamic features of UAANET. This is because of thesmall sizes of control packets and the speed of lightswhich is approximately 3 ∗ 108ms−1. Our protocolbehaves correctly to its requirements specification.The topology change caused by UAVs mobility andspeed does not affect significantly the delay to retrieveroutes. This is also explained by the fact that theprotocol does not wait for the loss of several beaconmessages to start looking for an alternative route.

Average end to end delay of control packetsIt refers to the time taken for a packet to be

transmitted across the network. It is composed oftransmission delay, propagation delay, processing de-lay and queuing delay.

0.0001

0.00012

0.00014

0.00016

0.00018

0.0002

0.00022

0.00024

0.00026

0.00028

0.0003

12mn 16mn 20mn 24mn 28mn

Tra

nsfe

rt d

elay

(se

cond

s)

Experience Delay (minutes)

Transfert delay between GCS and DR1

’endtoend.dat’

Figure 13. End to end Delay Between DR1 andGCS

Figure 14 and Table XI shows the average timerouting of control packets between Dr1 and Dr2.

0

0.0005

0.001

0.0015

0.002

0.0025

0.003

12mn 16mn 20mn 24mn 28mn

tran

sfer

t del

ay (

seco

nds)

Experience delay (minutes)

Transfert delay between Dr1 and Dr2

’endtoend.dat’

Figure 14. Average end to end Delay Between Dr1and Dr2

Table XI. Average Delay Between Dr1 and Dr2

Delay valueAverage delay 0.000549 sMaximum delay 0.003 sMinimum delay 0.000224s

Figure 13 and Table X for the communication Dr1to the GCS. These two graphs indicate a good abilityto forward control traffics within the network aswe are noticing small delays. The routing protocoldoes not add significant further delays. Besides, thesmall sizes of control packets justify the result. Wealso notice that the communication delay of Dr1 andDr2 is slightly more important than Dr1 and GCS.This is because the GCS does not move during theduration of the mission whereas Dr1 and Dr2 executetheir respective flight plan. It is important to notethat the delay may vary depending on the type ofcontrol packet (request, response, hello or route error).Nonetheless, due to the small size difference betweenthese packets, we can ignore these differences.

Loss analysis of control and payload packetsThis metric measure how many routing control

packets are lost during the mission. We also analyzedits impact on the payload traffics by measuring thesize of payload packets being lost by the time theroute is repaired. As shown in Table XII, we notice aquite important amount of control packet loss (mostlythe loss of hello packets). When a certain amount ofhello packet is lost, there is a delay to establish a

5

10

15

20

25

30

35

40

45

50

55

8mn 12mn 16mn 20mn 24mn

Byt

es

Experience delay (minutes)

Payload packet loss

Figure 15. Average Payload Packet Loss

new route. This delay is relatively small (as depictedin Table IX) but not negligible at this level. As aresult, payload packets are fragmented and decreasedin size as shown in Figure 15. This indicates thedegradation of the video quality viewed on the GCSdesktop application during the mission.

Table XII. Control and Payload Packet LossSummary

Parameters ValueNumber of control packet loss 284 packetsAverage size of payload packet loss 12 BytesMaximum size of payload packet loss 52 Bytes

Conclusion and Future ResearchIn this paper, we have presented a case study of

designing a secure UANET routing protocol applyingmodel driven development approach. We were able tomodel and generate code through Mathworks (e.g.,Simulink and Stateflow) tools. It allowed us an easy,rapid modeling and testing of the algorithms, andavoid many implementation problems by the use ofintegrated formal verification tools which gives acomplete flexibility to the process. We obtained averified and validated model that contributes to thecertification of the final architecture.

We also introduced real test experiments to con-front our final embedded software to the real wordsexperiment environments. Our performance resultsshow that our routing protocol fits well to the dynamictopology of UAANET. Despite the route loss for

every 14.5 seconds which degrades the video trafficquality, we noticed that the delay to find alternativeroutes is relatively small, which does not perturb thepayload traffic exchanges. However, we add this inour to-do list to have more stable routes and improveour communication architecture performance.

In regards to our short-term perspectives, weare currently working on formal verification of oursecure routing protocol with AVISPA tool. It is auseful validation technique for authentication, non-repudiation and confidentiality. This approach is notfully applied in ad hoc networks. Some researchershad used formal analysis with a mathematical ap-proach but it appears to be hard to automate and timeconsuming. Our objective is to validate the SUAPsecurity specification. Furthermore, we also plan toperform additional real-world tests to validate oursecure routing protocol with a higher node density (3or 4 UAVs) and by considering different additionalscenarios.

AcknowledgmentsWe would like to express our gratitude to Delair

Tech research and development team for their supportand help during the real world experiments.

References[1] B. Mancini, “The great reconnaissance: a uavproject in niger,” GeoInformatics, vol. 17, no. 6, p. 6,2014.[2] S. Rosati, K. Kruzelecki, G. Heitz, D. Floreano,and B. Rimoldi, “Dynamic routing for flying ad hocnetworks,” 2014.[3] K. P. Valavanis and G. J. Vachtsevanos, “Uav ap-plications: introduction,” in Handbook of UnmannedAerial Vehicles, Springer, 2015, pp. 2639–2641.[4] J.-A. Maxa, M. Slim Ben Mahmoud, and N. Lar-rieu, “Secure routing protocol design for uav ad hocnetworks,” in Digital Avionics Systems Conference(DASC), 2015 IEEE/AIAA 34th, IEEE, 2015, 4A5–1.[5] J. Li, Y. Zhou, and L. Lamont, “Communicationarchitectures and protocols for networking unmannedaerial vehicles,” in Globecom Workshops (GC Wk-shps), 2013 IEEE, IEEE, 2013, pp. 1415–1420.[6] L. Gupta, R. Jain, and G. Vaszkun, “Survey ofimportant issues in uav communication networks,”

[7] J.-A. Maxa, G. Roudiere, and N. Larrieu,“Emulation-based performance evaluation of routingprotocols for uaanets,” in Communication Technolo-gies for Vehicles, Springer, 2015, pp. 227–240.[8] C. Perkins, E Belding-Royer, and S. Das, “Ad hocon demand distance vector (aodv) routing (rfc 3561),”IETF MANET Working Group, 2003.[9] T. Clausen, P. Jacquet, C. Adjih, A. Laouiti, P.Minet, P. Muhlethaler, A. Qayyum, and L. Viennot,“Optimized link state routing protocol (olsr),” 2003.[10] D. Johnson, Y Hu, and D. Maltz, “The dynamicsource routing protocol (dsr) for mobile ad hoc net-works for ipv4,” Tech. Rep., 2007.[11] M. Hyland, B. E. Mullins, R. O. Baldwin,and M. A. Temple, “Simulation-based performanceevaluation of mobile ad hoc routing protocols in aswarm of unmanned aerial vehicles,” in AdvancedInformation Networking and Applications Workshops,2007, AINAW’07. 21st International Conference on,IEEE, vol. 2, 2007, pp. 249–256.[12] J.-A. Maxa, “Model-driven approach to design asecure routing protocol for uav adhoc networks,” inEDSYS 2015, 15ème Congrès des doctorants, 2015.[13] N. Butcher, A. Stewart, and S. Biaz, “Securingthe mavlink communication protocol for unmannedaircraft systems,”[14] N. Larrieu, “How can model driven developmentapproaches improve the certification process for uas?”In Unmanned Aircraft Systems (ICUAS), 2014 Inter-national Conference on, IEEE, 2014, pp. 253–260.[15] Delair Tech, www . delair - tech . com, [Online;accessed 09-octobre-2015], 2015.[16] Y. Moy, E. Ledinot, H. Delseny, V. Wiels, and B.Monate, “Testing or formal verification: do-178c al-ternatives and industrial experience,” Software, IEEE,vol. 30, no. 3, pp. 50–57, 2013.[17] N. Larrieu and A. Varet, “Prototypage rapidede logiciel pour les systèmes avioniques: contributiondes approches orientées modèle pour la certificationde systèmes complexes,” 2014.

[18] R. Castanet and D. Rouillard, “Generate certifiedtest cases by combining theorem proving and reacha-bility analysis,” in Testing of Communicating SystemsXIV, Springer, 2002, pp. 249–265.[19] B. Kannhavong, H. Nakayama, Y. Nemoto, N.Kato, and A. Jamalipour, “A survey of routing attacksin mobile ad hoc networks,” Wireless communica-tions, IEEE, vol. 14, no. 5, pp. 85–91, 2007.[20] M. Khabbazian, H. Mercier, and V. K. Bhargava,“Severity analysis and countermeasure for the worm-hole attack in wireless ad hoc networks,” WirelessCommunications, IEEE Transactions on, vol. 8, no.2, pp. 736–745, 2009.[21] J. Cordasco and S. Wetzel, “An attacker modelfor manet routing security,” in Proceedings of thesecond ACM conference on Wireless network security,ACM, 2009, pp. 87–94.[22] Y.-C. Hu, A. Perrig, and D. B. Johnson, “Packetleashes: a defense against wormhole attacks in wire-less networks,” in INFOCOM 2003. Twenty-SecondAnnual Joint Conference of the IEEE Computer andCommunications. IEEE Societies, IEEE, vol. 3, 2003,pp. 1976–1986.[23] M. Jain and H. Kandwal, “A survey on com-plex wormhole attack in wireless ad hoc networks,”in 2009 International Conference on Advances inComputing, Control, and Telecommunication Tech-nologies, IEEE, 2009, pp. 555–558.[24] O. Team, Openembedded user manual, 2006.[25] I. D. Chakeres and E. M. Belding-Royer, “Aodvimplementation design and performance evaluation,”International Journal of Wireless and Mobile Com-puting, vol. 2, no. 3, p. 42, 2005.

2016 Integrated Communications Navigationand Surveillance (ICNS) Conference

April 19-21, 2016