Collection Tree Extension of Reactive Routing Protocol for ...(unicast) (unicast) Time Time Time.....

Research ArticleCollection Tree Extension of Reactive Routing Protocol forLow-Power and Lossy Networks

Jiazi Yi and Thomas Clausen

Laboratoire d’Informatique-(LIX), Ecole Polytechnique, Palaiseau, 91128 Route de Saclay, France

Correspondence should be addressed to Jiazi Yi; [email protected]

Received 31 October 2013; Revised 19 February 2014; Accepted 20 February 2014; Published 25 March 2014

Academic Editor: Christos Verikoukis

Copyright © 2014 J. Yi and T. Clausen.This is an open access article distributed under the Creative Commons Attribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

This paper proposes an extension to reactive routing protocol, for efficient construction of a collection tree for data acquisition insensor networks.The Lightweight On-Demand Ad hoc Distance Vector Routing Protocol-Next Generation (LOADng) is a reactivedistance vector protocol which is intended for use in mobile ad hoc networks and low-power and lossy networks to build pathsbetween source-destination pairs. In 2013, ITU-T has ratified the recommendation G.9903 Amendment 1, which includes LOADngin a specific normative annex for routing protocol in smart grids. The extension uses the mechanisms from LOADng, imposesminimal overhead and complexity, and enables a deployment to efficiently support “sensor-to-root” traffic, avoiding complicationsof unidirectional links in the collection tree. The protocol complexity, security, and interoperability are examined in detail. Thesimulation results show that the extension can effectively improve the efficiency of data acquisition in the network.

1. Introduction

“The Internet ofThings” (IoT) assumes objects in our environ-ment be part of the Internet, communicating with users andwith each other and that these objects have communicationas a commodity. Communication in “The Internet ofThings”is a challenge, subject to resource constraints, fragile and low-capacity links, and dynamic and arbitrary topologies. Routingis among the challenges, which requires efficient protocols,able to converge rapidly even in very large networks, whileexchanging limited control traffic and requiring limitedmemory and processing power.

One of the important applications of IoT is for data acqui-sition in sensor networks: a set of spatially distributed sensorsthat are used to monitor physical or environmental condi-tions, and transmit their data to a data concentrator (periodi-cally, or triggered by some events).These data are transmittedby way of a multihop network and where the intermediaryhops (routers) in that network are the sensor devices them-selves. The collection of all paths from each sensor to thedata concentrator forms a collection tree. Traffic in such acollection tree is commonly described as being “sensor-to-root” traffic or “multipoint-to-point” traffic, indicating thatall traffic flows from the sensors to the data concentrator.

This paper describes a protocol for constructing sucha collection tree in multihop sensor networks, where theprotocol ensures that the resulting collection tree containsbidirectional paths between each sensor and the data con-centrator. The protocol is defined as an extension to areactive protocol: the LOADng routing protocol [1], whichprovides point-to-point routes between any two devices in asensor network. Deploying both in unison permits efficientconstruction of both point-to-point routes and collectiontrees, by way of the same, simple protocol mechanisms.

