rpl layer in contiki with the z1 slide 1 lower layers part...

Lower Layers PART 3:

RPL layer in Contiki with the Z1

1

Remark: all numerical data refer to the parameters defined in IEEE802.15.4 for

32.5 Kbytes/s transmission in the 2.4 GHz frequency band.

Kris Steenhaut - Jacques Tiberghien

Routing in Wireless Sensor and Actuator Networks

2

• Almost all WSANs use multi-hop communication, thus requiring routing of messages through the network.

• Power grows at least as the square of the distance, but more often as the 4th power.

d d

P ~ (2d)2 = 4d2

P ~ d2 + d2 = 2d2

Routing in WSANs

Communication needs: 1. Collect : M2PFrom sensors to gatewayTo collect field data2. Distribute : P2MFrom gateway to sensorsTo download commands, parameters and software.3. Sensor to Sensor : P2PFrom one sensor to an otherTo run distributed data processing algorithms.

The Internet

Sensors

Radio links

Gateway(sink node)

The collect function is by far the most important, as most of the Wireless Sensor Networks are mainly intended for collecting data from the field. Power economy is often essential for extending lifetime and/or reducing maintenance costs. Latency can be an issue when the sensors can generate alarms. In most Wireless Sensor Networks the distribute protocol is only used for (exceptional) maintenance functions. Sensor to sensor communication is gaining importance because, as nodes become more powerful, local data pre-processing and data clustering can reduce the volume of data to send to the gateway. In Wireless Sensor and Actuator networks, the Distribute function is used to give commands to local actuators. Latency and reliability can be important issues. Some references: Philip Levis, Eric Brewer, David Culler, David Gay, Sam Madden, Neil Patel, Joe Polastre, Scott Shenker, Robert Szewczyk, Alec Woo: The Emergence of a Networking Primitive in Wireless Sensor Networks, Communications of the ACM, Volume 51, Number 7, July 2008.

Contiki Communication stacksConceptual view

M2P / P2MP2P

TCP/UDP

IP+RPL

6LOWPAN

MAC

RDC

Physical Layer

P2P + BROAD

M2P

COLLECT

Rime UIP6

Services

16 bit addresses 64 bit addresses

The Net subsystem of Contiki implements the communications facilities. This slide shows the simplified layered structure. Two different communication stacks are available: rime and UIP6. The rime stack offers simple, Contiki specific, communication facilities, including single-hop unicast (P2P) or broadcast (BROAD) and multi-hop multipoint to point (M2P) functionality. The UIP6 stack offers, multi-hop multipoint to point (M2P), point to multipoint (P2M) and point to point (P2P) functionality via the RPL routing protocol. By bypassing the transport and network layers, single hop unicast (P2P) and broadcast (BROAD) functionality is also available. The MAC, RDC and physical layers are common to both stacks, but their code contains many if(IPV6) and if(!IPV6) statements. The RPL routing protocol uses additional information about links gathered by the MAC and RDC layers. The most common example of this is the Estimated number of Transmissions needed to cross a specific link which is commonly used as a cost function for links.

IPv6 on Low Power and Lossy Networks?

5

Applications

TCP/UDP

MAC&PHY

IPv6

Applications

TCP/UDP

IEEE 802.15.4

RPL

6LowPan

A

GFE

I J K

B CD

H

L M

The Internet

The Low Power network is just one subnetThe sink node plays the role of a router

It is attractive to integrate low power and lossy networks in the internet, as it makes their access from anywhere and the development of applications much simpler. As these networks will often have a large number of nodes, only the IPv6 internet protocol has provisions for enough addresses. However, as low power networks have limitations, such as very limited memory capacity in the nodes, that other parts of the internet don’t have, their integration will need a specific architecture and specific protocols. The low power network will be considered as a specific subnet, connected to the internet through its sink node(s), which behave(s) like routers between the subnet and the internet. Reference : JeongGil Ko, Andreas Terzis, Stephen Dawson-Haggerty, David E. Culler, Jonathan W. Hui and Philip Levis: Connecting Low-Power and Lossy Networks to the Internet, IEEE Communications Magazine, April 2011, pp.96-101.

6LowPan – Why ?

6

TCP/UDP

