«Carles Gómez Josep Paradells José E. Caballero Edita: Fundación Vodafone España Autores: Carles Gómez Montenegro* Universitat Politècnica de ...»
One approach followed in many cases to provide multi-hop capabilities to WSNs consists in reusing routing protocols developed by the IETF MANET WG. While MANET routing protocols have been designed for scenarios with limitations due to wireless communication and mobility, WSNs constitute a further constrained scenario, especially in terms of the hardware capabilities of the devices and available network resources. In consequence, the MANET routing protocols considered for WSNs have required an adaptation process, which has mainly consisted in a simplification of the protocols by the removal of non-core mechanisms.
Given the constraints of WSNs, and in order to minimize energy and bandwidth consumption, only reactive routing solutions have been taken into account. In particular, several solutions are based on the Ad-hoc Ondemand Distance Vector (AODV) routing protocol  (a relevant case is the
mesh routing solution of ZigBee, which is essentially based on AODV, as will be seen in section 220.127.116.11). Some attention has also been devoted to the Dynamic MANET On-demand (DYMO) routing protocol .
7.2.1. AODV-based routing protocols This subsection first provides an overview of basic AODV operation. Then, two AODV-based routing protocols for WSNs are presented. These protocols are TinyAODV and Not So Tiny AODV (NST-AODV). Finally, other AODVbased proposals are also briefly introduced.
18.104.22.168. AODV basic operation AODV is a reactive routing protocol. When a node requires a route, it initiates a route discovery procedure by broadcasting Route Request (RREQ) messages (see Fig. 7.5). Each node rebroadcasts RREQs, unless it has a valid route entry to the destination or it is the destination itself. In this case, it sends a Route Reply (RREP) message back to the originator node and ignores any subsequent RREQs transmitted through alternative routes. Backward or forward next-hop routing entries are created at each node that receives a RREQ or a RREP, respectively. Route entries expire after a specified time if the route becomes inactive (i.e., it is not used for data transmission). For each route entry of a node, there is a precursor list containing the nodes that use this node as the next hop in the path to a given destination. The loop-freedom of routes towards a destination is guaranteed by means of a destination sequence number, which is updated when new information about that destination is received.
When a link in an active path breaks, the upstream node that detects this break may try to repair the route locally if the destination is close to the node. This is an optional mechanism. If local repair cannot be completed successfully or it is not supported, the node that detects the link break creates a Route Error (RERR) message, which reports the set of unreachable destinations. This message is sent to precursor nodes. If a route to the destination is still needed, the source of the active path then starts a new route discovery phase. Data packets waiting for a route should be buffered during route discovery.
Fig. 7.5. Route Discovery in AODV: node S intends to find a path to node D. Node S broadcasts a RREQ message; when a RREQ reaches the destination, this node replies back to the source with a RREP message, which is transmitted backwards to the source and creates routing entries to node D in the intermediate nodes and the source node An AODV node belonging to an active route may periodically broadcast local Hello messages for connectivity management. However, this approach may be expensive if nodes are battery-powered. Other strategies for detecting link failures include link layer mechanisms. For example, unsuccessful link layer transmissions may be used as an indication of a link break for AODV. This method is known as Link Layer Notification (LLN).
TinyAODV  is a minimalist AODV implementation for devices running TinyOS. In TinyAODV Release 2, only one node, namely a sink node, can be the destination of any data transmission. TinyAODV Release 3 enables communication between any pair of nodes in the network. The following description corresponds to TinyAODV Release 3.
If a data packet must be sent and no route entry exists for the intended destination, route discovery is performed, but the packet requiring the route is discarded. The next packet will be the first one using the discovered route. A number of route discovery retries (equal to 3 by default) can be performed.
In TinyAODV, only the destination generates RREP messages. A LLN mechanism is supported for detecting link failures, assuming the usage of
Chapter 7. Routing
an acknowledged mode at layer two. However, LLN is not enabled by default. Thus, TinyAODV is targeted for static topology networks, where link failures are not expected. In any case, the data packet undelivered due to a link break is discarded. An RERR is then generated and locally broadcast by the upstream node detecting the link failure. In any case, local repair is not supported. Finally, hop count is the routing metric used in the TinyAODV implementation.
NST-AODV is a routing solution implemented in nesC18 language for devices running TinyOS. It was developed on the basis of TinyAODV (Release 3), to which several features were added to improve its reliability and to provide better support for dynamic topologies . The main characteristics of
NST-AODV are summarized below:
• An LLN mechanism is enabled by default. This requires the protocol to run on top of the IEEE 802.15.4 reliable mode (where a node that correctly receives a data frame sends an acknowledgement frame to the sender).
• After an unsuccessful link layer transmission, up to two additional retries triggered by layer three can be performed.
• When a packet leads to link failure detection due to three consecutive, unsuccessful layer three transmission attempts, it is buffered and transmitted if a new route can be found. This may happen if the node that detects the break is the originator itself, or if it is an intermediate node that locally repairs the route.
The implementation consumes 957 bytes of RAM and 4664 bytes of ROM. According to experiments in a real IEEE 802.15.4 environment, each hop in a path contributes 20 ms to the Round Trip Time (RTT) when a route is available, and 30 ms when the route discovery time is included.
The Route Change Latency (RCL) incurred when a link fails and a new nesC is a programming language based on the C language developed for TinyOS devices (see Chapter 10).
route has to be found is below 100 ms in many topologies. For a detailed comparison of NST-AODV and other routing solutions, the reader is referred to .
22.214.171.124. Other proposals AODVjr  and AODVbis  are the first two AODV proposals aimed at reducing implementation complexity and leaving some features as optional. LoWPAN-AODV  and 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD)  were two proposals developed by the IETF 6LoWPAN WG , which assumes use of IEEE 802.15.4 as the radio interface. However, both proposals expired when another IETF WG, the IETF Routing Over Low-power and Lossy networks (ROLL) WG , was created with the aim of developing routing protocol solutions for WSNs, making initial routing proposals from 6LoWPAN obsolete (see section 7.3).
7.2.2. DYMO-based routing protocols
DYMO is a reactive routing protocol for MANETs which inherits most of its essential functionality from AODV. The main new feature in DYMO (when compared with AODV) is path accumulation. With this mechanism, RREQ messages record the path they traverse. When a RREQ message reaches the destination, the corresponding RREP that is transmitted back to the source includes the path recorded in the RREQ. In this way, all the intermediate nodes that transmit the RREP back can store the full route from the source to the destination. Intermediate nodes can then make use of this stored route if necessary, thus avoiding the Route Discovery message overhead.
DYMO has also been considered for WSNs. A proposal called DYMOlow, which was a DYMO simplification developed by the IETF 6LoWPAN WG, expired recently due to the reasons already given for LoWPAN-AODV and LOAD expiries. A TinyOS implementation of the DYMO protocol is called TYMO .
7.3 ROLL routing protocols 7.3.1. IETF ROLL WG scope and routing requirements The IETF Routing Over Low power and Lossy Networks (ROLL) Working Group  was created in late 2007 with the aim of analyzing and eventually developing solutions for IP-based Low power and Lossy Networks (LLNs). LLNs are defined as networks composed of embedded devices with limited power, memory and processing capabilities. LLNs include wireless low power radios (e.g. IEEE 802.15.4) and wired solutions with similar characteristics, such as powerline communication (PLC) links.
The ROLL WG first elaborated a list of requirements for a routing protocol on top of LLNs in each of the following application domains: home automation, commercial building automation, industrial automation and urban automation. Based on these requirements, the WG carried out an analysis of
existing routing protocols within the IP domain with regard to their applicability to LLNs. The general requirements that can be derived from the requirements specific to each application domain are as follows :
• The routing state of a node must not increase linearly with the number of nodes in the network or in the neighbourhood. A routing state that depends linearly on the number of unique destination is acceptable.
• Local events, such as the failure of a link between two nodes, must not lead to flooding broadcast messages to the whole network.
• The rate at which the routing messages are sent or received must be bounded by the rate of data packets.
The first requirement is a consequence of the need for scalability with the network size and density. However, it precludes those WSNs where any device can communicate with another (such a network may be found in the building of automation applications, for instance ).
According to the analysis, none of the existing IP routing protocols would fulfill all the criteria without modification. In consequence, the ROLL WG started to work on the specification of a new routing protocol suitable for
LLNs. This routing protocol is called IPv6 Routing Protocol for Low power and Lossy Networks (RPL19) . As of the writing of this book, the RPL specification is still being developed. The next subsection overviews RPL, based on the latest version of its specification.
RPL maintains Directed Acyclic Graphs (DAGs), which may be rooted at sink nodes or gateways to the rest of the Internet. The main difference between a DAG and a tree is the fact that, in a DAG, a node may select multiple neighbours as its parents (see Fig. 7.6). An important property of DAG is loop-freedom. This is achieved in RPL by ensuring that any node must always have a higher rank than any of its parents. A rank expresses the relative position of a node within a DAG. The rank may (or may not) be related with the routing cost for reaching the DAG root.
RPL naturally supports multipoint-to-sink and sink-to-multipoint communications. Point-to-point communications are also supported, but routes between arbitrary nodes may not be optimal, since they are constrained to the DAG structures.
RPL nodes build and maintain DAGs by periodically multicasting the DAG Information Object (DIO) message to their neighbours. The DIO message includes the rank of a node, the values used to calculate the routing cost towards the DAG root and the DAG identifier, among other fields. In order to join a DAG, a node listens to the DIO messages sent by its neighbours and selects a subset of these messages as their parents in the DAG. A node may also identify siblings, which are neighbours of this node having the same rank as this node (but does not necessarily share a common parent with this node). This allows path diversity to be increased, as a node can decide to forward a packet to a sibling in RPL. A node might select one preferred parent. The rank of this node would then be computed as the rank of the preferred parent plus an increment which depends on the cost of the link between the node and its preferred parent.
RPL is pronounced as ‘Ripple’.
Fig. 7.6. An example of a DAG in RPL. Note that Node 7 has two parents, which are Nodes 2 and 3. Assuming that Nodes 4 and 6 are neighbours of Node 5, Node 5 can choose both of them as siblings In RPL, the path to be used in a DAG is determined by a certain objective function, which specifies the routing metric and a certain objective. For example, this objective may specify constraints with regard to the power mode used by the nodes.
The period between transmitted DIO messages is computed using the Trickle algorithm . Each node maintains an interval I, which may vary between Imin and Imax. During each interval, a counter k is incremented every time a DIO advertising the same rank and cost as the last one is received from a parent. The timer fires at a random time between I/2 and I. Then, if k is smaller than a certain threshold, the node generates a new DIO message, doubles the value of I and restarts the timer. If at any moment a node receives a DIO message which is not consistent with the node’s own rank, or which advertises a different rank or cost from the previous one, this node sets I to the minimum value and restarts the timer. In consequence, in a stable DAG, the interval grows exponentially towards Imax and the DIO message rate becomes low. When changes in the DAG occur, the DIO messages are generated faster so as to allow a rapid convergence to the new situation. The counter k offers a method to control the amount of DIO overhead.