1.1. Background and History. Since the late 90s, the InternetEngineering Task Force (IETF) (http://www.ietf.org) hasembarked upon a path of developing routing protocols fornetworks with increasingly more fragile and low-capacitylinks, with less predetermined connectivity properties andwith increasingly constrained router resources. In ,97, theMANET (Mobile Ad hoc Networks) working group wascharted, then subsequently in 2006 and 2008, 6LoWPAN(IPv6 over Low PowerWPAN) and ROLL (Routing over LowPower and Lossy Networks) working groups were charted.

(1) MANET Protocol Developments. The MANET work-ing group has developed two protocol families: reactive

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2014, Article ID 352421, 12 pageshttp://dx.doi.org/10.1155/2014/352421

http://dx.doi.org/10.1155/2014/352421

2 International Journal of Distributed Sensor Networks

protocols, including AODV (Ad hoc On-Demand DistanceVector Routing [2]), and proactive protocols, includingOLSR(Optimized Link State Routing [3]). A distance vector pro-tocol, AODV, operates in an on-demand fashion, acquiringand maintaining routes only while needed for carrying data,by way of a Route Request-Route Reply exchange. A link stateprotocol, OLSR, uses a periodic control messages exchanges,each router proactively maintaining a routing table withentries for all destinations in the network, which provides lowdelays but constant control overhead. A sizeable body of workexists, including studying the performance of these protocolsin different scenarios and justifying their complementarity[4]. For the purpose of this paper, it suffices to observe thatOLSR provides low delays and predictable, constant controloverhead—at expense of requiringmemory in each router formaintaining complete network topology. AODV limits thememory required for routing state to that for actively usedroutes—at the expense of delays for the Route Request-RouteReply exchange to take place and control overhead dependenton data flows.

After acquiring operational experiences, the MANETworking group commenced by developing successors toOLSR andAODV, denoted byOLSRv2 andDYMO (DynamicMANET On-Demand Routing). Whereas a relativelylarge and active community pushed OLSRv2 towardsstandardisation [5, 6], the momentum behind DYMOwithered in the MANET working group http://tools.ietf.org/wg/manet/minutes?item=minutes81.html).

(2) 6LowPAN, ROLL, and Related Protocol Developments.The6LowPAN (IPv6 over low powerWPAN) working group waschartered for adapting IPv6 for operation over IEEE 802.15.4,accommodating characteristics of that MAC layer, and witha careful eye on resource constrained devices (memory, CPU,energy, and so forth). Part of the original charter for thisworking group was to develop protocols for routing in mul-tihop topologies under such constrained conditions and overthis particularMAC. Two initial philosophies to such routingwere explored:mesh-under and route-over.The former,mesh-under, would, as part of an adaptation layer between 802.15.4and IP, provide layer 2.5 multihop routing, that is, usinglink layer address for routing and presenting an underlyingmesh-routed multihop topology as a single IP link. Thelatter, route-over, would expose the underlying multihoptopology to the IP layer, whereupon IP routing would buildmultihop connectivity.

Several proposals for routing were presented in 6Low-PAN, for each of these philosophies, including LOAD(6LoWPAN Ad hoc On-Demand Distance Vector Routing[7]). LOAD was a derivative of AODV but was adapted forlink layer addresses and mesh-under routing, with somesimplifications over AODV (e.g., removal of intermediaterouter replies and sequence numbers). However, 6LowPANwas addressing other issues regarding adapting IPv6 for IEEE802.15.4, such as IP packet header compression, and solvingthe routing issues was suspended, delegated to a workinggroup ROLL, and created in 2008 for this purpose. ROLLproduced a routing protocol denoted by “routing protocol for

low-power lossy networks” (RPL) [8] in 2011 based on the ideaof collection tree protocol [9].

(3) Finally, towards LOADng. RPL as a collection tree proto-col has several well-known issues with respect to supportingdifferent kinds of traffic patterns, unidirection link handling,and algorithmic and code complexity [10]. On the otherhand, while LOAD [7] development was suspended by the6LoWPAN working group, AODV derivatives live on: IEEE802.11s [11] is based on AODV, and the ITU-T G3-PLCstandard [12], published in 2011, specifies the use of [7]at the MAC layer, for providing mesh-under routing forutility (electricity) metering networks. Justifications for usingan AODV derivative in preference to RPL include that theformer better supports bidirectional data flows such as arequest/reply of a meter reading, as well as algorithmic andcode complexity reasons [10].

The emergence of LLNs thus triggered a renewed interestin AODV-derived protocols for specific scenarios, resultingin work within the IETF [1, 13] for the purpose of stan-dardisation of a successor to LOAD—denoted by LOADng(the Lightweight On-Demand Ad hoc Distance Vector Rout-ing Protocol-Next Generation). LOADng incorporates theexperiences from deploying LOAD—including, but not only,LLNs—and has been accepted as part of an update to theG3-PLC (Power Line Communication) ITU-T (InternationalTelecommunication Union—Telecommunication Standard-ization Sector) standard for communication in the “smartgrid” [14].

1.2. Statement of Purpose. There have been a lot of protocolsproposed for data acquisition in sensor networks. In [15],the authors proposed collection tree protocol that uses ETX(expected transmission count) as the routing metric toconstruct one-way collection tree. A CDS-based networkbackbone for data collection is introduced in [16], to balanceenergy consumption and prolong the router lifetime inthe backbone. A Pareto based multioptimization approachPOCTP (Pareto Optimal Collection Tree Protocol) is dis-cussed in [17] to ensureQoS such as transmission throughput,delay, and loss of packets. In [18], an average transmissiontime (ATT) metric is applied to routing protocol, underwhich real-time events are transferred along the routes withthe shortest transmission time expectation. Multichannel isalso used in [19] to reduce interference.Those protocols, someof them only support one-way traffic from sensor routersto one concentrator like [15], or hard to be extended forgeneral sensor-to-sensor communications [16, 17]. Some ofthe protocols like [19] require specific support from lowerlayers, which are hard to be applied to normal sensorequipment.

The LOADng core specification aims at finding a routebetween any originator-destination pairs. This kind of point-to-point traffic pattern matches the basic traffic model of theInternet. However, in the world of smart grid, another impor-tant traffic pattern, called sensor-to-root, or multipoint-to-point exists. In such kind of scenarios, there are one or moreconcentrators that play as “root,” and all the other routers

International Journal of Distributed Sensor Networks 3

communicate with the root. If routes from all the otherrouters to the root are required, it is more efficient to builda “collection tree,” which is a directed graph that all edges areoriented toward and terminate at one root router.

This paper proposes an extension to a reactive routingprotocol LOADng, denoted by LOADng Collection TreeProtocol (LOADng-CTP), for building a “collection tree” inenvironments, constrained in terms of computational power,memory, and energy. An example of the design target forLOADng-CTP is the ESB (Embedded Sensor Board [20]),with a TI MSP430 low-power microcontroller, an 1MHzCPU, 2 kB RAM, and 60 kB flash ROM. The link layerstypically used in LLNs impose strict limitations on packetsizes: in IEEE 802.15.4, the maximum physical layer packetsize is 127 bytes and the resulting maximum frame size at themac-layer is 102 bytes. If link-layer security is used, this mayconsume up to a further 21 bytes, which leaves just 81 bytesfor upper layer protocols.

The LOADng-CTP presented in this paper is thusdesigned to meet the following requirements:

(i) effectively building a route from all sensors to the rootand the route from the root to the sensors if required;

(ii) unidirectional links being avoided in these routes;(iii) low overhead, easy collection tree maintenance;(iv) easy extension to LOADng, such that routers using

only LOADng (without collection tree extension) canjoin the collection tree.

Although the specification in this paper is designatedfor LOADng, its basic mechanism can be applied to generalreactive protocol, like AODV also.

The remainder of this paper is organized as follows. InSection 2, the LOADng-CTP specification is introduced,including related message format and main operations.The protocol is further analysed in Section 3, from theaspect of routing complexity, security, and interoperability.The simulation study is performed in Section 4, in whichLOADng, LOADng-CTP, and RPL are compared. Section 5concludes this paper.

2. LOADng-CTP Protocol Specification

LOADng Collection Tree Protocol (LOADng-CTP) is basedon the operation and packet format of LOADng. Therefore,the current LOADng implementation can be easily extendedto the collection tree protocol. In the following, the basicoperation of LOADng is introduced briefly, followed bythe single message and protocol processing required forcollection tree building and maintenance.

2.1. LOADng Basic Operation. LOADng contains two mainoperations: Route Discovery and Route Maintenance.

(1) Route Discovery. During Route Discovery, RREQ (RouteRequest) messages are flooded through the network. InLOADng [1], only the destination of the RREQ will replyby generating and unicasting an RREP (Route Reply) to the

originator of the RREQ. All RREQ and RREP messages, gen-erated by a LOADng router, carry amonotonically increasingsequence number, permitting both duplicate detection, anddetecting which of two messages contain the most “fresh”information.

(2) Route Maintenance. Route Maintenance is performedwhen an actively used route fails. Route failure is detected byway of a data packet not being deliverable to the next hoptowards the intended destination. In LOADng, the RERR isunicasted to the source of data packet. On receiving the RERRat the source of data packet, a new Route Discovery can beperformed, in order to discover a new route to the intendeddestination.

Compared to AODV, LOADng has the following charac-teristics.

(i) Modular design: the core specification defines thesimple and lightweight core functions of the protocol.LOADng is extensible, by way of a flexible packetformat permitting addition of arbitrary attributes andinformation via newmessage types and/or TLV (type-length-value) blocks. The LOADng protocol core isdetailed in this section, with subsequent sectionsillustrating the use of the flexible architecture ofLOADng for developing (interoperable and back-wards compatible) protocol extensions.

(ii) Optimised flooding: It can reduce the overheadincurred by RREQ forwarding. Jitter is employed, toreduce the probability of losses due to collisions onlower layers [21].

(iii) Flexible addressing: address lengths from 1 to 16octets are supported (i.e., IPv6, IPv4, 6LowPAN shortaddresses, Layer-2 MAC addresses, and so forth areall supported by LOADng). The only requirement isthat, within a given routing domain, all addresses areof the same address length.

(iv) Metrics: different metrics are supported, to make useof link information from different layers.

(v) Destination replies: intermediate LOADng routers areexplicitly prohibited from responding to RREQs, evenif they may have active routes to the sought des-tination. All messages (RREQ or RREPs) generatedby a given LOADng router share a single unique,monotonically increasing sequence number.This alsoeliminates Gratuitous RREPs while ensuring loopfreedom.The rationale for this simplification reducedcomplexity of protocol operation and reduced mes-sage sizes—found to be without significant influencein the performance [22]. Allowing only the destina-tion to reply to an RREQ also simplifies the task ofsecuring the protocol, because the destination canthus sign the RREPmessage, and the originator couldverify that it is the “real” destination that replies.

(vi) Reduced state: a LOADng router is not required tomaintain a precursor list; thus when forwarding adata packet to the recorded next hop on the pathto the destination fails, an RERR is sent only to


the originator of that data packet. The rationale forthis simplification is an assumption that few overlap-ping routes are in use concurrently, and delay is not acritical issue in a given network.

2.2. Message for LOADng-CTP. LOADng-CTP introducestwoflags toRREQmessages, carried by a so-calledRREQflag.

(i) RREQ COLLECTION TREE TRIGGER: when set, areceiving router will be triggered to discover withwhich of its neighbours it has bidirectional links.

(ii) RREQ COLLECTION TREE BUILD: when set, areceiving router will build the route to the root.

In addition, a HELLOmessage [5] is used, which includesall the 1-hop neighbours of the router generating the HELLOmessage. The HELLO messages are broadcast and neverforwarded. Bidirectional neighbours are identified by theexchange of HELLO messages.

2.3. Router Parameters for LOADng-CTP. LOADng-CTPuses the following parameters for protocol functioning.

(i) NET TRAVERSAL TIME: it is the maximum timethat a packet is expected to take when traversing fromone end of the network to the other.

(ii) RREQ MAX JITTER: it is the maximum jitter forRREQ message transmission. Jitter is a randomlymodifying timing mechanism to control traffic trans-mission in wireless networks to reduce the probabilityof transmission collisions [21].

(iii) HELLO MIN JITTER: it is the minimum jitter forHELLO message transmission. HELLO MIN JIT-TER must be greater than 2 × RREQ MAX JITTER.

(iv) HELLO MAX JITTER: it is the maximum jitter forHELLO message transmission.

(v) RREP REQUIRED: it is the flag to define if an RREPmessage is required on receiving RREQ BUILDmes-sage, to build routes from the root to sensors.

2.4. LOADng-CTP Procedures. The collection tree is, then,built by way of the following procedure—initiated by therouter wishing to be the root of the collection tree.

(1) Collection Tree Triggering (by the Root).The root generatesan RREQ with COLLECTION TREE TRIGGER set (hence-forth, denoted by RREQ TRIGGER). Both the originator anddestination of the RREQ TRIGGER are set to the address ofthe root.

When an RREQ TRIGGER is generated, an RREQ withCOLLECTION TREE BUILD flag set (henceforth, denotedby RREQ BUILD) is scheduled to be generated in 2 ×NET TRAVERSAL TIME.

(2) Bidirectional Neighbour Discovery. On receiving aRREQ TRIGGER, a router does the following.

(i) It records the address of the sending router(i.e., the neighbour, from which it received the

RREQ TRIGGER) in its neighbour set, with the statusHEARD.

(ii) If no earlier copy of that same RREQ TRIGGER hasbeen previously received,

(a) the RREQ TRIGGER is retransmitted, subjectto a jitter of RREQ MAX JITTER, to reduce thechance of collisions (except the root router);

(b) it schedules generation of a HELLO message,subject to a jitter of between HELLO MINJITTER and HELLO MAX JITTER. When thescheduled HELLO message is generated, it liststhe addresses of all the 1-hop neighbours, fromwhich it has received a RREQ TRIGGER.

On receiving a HELLO message, a router does thefollowing.

(i) If it finds its own address listed in the HELLO mes-sage, it records the address of the sending router (i.e.,the neighbour, from which it received the HELLO) inits neighbour set, with the status SYM (bidirectional).

(ii) The HELLO message is never forwarded but dis-carded silently.

Thus, each router will learn with which among its neigh-bour routers it has a bidirectional (SYM) or unidirectional(HEARD) link.

(3) Collection Tree Building. For 2 × NET TRAVERSALTIME after the RREQ TRIGGER, the root generates aRREQ BUILD.

On receiving a RREQ BUILD, a router does the follow-ing.

(i) It verifies if the RREQ BUILD was received from aneighbour with which it has a bidirectional (SYM)link. If not, the RREQ BUILD is silently discarded.

(ii) Otherwise, if no earlier copy of that sameRREQ BUILD has been previously received, orthe RREQ BUILD indicates a short path to the root,

(a) a new routing entry is inserted into the routingtable, with(1) next hop = previous hop of the

RREQ BUILD,(2) destination = root;

(b) the RREQ BUILD is retransmitted, again sub-ject to a jitter of RREQ JITTER.

Thus, each router will record a route to the root, andthis route will contain only bidirectional links.The collectiontree is built, enabling upward traffic. Figure 1 illustrates theRREQ BUILD processing.

(4) Root-to-Sensor Path Building. By exchanging RREQTRIGGER and RREQ BUILD messages, all the sensors inthe network obtained a path using only bidirectional links to


RREQ buildmessage received

From bidirectionallink?

Yes

Yes

YesNo

No

No Messagereceived before?

Insert tuple to routingtable

Forward themessage bybroadcast

End

Discard themessage

Message carriesbetter path?

Figure 1: LOADng-CTP RREQ BUILD message processing.

the root. This is sufficient for applications like environmentmonitoring, automatic meter reading, and so forth. However,in some applications, such as firmware update or remotecontrol, the root needs to send messages to sensors in thenetwork. The paths from root to sensors are thus desired.

The sensors that require root-to-sensor traffic must havetheir RREP REQUIRED flag set to be true. On receivingthe RREQ BUILD message, all the sensor routers withRREP REQUIRED flag set must initiate an RREP messagewith content of

(i) RREP originator = address of the sensor router;

(ii) RREP destination = address of the root.

The RREP is thus unicast to the root, subject to jitterRREP JITTER. On receiving the RREP message, a routingtuple is created in the routing table with

(i) next hop = previous hop of the RREP;

(ii) destination = address of the RREP originator(RREP originator).

Figure 2 depicts an example of root-sensor messageexchange sequences by illustrating the four steps of LOADng-CTP protocol (collection tree triggering, bidirectional neigh-bour discovery, collection tree build, and root-to-sensor pathbuilding). In the example, the root router builds a collectionstree connecting sensor routers 𝐴 and B, with the topologyshown in Figure 2(a). The message exchange is shown inFigure 2(b). The pseudosequence number in the brackets isused just for distinguishing different messages in this figure.In a real protocol implementation, sequence numbers aregenerated independently at each router.

2.5. Collection Tree Maintenance. Based on the operationintroduced in Section 2.4, a collection tree is built to enabledata traffic transmission between the root router and allthe other sensors. However, route failure could still happen,


Root Sensor A Sensor B

(a) Network topology

Root Sensor A Sensor B

(broadcast)

(broadcast)

(broadcast)

(broadcast)(broadcast)

(broadcast)

(broadcast)

(broadcast)

(discarded by root)RREP [6]

(unicast)

Collection tree triggering

Bidirectional neighbourdiscovery

Collection tree building

Root-to-sensor pathbuilding (optional)

(broadcast)

RREP [7]

RREP [7]

(unicast)

(unicast)

Time Time Time

...2×

NET

TRAV

ERSA

LTI

ME

RREQ TRIGGER [1]

RREQ TRIGGER [1] RREQ TRIGGER [1]

HELLO [2] HELLO [2]

HELLO [3]

RREQ BUILD[5]

RREQ BUILD[5] RREQ BUILD[5]

(b) Message flows

Figure 2: Message exchange of LOADng-CTP between root and sensors.

S

D

A

RREQRREQ

B

RREQ

C

RREQ

Root

(a) Route discovery without smart routerequest

S

D

ARREQ

B

Unicast RREQ

Unicast RREQ Unicast RREQ

C

Root

(b) Route discoverywith smart route request

Figure 3: An example of route maintenance. Router D is the root. The link between S–D is detected broken. Sensor routers A, B, and C stillhave routing tuple to D.

due to the “lossy” nature of sensor networks or topologychanges, such as

(i) loss of control message during the collection treebuilding process;

(ii) routing entries expire because of not updated timely;(iii) participation of new sensors;(iv) Sensors quit the network because of movement or

battery drain.

LOADng-CTP supports per-path maintenance when apath failure is detected, without rebuilding the whole collec-tion tree. A new route discovery is initiated according to usualprocedures of route discovery if

(i) the data packet to be forwarded cannot find a routingtuple to the desired destination in the routing table, or

(ii) the link to the “next hop” indicated by the routingtable is detected broken.

To avoid RREQ being broadcast through the wholenetwork and take benefits from that “most of other neighbourrouters might have an available route to the root,” a SmartRoute Request scheme can be employed: if an intermediaterouter, receiving the RREQ, does not have an available routeto the destination, the RREQ is forwarded as normal. If theintermediate router has a route to the root, that intermediaterouter will unicast the RREQ to the destination according tothe routing table.


......

· · ·

h = 0

h = 1

h = 2

h = H − 1

Figure 4: An example of balanced tree. Every parent has 2 children(𝐶 = 2).

Figure 3 gives an example of path maintenance in col-lection tree. Router D is the root, and the link between S–D is detected broken. Routers A and B have already directpath to D, and C has also a routing tuple to 𝐷 (by goingthrough S). Figure 3(a) depicts the route discovery initiatedby S according to LOADng basic operation. Because only thedestination is allowed to reply to the RREQ message, sensorrouters A, B, and C have to rebroadcast the RREQ message,even they have already routing tuples to D. This renders anetwork-wide flooding: for a network with 𝑛 routers, 𝑛RREQmessage retransmissions are required.

With smart route request, as shown in Figure 3(b), routersA, B, and Cwill unicast the RREQ to rootD according to theirrouting tables, and D can choose the best path to send RREPmessage. By doing so, the RREQ dissemination is limitedlocally (4 retransmission in this example), and the routingoverhead can be greatly reduced.

When a link on an active route to a destination is detectedas broken (by way of inability to forward a data packettowards that destination), an RERR (route error) message isunicast to the source of the undeliverable data packet. Boththis intermediate router and the source router need to initiatea new route discovery procedure.

3. LOADng-CTP Protocol Analyses

This section analyzes the main features of the LOADng-CTP,including protocol complexity, security considerations, andits interoperability with LOADng protocol.

3.1. Protocol Complexity. Unlike link-state routing protocolssuch as OSPF [23] or OLSR [6], which require keeping anetwork topology locally and run the Dijkstra algorithm,LOADng and LOADng-CTP concern only the basic addi-tive operation when calculating link metrics. Therefore, thecomputational complexity is negligible. A very importantconcern of routing protocol for sensor networks is its routingoverhead: themessage required tomaintain the routing table.

For simplicity, a balanced tree model is considered: thereis a single root in the tree, with total height of𝐻.The height ofroot is 0, and the leaf nodes are with height𝐻−1. Every nodein the tree (except the leaf nodes) has 𝐶 children (𝐶 > 1).Figure 4 gives an example of balanced tree with 𝐶 = 2.

The number of nodes at height ℎ (0 ≤ ℎ ≤ 𝐻 − 1) is 𝑛ℎ

=

𝐶ℎ. The total number of nodes in the tree is

𝑁 = 1 + 𝐶 + 𝐶2

+ ⋅ ⋅ ⋅ + 𝐶(𝐻−1)

=1 − 𝐶𝐻

1 − 𝐶(𝐶 > 1) . (1)

In LOADng-CTP, the message required for collectiontree building is the sum of RREQ TRIGGER, HELLO, andRREQ BUILD:

RREQ = 3𝑁. (2)

If root-to-sensor paths are required, every sensor also hasto unicast an RREP message to the root.

The number of RREP messages forwarded by all therouters at height ℎ is

RREPℎ

= 𝐶ℎ

𝐻−ℎ−1

∑

𝑖=0

𝐶𝑖

= 𝐶ℎ1 − 𝐶𝐻−ℎ

1 − 𝐶. (3)

The total number of RREP can thus be given by

RREPAll =𝐻−1

∑

ℎ=1

RREPℎ

=

𝐻−1

∑

ℎ=1

𝐶ℎ

1 − 𝐶−

𝐻−1

∑

ℎ=1

𝐶𝐻

1 − 𝐶. (4)

Considering (1), the total number of RREP forwarding is

RREPAll =1

1 − 𝐶

𝐶 − 𝐶𝐻

1 − 𝐶−(𝐻 − 1)𝐶

𝐻

1 − 𝐶

= 𝑁𝐻 −𝑁 +𝑁 −𝐻

1 − 𝐶.

(5)

Considering 𝐻 = ⌊log𝐶

𝑁⌋, the total number of RREPmessages thus scales with 𝑂(𝑁 log𝑁).

For the basic LOADng protocol, by which only point-to-point route build is supported, the number of RREQmessagesforwarding required to build path from all the sensors to theroot is

RREQ = 𝑁2. (6)

The RREP message is always needed in LOADng basicoperation, which is the same as (5).

Based on (2), (5), and (6), it can be concluded thatLOADng-CTP reduced routing overhead from 𝑂(𝑁2) to𝑂(𝑁) compared to basic LOADngmechanism if only sensor-to-root paths are needed, or 𝑂(𝑁 log𝑁), if root-to-sensorpaths are also required.

3.2. Security Considerations

(1) Protocol Vulnerability. The collection tree buildingprocess relies on strictly ordered message sequences:RREQ TRIGGER message for triggering the buildingprocess, then HELLO message for bidirectional neighbourcheck, and RREQ BUILD message for collection tree buildin the end. The message emission is controlled by routerparameters like NET TRAVERSAL TIME, RREQ JITTER,and HELLO JITTER.


The receiving order can be expected if those parametersare set correctly; however, in real implementations, theremight exist misconfigured routers, or even compromisedrouters that emit messages out of order. For example, ifa router sends a HELLO message before it receives allthe RREQ TRIGGER messages from its neighbours, oran RREQ BUILD message is received before the HELLOmessage exchange finished, the router cannot identify itsbidirectional neighbours correctly—thus it is not able to jointhe collection tree as expected.

In addition to message misordering, LOADng-CTP isalso prone to attacks like block-hole or spoofing attacks [24,25]. Malicious control traffic can have severe impact on thenetwork stability.

(2) Security Framework. One of the main objectives whenspecifying LOADng was to provide a modular architecturewith a core module that is easily extensible. The rationale forthis decision was that rarely “one-size-fits-all” in the area ofconstrained networks. This is particularly true for securityextensions: some networks may not require any level of Layer3 security, for example, because physical access is limited orlower layer protection is sufficient. Other networks requireintegrity protection with a lightweight cipher suite due tolimited processing power and memory of routers. In somecases, security requirements are tighter and confidentiality aswell as strong cryptographic ciphers is required.

The IETF has standardized a security framework forprotocols using the message and packet format definedin [26], which is used by LOADng-CTP. (Note thatthis framework is currently being revised in a succeed-ing document that will obsolete RFC6622 once approved:http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis). Ref-erence [27] specifies a syntactical representation of security-related information in TLVs for use with [26] addresses,messages, and packets. That specification does not representa stand-alone protocol but is intended for use by MANETrouting protocols, or security extensions thereof, such asLOADng-CTP.

Figure 5 depicts the architecture of a module forLOADng-CTP that provides integrity andnonrepudiation forLOADng, using the framework specified in [27].

Incoming RFC5444 packets are first parsed by theRFC5444 parser that demultiplexesmessages and sends themto the protocol “owning” the message type. As each RFC5444packet may contain multiple messages that are used bydifferent protocols on a router, the message type is used todemultiplex and send themessage to the appropriate protocolinstance. A message intended for LOADng-CTP will then beforwarded to the security extension module that verifies thesignature contained in a signature TLV inside the message.As the TLV contains additional information, such as thehash function (e.g., SHA-256, Secure Hash Algorithm) andthe cryptographic function (e.g., AES, Advanced EncryptionStandard), the module can choose the correct key and verifythe integrity protection. If the message signature is correct,the message is handed over to the LOADng-CTP module;otherwise it is rejected. Similarly, outgoing messages fromLOADng-CTP are handed over to the securitymodule, which

RFC5444 packet parsing / generation

Security extension based on RFC6622

LOADng -CTP messageprocessing / generation

Incomingpacket

Outgoingpacket

Messages Messages withadded TLVs

Messages(passed check) Messages

DROPMessages

(failed check)

Figure 5: Relationship with RFC5444, RFC6622, and LOADng-CTP.

in turn adds the TLV containing the digital signature of themessage. Then the message is handed over to the RFC5444module that multiplexes it into a packet.

During the message signature generation as well as veri-fication process, [27] takes special consideration for mutablefields, such as hop count and hop limit. In addition to hopcount and limit, the route metric contained in a metric TLVis also updated along the path of a message and can thereforenot be protected by a digital signature. LOADng-CTP liststhesemutable fields explicitly.While this is a security problemthat needs to be addressed in addition to a pure messagesignature (and is not discussed in this paper), based onthe message format of LOADng-CTP messages, at least thecalculation of signature is easy. This is because the messagesize does not change as no field is added or removed duringthe forwarding process of a message through the network(and therefore no other fields, such as message size or TLVblock size, need to be recalculated). The metric can simplybe replaced by a sequence of zeros before calculating thesignature and is then restored afterwards.

In addition to message integrity, packets may also bedigitally signed. As packets are used hop-by-hop, that is, arenever forwarded, this is useful to authenticate the previoushop along the path of a message. Otherwise, a router nothaving any credentials may, for example, simply forward acorrectly signed RREP message from one adjacent routerto another and increase the hop count. As the hop countis excluded from the signature calculation, the messageintegrity would still be valid. Packet signatures mitigate thisproblem at the expense of increased overhead on the channel.Note also that it is difficult to detect simple forwardingof a frame without modifying the content, also known as“wormhole attack.”

3.3. Interoperability Considerations. As sensor networks andlow-power and lossy networks are generally decentralizedsystem, devices would possibly work in a heterogeneousenvironment: theremight be old devices with basic functions,


Root

LOADng-core router

RREQ

S

D

A

C

B

E

Figure 6: An example of interoperability between LOADng-CTP(white nodes) and LOADng-core routers (grey nodes).

and newly jointed deviceswith extensions in the same routingdomain. This requires interoperability between routers usingLOADng-CTP and LOADng routers without collection treeextension (denoted by LOADng-core router).

A LOADng-core router will forward RREQ TRIGGERand RREQ BUILD message as normal RREQ messages, soit will not affect the collection tree building process of otherrouters in the network. But because LOADng-core routerscannot generate HELLO messages themselves and are notable to be verified as bidirectional neighbour, therefore,LOADng routers will not join the collection tree during thecollection tree building process described in this section.However, these routers can participate in the collection treeby initiating a new RREQ message to the root and thusjoin the collection tree as “leaf nodes” (i.e., nodes withoutchildren), as shown in Figure 6.

During the collection tree building process, LOADng-core routers will not be able to function as parents of otherrouters. As depicted in Figure 6, router 𝐶 will choose 𝐵 asparent, even if 𝑆 probably provides a shorter path to the root.If the LOADng-core router is on the only path to the root,forexample, router𝐸 has to go through 𝑆 to reach the root, a newRREQ will be initiated to the root.

The existence of LOADng-core routers will possiblyincrease the routing overhead in the network by initiatingmore route discoveries. But with the smart RREQ introducedin Section 2.5, the RREQ dissemination can be kept locally,thus without introducing much influence in the networks.

4. Simulation and Performance Analyses

4.1. Simulation Settings. In order to understand the perfor-mance impact of the collection tree extension to LOADng,this section presents a set of ns2 simulations, comparingLOADng, LOADng-CTP, and RPL, with the parametersof the trickle timer in RPL being set according to [8].Simulationsweremadewith varying numbers of routers from63 to 500 and placed statically randomly in a square field.The networks have consistent density of nodes; that is, thesimulation field grows as the number of routers increases:1100m × 1100m for 63 nodes, 1580m × 1580m for 125 nodes,2230m × 2230m for 250 nodes, and 3160m × 3160m for 500nodes. This simulates smart grid in suburban areas. As thesize of the network grows, the scalability of the protocol canbe tested.

The network is subject to sensor-to-root traffic, likeperiodic meter reading: all routers generate traffic, for whichthe destination always is a single, fixed router in the network.Each data source transmits a 512-byte data packet every 5seconds, in bursts lasting for 80 seconds each, for a totalsimulation time of 100 s.

For the purpose of this study, router mobility was notconsidered. Simulations were conducted using the TwoRay-Ground propagation model and the IEEE 802.11 MAC.Although there are various low-layer technologies morecommonly (and, perhaps, more viably) used for LLNs (powerline communication, 802.15.4, low-power wifi, Bluetooth lowenergy, etc.), 802.11 provides basic distributed mechanismsfor channel access, such as DCF (distributed coordinationfunction), CSMA/CA (carrier sense multiple access with col-lision avoidance). Therefore, general behaviour of a protocolcan be inferred from simulations using 802.11.

In the simulations, three types of routing protocols arecompared.

(i) LOADng core specification [1], referred to asLOADng in the following section. The routes arebuilt reactively when there are data packets need tobe sent.

(ii) LOADng with collection tree extension, referred toas LOADng-CTP. The collection tree is triggered andbuilt before the sending of data packets.

(iii) RPL with trickle timer, referred to as RPL. Theparameters of trickle timer are set according to [8].

4.2. Simulation Results. Figure 7 depicts the delivery ratio ofthree protocols. Both LOADng-CTP and RPL obtain deliveryratios close to 100%, regardless of number of nodes. LOADng,initiating route discovery for every router (network-widebroadcast), incurs a high number of collisions on the MAClayer (shown in Figure 8), and thus a lower data delivery ratio,especially in larger scenarios.

Figure 9 illustrates the average end-to-end delay.LOADng has longer delay mainly because the routediscovery is performed reactively; that is, the data packetshave to wait the finish of route discovery before being sentout. LOADng-CTP and RPL have routes a priori available,thus exhibiting identical delays.

For the sensor networks, the routing overhead is also acrucial consideration. Figures 10 and 11 show the number ofoverhead packets per router and average overhead of network(bytes/second), respectively, which the networks are neededto converge to a stable state; that is, every router has a routeto the root.

The overhead packets of LOADng-CTP and RPL growlinearly with RPL sending twice asmany packets as LOADng-CTP and RPL sending 10 times more bytes/s as comparedto LOADng-CTP, due to the RPL control packets (mainly,the DIOs) being bigger [10]: a DIO packet takes up to 40octets in these scenarios, whereas a LOADng-CTPRREQandRREP packet typically are 10 octets (base header of 24 octets,plus other options and addresses). The overhead of LOADnggrows exponentially as the number of nodes increases, up to


0

0.2

0.4

0.6

0.8

1

1.2

0 100 200 300 400 500

Del

iver

y ra

tio

Number of nodes

LOADng-CTPLOADngRPL

Figure 7: Packet delivery ratio.

LOADng-CTPLOADngRPL

1

10

100

100

1000

10000

100000

0 200 300 400 500

Num

ber o

f col

lisio

ns

Number of nodes

1e + 06

1e + 07

Figure 8: Number of MAC layer collisions.

700,000 packets for scenarios of 500 nodes (not drawn in thefigure). The point-to-point based basic LOADng mechanismis not optimized for sensor-to-root traffic.

5. Conclusion

This paper has presented an extension, LOADng-CTP, to thereactive LOADng routing protocol, permitting efficient andon-demand construction of collection trees for supportingsensor-to-root traffic types. LOADng-CTP permits findingpaths between a root router and all the other sensor routers inthe network using bidirectional links. The protocol supportsper-path route maintenance without rebuilding the wholecollection tree. Another key aspect of LOADng-CTP is thatany router can at any time determine that it needs to act

LOADng-CTPLOADngRPL

0

0.05

0.1

0.15

0.2

0.25

0.3

0 100 200 300 400 500

Del

ay (s

)

Number of nodes

Figure 9: Average end-to-end delay.

LOADng-CTPLOADngRPL

1

10

100

1000

10000

0 100 200 300 400 500

Num

ber o

f ove

rhea

d pa

cket

s per

rout

er

Number of nodes

Figure 10: Number of overhead packets transmitted by each router.

as a root for sensor-to-root traffic and spawn a collectiontree construction; this, without requiring that said routeris specifically provisioned for this purpose (no extra state,processing power, required).

The main features of LOADng-CTP are analysed. Therouting overhead is reduced to 𝑂(𝑁) for collection treebuilding, compared to 𝑂(𝑁2) of LOADng core specification(𝑁 is the number of routers in the network). An extensiblesecurity framework is proposed to protect the integrityof routing message exchange. The interoperability betweencollection tree extension and LOADng core specificationis considered. The LOADng routers without collection treeextension can also join the collection tree by initiating a routediscovery.


LOADng-CTPLOADngRPL

1

10

100

1000

10000

100000

0 100 200 300 400 500

Ove

rhea

d (b

ytes

/sec

)

Number of nodes

Figure 11: Overhead bytes per second in the whole network.

The performance of this extension has been studied;revealing delays and data delivery rations, comparable withRPL, are obtained while at the same time yielding consid-erably lower control traffic overheads. Compared to basicLOADng, the performance of the LOADng-CTP extensionyields better performance: lower overhead, higher data deliv-ery ratios, and lower delays.

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper.

Acknowledgments

The authors would like to gratefully acknowledge UlrichHerberg, Axel Colin de Verdiere, Yuichi Igarashi, ChristosVerikoukis (assigned editor), and anonymous reviewers ofthe paper for valuable comments, reviews, and technicaldiscussions.

References

[1] T. Clausen, A. C. de Verdiere, J. Yi et al., “The lln on-demandad hoc distance-vector routing protocol—next generation,”TheInternet Engineering Task Force, October 2013, internet Draft,work in progress, draft-clausen-lln-loadng.

[2] C. Perkins, E. Belding-Royer, and S. Das, “Ad hoc On-DemandDistance Vector (AODV) Routing,” Experimental RFC, 3561,July 2003.

[3] T. Clausen and P. Jacquet, “Optimized Link State RoutingProtocol (OLSR),” Experimental RFC, 3626, October 2003.

[4] L. V. T. Clausen and P. Jacquet, “Comparative study of routingprotocols for mobile ad-hoc networks,” in Proceedings of theIFIP MedHocNet, Sardinia, Italy, September 2002.

[5] T. Clausen, C. Dearlove, and J. Dean, “Mobile Ad Hoc Network(MANET) Neighborhood Discovery Protocol (NHDP),” RFC,6130, IETF, April 2010.

[6] T. Clausen, C. Dearlove, P. Jacquet, and U. Herberg, “TheOptimized Link State Routing Protocol version 2,” InternetDraft, draft-ietf-manetolsrv2- 19, work in progress, March 2013.

[7] K. Kim, S. D. Park, G. Montenegro, S. Yoo, and N. Kushalnagar,“6LoWPAN Ad Hoc On-Demand Distance Vector Routing,”Internet Draft, work in progress, draft-daniel-6lowpan-load-adhocrouting- 03, June 2007.

[8] T. Winter, P. Thubert, A. Brandt et al., “RPL: IPv6 RoutingProtocol for Low power and Lossy Networks,” IETF RFC6550,March 2011.

[9] O.Gnawali, R. Fonseca, K. Jamieson,D.Moss, and P. Levis, “TheCollection Tree Protocol (CTP),” TinyOS, Tech. Rep., 2009,http://sing.stanford.edu/pubs/sing-09-01.pdf.

[10] T. Clausen, A. C. de Verdiere, J. Yi, U. Herberg, and Y.Igarashi, “ExperienceswithRPL: IPv6Routing Protocol for Lowpower and Lossy Networks,” The Internet Engineering TaskForce, internet Draft, work in progress, draft-clausen-lln-rpl-experiences, February 2013.

[11] G. R. Hiertz, S. Max, Z. Rui, D. Denteneer, and L. Berlemann,“Principles of IEEE 802.11s,” in Proceedings of the 16th Interna-tional Conference on Computer Communications and Networks(ICCCN ’07), pp. 1002–1007, Honolulu, Hawaii, USA, August2007.

[12] “ITU-T G. 9956: Narrow-Band OFDM power line communi-cation transceivers—Data link layer specification,” November2011.

[13] T. Clausen, A. Camacho, J. Yi et al., “Interoperability reportfor the lightweight on-demand ad hoc distance-vector routingprotocol—next generation (loadng),” The Internet EngineeringTask Force, internet Draft, work in progress, draft-lavenu-lln-loadng-interoperability-report, December 2012.

[14] ITU, “ITU-T G. 9903: Narrow-band orthogonal frequencydivision multiplexing power line communication transceiversfor G3-PLC networks: Amendment 1,” May 2013.

[15] J. J. Lei, T. Park, and G. I. Kwon, “A reliable data collectionprotocol based on erasure-resilient code in asymmetric wirelesssensor networks,” International Journal of Distributed SensorNetworks, vol. 2013, Article ID 730819, 8 pages, 2013.

[16] X. Kui, Y. Sheng, H. Du, and J. Liang, “Constructing a cds-based network backbone for data collection in wireless sensornetworks,” International Journal of Distributed Sensor Networks,vol. 2013, Article ID 258081, 12 pages, 2013.

[17] Y.-Z. Wu, D.-P. Quan, and H.-G. Han, “Pareto Optimal Col-lection Tree Protocol for industrial monitoring WSNs,” inProceedings of the IEEE GLOBECOM Workshops (GC Wkshps’11), pp. 508–512, Houston, Tex, USA, December 2011.

[18] Y. Tang, C. Bu, and A. Fan, “A transmission time based routingprotocol for clustered collection tree wireless sensor networks,”in Proceedings of the International Conference on Computationaland Information Sciences (ICCIS ’10), pp. 21–24, Chengdu,China, December 2010.

[19] C. Buengbon, C. Tanwongvarl, and S. Chantaraskul, “Multi-channel collection tree protocol for wireless sensor networks,”in Proceedings of the 10th International Conference on Electri-cal Engineering/Electronics, Computer, Telecommunications andInformation Technology (ECTI-CON ’13), pp. 1–5, 2013.


[20] “TheESB Embedded Sensor Board,” 2013, http://contiki.source-forge.net/docs/2.6/a01781.html.

[21] T. Clausen, C.Dearlove, and B. Adamson, “Jitter Considerationsin MANETs,” IETF Inf. RFC, 5148, February 2008.

[22] T. Clausen, J. Yi, and A. C. de Verdiere, “LOADng: TowardsAODV Version 2,” in VTC Fall. IEEE, pp. 1–5, 2012.

[23] J. Moy, “OSPF Version 2,” RFC, 2328, IETF, April 1998.[24] W. Wang, Y. Lu, and B. K. Bhargava, “On vulnerability and

protection of ad hoc on-demand distance vector protocol,” inProceedings of the 10th International Conference on Telecommu-nications (ICT ’03), vol. 1, pp. 375–382, 2003.

[25] P. Ning and K. Sun, “How to misuse AODV: a case study ofinsider attacks againstmobile ad-hoc routing protocols,”AdHocNetworks, vol. 3, no. 6, pp. 795–819, 2005.

[26] T. Clausen, C. Dearlove, J. Dean, and C. Adjih, “GeneralizedMobile Ad Hoc Network (MANET) Packet/Message Format,”RFC, 5444, IETF, Feburary 2009.

[27] U. Herberg and T. Clausen, “Integrity Check Value andTimestamp TLV Definitions for Mobile Ad Hoc Networks(MANETs),” RFC, 6622, IETF, May 2012.

Submit your manuscripts athttp://www.hindawi.com

VLSI Design

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

International Journal of

RotatingMachinery


Hindawi Publishing Corporation http://www.hindawi.com

Journal ofEngineeringVolume 2014


Shock and Vibration


Mechanical Engineering

Advances in


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of


Distributed Sensor Networks


The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014

SensorsJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Active and Passive Electronic Components


Chemical EngineeringInternational Journal of

Control Scienceand Engineering

Journal of


Antennas andPropagation




Navigation and Observation


Advances inOptoElectronics

Hindawi Publishing Corporation http://www.hindawi.com

Volume 2014

RoboticsJournal of


Collection Tree Extension of Reactive Routing Protocol for ...(unicast) (unicast) Time Time Time.....

Documents

Transcript of Collection Tree Extension of Reactive Routing Protocol for ...(unicast) (unicast) Time Time Time.....