IEEE 802.15.4

RPL

6LowPan

• Frame length : IPv6: <= 1280 bytes; IEEE 802.15.4: <= 81 bytes.Frame fragmentation & defragmentation

• Header length : IPv6 header >= 40 bytes; TCP header = 20 bytes, … No version field, no flow label, One subnet : 64 instead 128 bit addresses,Header compression

• Connectivity inside the subnet :• Single broadcast domain vs. multi-hop connectivityRoute-over architecture (see next slide)

001 resTLA SLANLA

3 13 8 24 18

INT

64

IPv6 address :

As specific protocols for low power and lossy networks using IPv6, there is first an adaptation layer between the network and the MAC layer. This layer is needed for several reasons: - first there is the length of the MAC frames: max 1280 bytes according to IPv6, while in

some configurations, IEEE 802.15.4 frames can be as short as 81 bytes. 6LowPan has to provide facilities to fragment and rebuild frames.

- Second, there is the size of the IPv6 headers. An IPv6 header, without extensions requires 40 bytes. If one adds a TCP header (20 bytes) to that, there are, in the shortest IEEE 802.15.4 frames just 21 bytes left for data. Fortunately, in the context of low power and lossy networks, lots of redundant or useless information can be removed from the headers. The version field is not needed as 6LowPan uses, by definition, v6. The flow label is also useless as no connection oriented, high-throughput data flows will be established in a low power and lossy network. As the entire low power network is considered as a single IPv6 subnet, the 64 most significant bits of the IPv6 addresses, which identify the subnet, are not needed for addressing inside the subnet.

- Third, an IPv6 subnet generally constitutes a single broadcast domain, while a low power and lossy network offers, most often, multi-hop connectivity, with the need for routing frames through the subnet. The RPL routing protocol has been proposed for this purpose and modified versions of the IPv6 Neighbor Discovery and configuration protocols can be used with RPL to integrate a low power and lossy network in an IPv6 internet.

Routing Protocol for Low Power and Lossy Networks

• RPL origin: “The Internet of things”.

– IETF working group for IPv6 routing.

– None of the existing protocols is adequate!

– New design combining interesting ideas of all.

• RPL Basic Mechanisms

– Routing based upon one or more Destination Oriented Directed Acyclic Graphs (DODAGs)

• Optimal routes between sink and all other nodes for both the collect and distribute data traffics.

• Redundant equivalent routes are kept for reliability in case of link or node failure.

– Multiple DODAGs if different optimisation criteria.

7

Some references: Internet Engineering Task Force (IETF), Request for Comments: 6550 - RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks, ISSN: 2070-1721 , March 2012. Internet Engineering Task Force (IETF), Request for Comments: 6551 - Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks, ISSN: 2070-1721, March 2012. Internet Engineering Task Force (IETF), Request for Comments: 6552 - Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL), 2070-1721, March 2012.

RPL: the DODAG

8

F

B

K

Flo

atin

g D

AG

J

A “floating DAG”

has no connection

with the sink. E.g :

failure of link A-B

A “grounded

DODAG” contains

the sink node and

offers routes from

all its nodes to

that sink node.

A

H

C

G

ED

I

NML

Grounded

DODAG

DODAG =

Destination

Oriented,

Directed,

Acyclic

Graph..

Routing in the RPL protocol is based upon the DODAG concept. It is a distributed data structure build-up and maintained during the WSAN usage. It is a kind of distributed routing table, build by the RPL algorithm and used for routing frames through the network. • DODAG = Destination Oriented Directed Acyclic Graph

Destination Oriented = All routes end in a Root Directed: one way edges Acyclic: no loops Nodes and links map into to those of the physical network

• Root = Node with no outgoing links • Roots interconnect the low power and lossy network with external networks such as

the Internet. DODAG roots correspond to the “sink” nodes traditionally used in the WSAN literature.

DODAG: neighbors and parents

9

The neighbors of a node are all the

nodes that can be reached via a single-

hop radio link.

The neighbors of G are C,D,H and L

A

H

C

G

ED

I

NML

Grounded

DODAG

The parents of a node are all

the neighbors that are on a

possible route from the node

to the sink.

Parents of G are C,D and H.

The preferred parent of a node is the

neighbor that is on the “best” route

from the node to the sink.

The preferred parent of G is H (will

be explained in a later slide).

To understand the building of a DODAG the concepts of neighbor, parent and preferred parent need to be introduced: - In a WSAN nodes communicate by radio. The neighbors of a node are all the nodes that

can communicate via single-hop radio links with that node. (To simplify this introduction, all radio links are supposed symmetric).

- A DODAG defines routes from all nodes to the root. The parents of a node are the neighbors of that node that belong to such a route. When a node has to send a message to the route, it suffices that it sends it to one of its parents.

- The quality of a route can be defined according to criteria dependent on the application (“Routing Metric”). A node should select among its parents the one that ensures the “best” route to the root, according to the selected criterion. This parent is the “preferred parent”.

- A node will always use its preferred parent to send messages to the route, unless the preferred parent is unavailable. In this case the node can use its other parents as back-up.

DODAG: the Routing Metric

10

1 2 -> 61

5 1

1

13

511 1

C1

D1

E4

G3

H2

I3

L4

M3

N3

A0

Each link and each node has an

associated cost, defined in terms of

the specific Routing Metric.

In this example nodes have no cost.

Each node computes the cost of the

best route to the root by adding to

the cost of the preferred parent the

cost to reach that preferred parent

3

Of course, no loops can be allowed

in the routing scheme. The situation

shown here could occur if suddenly

the cost of the link EA increases

For selecting the best route to the sink a “Routing Metric” is defined. This metric is similar to the “distance” parameters used in algorithms like Distance Vector. It gives the cost for reaching the sink from a specific node. The routing metric normally takes into account, depending on the application, not only the cost of traveling along a link, but also some node specific dynamic parameters such as the state of the battery. When a node has to select between several parents its preferred parent, that selection should minimize the routing metric. Of course, no loops may exist in the routes towards the root, because they would make the root unreachable from certain nodes.

DODAG: the RANK of nodes

11

1 21

5 11

511 1

C1/1

D1/1

E1/2

G3/3

H2/2

I2/3

L4/4

M3/3

N3/3

A0/0

3

1

All nodes have a rank, which is

some measure of the distance

between node and root. In this

example it is simply the hop-count.

To prevent the creation of routing

loops, all parents of a node must

have a rank lower than the rank of

that node. When a node joins the

DODAG, its rank is computed from

the data provided in the DIO

message. However a node is

authorized to increase its rank to

expand the set of its parents. In

this example G has increased its

rank from 2 to 3 in order to add H

to its parents.

To avoid creation of loops in the DODAG, the notion of “rank” has been introduced. In a DODAG, all nodes have a rank. This rank expresses in some way the distance from the node to the sink. This distance could be a simple hop-count or it could be a much more complex function, such as the average number of times a message needs to be retransmitted by radio to reach the root. The rank of a node is computed by an “Objective Function” (OF, not defined in the standard, because it should be specific for the application) , that takes into account the properties of the nodes and the links along the route between the node and the root. • The rank of a node should always be higher than the rank of its parents (this prevents

the creation of loops) • In older versions of the proposal nodes with the same rank were called “siblings”. • A node can voluntarily increase its rank in order to increase the set of its parents. • In these introductory slides, rank is considered equal to the hop count to the root.

RPL : Building the DODAG (1)

12

5 11

511 1

G3/3

H2/2

I2/3

L4/4

M3/3

N3/3

3

1

1 21

C1/

D1/

E1/

A0/0

The root initiates the building of a

new DODAG by sending DIO

messages to all its neighbors.

Nodes C,D and E join the DODAG.

and set their rank = 1.

Building a new DODAG is initiated by the root node of that DODAG. It assigns a unique DODAG identity to the new DODAG and sends DODAG Information Object (DIO) messages to all its neighbors. Each DIO messages carries the identity of the new DODAG, the rank of its sender (0 by definition for the root), the cost to reach the root from its sender (0 by definition for the root itself) as well as data about the link between its sender and its destination. The nodes receiving these DIO messages join the new DODAG. Their rank is, with the simple hop-count Objective Function used for this example, 1 as they are at one hop from the root.


13

511 1

L M N

Nodes C,D and E have only one

parent, A. It is automatically their

preferred parent.

5 11

G H I

1 21

C1/1

D1/1

E1/2

A0/0

3

1

Nodes C,D and E set their cost

function

• The neighbors of the root have each one parent, the root, and their cost to the root is determined by the cost of the link from the root. Obviously the root is also their preferred parent.


14

511 1

L M N

Node A ignores the DIO

messages because they

come from neighbors with a

higher rank.

Nodes G,H and I join the

DODAG. and set their rank.

1 21

5 11

C1/1

D1/1

E1/2

G2/

H2/

I2/

A0/0

3

1

Nodes C,D and E start sending DIO

messages to their neighbors

After receiving DIO messages from the root and updating their state, nodes C,D and E send DIO messages to their neighbors: C sends a message to A and to G, D to A,G and H while E sends one to A and I. A ignores all messages it receives because they come from nodes with a rank higher than the rank of their destination. After receiving DIO messages nodes G,H and I join the new DODAG and set their rank value to 2.


15

511 1

L M N

Nodes G,H and L set up their list of

parents and select a preferred parent

5 11

G2/4

H2/2

I2/3

3

1Nodes G,H and L update their cost

figures

1 21

C1/1

D1/1

E1/2

A0/0

At this point the parents of G are C and D, with D as preferred parent. H and I each have only one parent, respectively D and E, wich become automatically preferred parents. G,H and I can now update their cost figures by adding to the cost of their preferred parent the cost of the link towards that preferred parent.


16

511 1

L3/

M3/

N3/

Nodes C,D and ignore the

DIO messages from G,H

and I, because they come

from nodes with a higher

rank

5 11

G2/4

H2/2

I2/3

3

1

Nodes G,H and L send DIO

messages to all their neighbors

1 21

C1/1

D1/1

E1/2

A0/0

Nodes G,H and L join the

DODAG and set their rank

Nodes G,H and I now start sending DIO messages to their neighbors. G sends one to C,D,H and L. H sends one to D,G,M and N. I just sends one to E and N. C,D and E ignore the DIO messages they receive because the come from a node with a higher rank. L,M and N join the DODAG and set their rank to 3.


17

511 1

L4/

M3/

N3/

5 11

G3/3

H2/2

I2/3

3

1

Nodes G discovers that using

neighbor H as a preferred parent

would result in a better cost figure,

but H has the same rank as G and

therefore can not be a parent of G.1 2

1

C1/1

D1/1

E1/2

A0/0

G now has to send DIO messages

to its neighbors, to inform them of

the change in rank.

Node G decides to increment its

rank to be allowed to adopt H as a

parent.

H can not become a parent of G, nor G a parent of H because G and H have the same rank but G discovers that the cost via H (3) is lower than the cost via its preferred parent D (4). Therefor G increments its rank by one unit. Now H can become a parent of G and it even beciomes its preferred parent. This change in its rank obliges G to send again DIO messages to its neighbors C,D,H and L. C,D and H ignore these messages because they come from a node with a higher rank. L will increment its own rank to 4.


18

511 1

L4/4

M3/3

N3/3

5 11

G3/3

H2/2

I2/3

3

1

Now nodes L,M and N can select

their parents and their preferred

parent.

1 21

C1/1

D1/1

E1/2

A0/0

At this stage nodes L,M and N can set up their parents list and select their preferred parents. This completes the building of the DODAG as now all nodes are included.

RPL: Messages for routing

19

A

HF

C

G

EDB

I

NMLK

Grounded

DODAG

Flo

atin

g D

AG

J

DA

O

1 1 1

1 1 1

DIO

DIS

DIO (Destination Information Object) Transmitted downward by root and nodes in the DODAG for discovery, construction and maintenance.

DAO (Destination Advertisement Object) Propagates upwards destination information along the DODAG to populate the routing tables of ancestor nodes in support of the distribute traffic.

DIS (DODAG Information Solicitation) Discovers DODAGs in the neighborhood for grounding a floating DODAG. A DIS message is answered by a DIO

RPL: Collect, Distribute and P2P routing

20

A

H

C

G

ED

I

NML

1 1 1

1 1 1

A

H

C

G

ED

I

NML

1 1 1

1 1 1

A

H

C

G

ED

I

NML

1 1 1

1 1 1

Collect (M2P) Distribute (P2M) P2P

The collect protocol is used to collect data from all the nodes and to send it to the sink node (A). The routing simply consist in following the DODAG. The distribute protocol is just the opposite: data from the sink is sent to specific nodes. When connected to the DODAG, each node has sent to the sink a DAO message containing the name of its starting point. This message is augmented in each traversed node with the information necessary to retrace the itinerary in the opposite direction. These messages are kept in the sink and are used to establish the route of messages to be distributed. In the Peer to Peer mode, a message is first sent to the sink, and from there to its destination. If the nodes have enough memory to keep locally the information contained in the DOA messages, there is no need to go by the sink if the collect and distribute itineraries have common links.

RPL : Maintaining the DODAG

21

Basic mechanism:Each node sends DIO messages to its neighbors

When they receive DIO messages from their parentsWhen their local trickle timer expires

These DIO messages inform childrenAbout nodes leaving the DODAG (rank = ∞)About rank and/or cost changes

These DIO messages can cause DODAG repairs

The trickle timer is a timer with variable period.Whenever a change occurs the period decreasesIf no changes the period increases

DODAGs are maintained by means of DIO messages. These messages, issued by the root or by any node inform the children of each node of any changes that have occurred between that node and the root. This can be simple variations in the value of the cost function, it can be more important changes that cause a node to change its rank, possibly forcing other nodes to also change their rank (children need to have a rank higher than their parents). When a node wants to leave a DODAG (for instance when its battery gets low), it broadcasts an infinite rank, forcing all children to choose other parents. The trickle timers ensure that the DODAG structure is periodically checked by means of DIO messages. If links and nodes are stable the period of the trickle timers increases progressively up to a maximum value. When changes occur, that period returns to its minimum value, to ensure fast adaptations of the DODAG to new conditions.

The ETX cost function

22

ETX = Estimated number of transmissions from x to y.= Number of times a frame needs to be transmitted

over a link before being acknowledged.= (dxy x dyx)

-1 dxy = success rate from x to y.

Each node broadcasts precisely once per second a short message, each receiver counts during 10 seconds the number of broadcasts it receives from each neighbor.

dxy = (number of frames received from x by y) / 10

In the Contikimac RDC protocol, the number of times a frame is retransmitted is counted and averaged. This is used as ETX.

The ETX cost function has been introduced in 2003 and is considered a good cost function for multi-hop radio networks. It can easily be measured during network operation, it gives a realistic estimation of the amount of energy used for transmission. Reference: Douglas S. J. De Couto, Daniel Aguayo, John Bicket and Robert Morris: A High-Throughput Path Metric for Multi-Hop Wireless Routing, in the proceedings of MobiCom ’03, September 14–19, 2003, San Diego, California, USA.

Mac Layer optimization for RPL

23

511 1

L4/4

M3/3

N3/3

5 11

G3/3

H2/2

I2/3

3

1

1 21

C1/1

D1/1

E1/2

A0/0

Wake-up = t0 - δt

Wake-up = t0 - 2δt

Wake-up = t0 - 3δt

Wake-up = t0 – 4δtWake-up = t0 - 3δt

Synchronize receiver wake-ups to minimize latency along specific routes.

If mostly collect or distribute traffic exists, most messages follow a predictable path determined by a DODAG. This could be used to minimize message latency in a network using Radio Duty Cycling to optimize power usage. The DMAC protocol proposes to schedule the wake up periods of receivers along the paths taken by messages, so that on a multi-hop route, waiting times for receiver wake-ups should be minimized. The Contikimac protocol could be modified to schedule receiver wake-ups along DODAG routes to minimize wake up waiting. For collect traffic, the wake-up times should follow the ranks of the nodes. Reference: Gang Lu, Bhaskar Krishnamachari, Cauligi S. Raghavendra: An Adaptive Energy-Efficient andLow-Latency MAC for Data Gathering in Wireless Sensor Networks, Proceedings of the 18th International Parallel and Distributed Processing Symposium (IPDPS’04), 2004.

rpl layer in contiki with the z1 slide 1 lower layers part...

Documents