contikirpl and tinyrpl -- happy together
DESCRIPTION
Regarding RPL ProtocolTRANSCRIPT
-
ContikiRPL and TinyRPL:Happy Together
JeongGil KoJoakim Eriksson
Nicolas TsiftesStephen Dawson-Haggerty
Andreas TerzisAdam Dunkels
David Culler
IP+SN 2011
Monday, April 11,
-
Overview WSN Interoperability Goal/Contributions IPv6 in Contiki and TinyOS Evaluation Lessons Learned Future Work & Conclusions
Monday, April 11,
-
Interoperability of WSN Systems
For widespread commercial adoption of WSN systems (e.g., smart grid), achieving interoperability between different platforms is essential
The performance of interoperable systems are equally important
Monday, April 11,
-
WSNs of Today
WSN systems are mostly single-purpose, homogeneous systems running the same software platform
Incompatible protocols and network architectures
Monday, April 11,
-
IP-based WSNs
The IP architecture has successfully integrated various network technologies into the Internet
With IP-based architectures WSNs can also be fully integrated to the Internet
Theoretically, the IP architecture should allow WSNs to interoperate
Monday, April 11,
-
Contributions
Test IPv6 interoperability between IPv6 stacks of TinyOS and Contiki
IETF 6LoWPAN, IETF RPL, IEEE 802.15.4
Evaluate the performance of the heterogeneous network
Although the two systems may interoperate, variations in implementation choices and system components can affect the end-systems performance
Monday, April 11,
-
Contiki/TinyOS Interoperability
UDP
TinyOS
BLIP
TinyRPL
CSMA
Low Power Control *
IEEE 802.15.4 Radio
UDP
Contiki
uIPv6
ContikiRPL
CSMA
Radio Duty Cycling *
IEEE 802.15.4 Radio
IEEE 802.15.4 Packet Frame Exchange
* Both software stacks have the capability of supporting a low power MAC.However, they are disabled for our evaluations presented in this work.
Application Application
Figure 3. Making Contiki and TinyOS interoperate.
implementation for TinyOS, called TinyRPL. The structureof the two systems is shown in Figure 3.
3.1 ContikiRPLContikiRPL implements the RPL protocol, as specified
in version 18 of the RPL specification [17], and two ob-jective functionsOF0 and MRHOF. ContikiRPL has beensuccessfully tested for interoperability through the IPSO Al-liance interop program, where it was used on three differ-ent platforms and ran over two different link layers, IEEE802.15.4 and the Watteco low-power power-line communi-cation module. ContikiRPL has also been used in two sensornetwork deployments.
The ContikiRPL implementation separates protocol logic,message construction and parsing, and objective functionsinto different modules. The protocol logic module managesDODAG information, maintains a set of candidate parentsand their associated information, communicates with objec-tive function modules, and validates RPL messages at a log-ical level according to the RPL specification. The messageconstruction and parsing module translates between RPLsICMPv6 message format and ContikiRPLs own abstractdata structures. Finally, the objective function modules im-plement an objective function API. To facilitate simple re-placement of and experimentation with objective functions,their internal operation is opaque to ContikiRPL.
ContikiRPL does not make forwarding decisions perpacket, but sets up forwarding tables for uIPv6 and leaves theactual packet forwarding to uIPv6. Outgoing IPv6 packetsflow from the uIPv6 layer to the 6LoWPAN layer for headercompression and fragmentation. The 6LoWPAN layer sendsoutgoing packets to the MAC layer. The default ContikiMAC layer is a CSMA/CA mechanism that places outgoing
Application
UDP / TCP
BLIP TinyRPL
ICMPv6 (DIO, DIS, DAO)
RPL Data Header Validation
Link Result
Route Install
MAC / IEEE 802.15.4 PHY
Data Packets
Data Packets
Data and ControlPackets
Figure 4. The 6LoWPAN/RPL implementations inTinyOS 2.x. TinyRPL implements the control plane ofthe RPL routing protocol and interacts with the packetforwarding plane supported by BLIP.
packets on a queue. Packets from the queue are transmittedin order through the radio duty cycling (RDC) layer. TheRDC layer in turn transmits the packets through the radiolink layer. The MAC layer will retransmit packets until itsees a link-layer acknowledgment from the receiver. If a col-lision occurs, the MAC layer does a linear back-off and re-transmits the packet. Outgoing packets have a configurablethreshold for the maximum number of transmissions.
An external neighbor information module provides linkcost estimation updates through a callback function. Within1 sec of such an update, ContikiRPL recomputes the pathcost to the sink via the updated link, and checks with theselected objective function whether to switch the preferredparent. The link cost reflects the per-neighbor ETX metric,which is calculated using an exponentially-weighted movingaverage function over the number of link-layer transmissionswith = 0.2. The ETX is used to compute the rank for theMRHOF objective function and in parent selection for theOF0 objective function. New neighbor table entries have aninitial ETX estimate of 5. The ContikiRPL neighbor evictionpolicy is to keep neighbors that have good ETX estimatesand low ranks.
3.2 TinyRPLThe RPL implementations in TinyOS mostly consists of
two layers in the TinyOS software stack, BLIP, the TinyOS6LoWPAN/IPv6 stack, and TinyRPL the actual implementa-tion of the RPL specifications.
The Berkeley Low-power IP stack, BLIP, is the de-factostandard IPv6/6LoWPAN stack in TinyOS 2.x. Therefore,the RPL implementations in TinyOS interacts heavily withBLIP interfaces. Specifically, BLIP implements the 6LoW-PAN header compression, 6LoWPAN neighbor discovery
Monday, April 11,
-
Contiki IPv6 Stack uIPv6 + ContikiRPL uIPv6
IPv6 Stack + 6LoWPAN HC/ND/Fragmentation Packet forwarding control
ContikiRPL IETF RPL implementations in Contiki Connects with uIPv6 Modular design OF0, MRHOF Controls routing decisions
Monday, April 11,
-
TinyOS IPv6 Stack BLIP + TinyRPL BLIP
6LoWPAN HC/Fragmentation PPP connection support Packet forwarding management
TinyRPL IETF RPL implementations in TinyOS Connects heavily with BLIP OF0, MRHOF Routing path control
Monday, April 11,
-
Evaluation
Using the two implementations, we test the performance of interoperability
Contiki Simulation Environment MSPsim node level emulator + Cooja Network Simulator
Bit-level accurate simulations for Tmote Sky
Benefits: Accurate simulations for multiple binaries in a single network setting -- essential for interoperability tests
Monday, April 11,
-
Simulation Environment 40 node topology IPI = 8 seconds (unless specified) Unit disk graph model with
Bernoulli loss model 0% loss (100% link PRR), 50% loss (avg
78% link PRR), 100% loss (avg. 56% link PRR) at edge of disk
This channel environment differs from real wireless channels but fits our need to create network dynamism to compare system performance
and DHCPv6 to support the use of IPv6 in the upper lay-ers. BLIP also provides a layered IP forwarding abstrac-tion which allows routing protocols such as RPL to be im-plemented on top of the ICMPv6 engine. In its interac-tion with TinyRPL, BLIP initiates the TinyRPL operationsonce a node is assigned a global IPv6 address. Specifically,as Figure 4 shows, once TinyRPL establishes a route usingthe RPL-related ICMPv6 messages (e.g., when TinyRPL ob-tains knowledge of what the next hop node is for any de-sired/supported destination), the route is added to BLIPsrouting table. The forwarding engine in BLIP makes rout-ing decisions by performing lookups in this routing table.BLIP also supports optional up-calls to the routing layer foreach packet being forwarded; this allows a routing proto-col to implement non-standard tests for packet forwarding.For instance, TinyRPL checks for an optional routing headerto discover the existence of any routing loops [10]. Finally,BLIP manages per-interface message queues which are usedto buffer outgoing packets, necessary to support bursts ofoutgoing packets such as those generated from sending afragmented packet and that caused by head-of-line blockingduring retransmissions.
In addition to the core IPv6-related features, the BLIPsoftware stack also provides a number of components whichallow implementers to work on just one layer rather thanreinventing a large amount of new software. One impor-tant piece for our experiments was the implementation ofthe Point-to-Point protocol (PPP). PPP is a framing and con-figuration protocol for many types of links which provide abyte-stream abstraction
On top of BLIP, TinyRPL is a prototype implementationof the IETF RPL routing protocol in TinyOS 2.x. As a sam-ple implementation, TinyRPL supports the RPL drafts ba-sic mechanisms, while omitting some of RPLs optional fea-tures, such as the security options. The current implemen-tation supports the use of the Objective Function 0 (OF0)[15] or the Minimum Rank Objective Function with Hystere-sis (MRHOF) [8] with the expected number of transmission(ETX) metric. Nevertheless, the modular design of TinyRPLsimplifies the implementation of additional objective func-tions (OFs) or routing metrics. For both supported OFs, anew node is added to the parent set (e.g., the set of nodes withlower rank values in a nodes single hop neighborhood) witha local ETX value of 3.5. For OF0, which is essentially ahop-count-based parent selection metric, the local ETXmea-surements are used as a tie-breaker for potential parents withthe same hop count. When MRHOF is used, the local ETXmeasurements and the parents path-ETX values (included inthe metric container option of the DIO) are used to computea nodes end-to-end path ETX to the root of the DODAG.Due to TinyRPLs modular design, additional OFs can alsobe supported easily.
TinyRPL updates the ETX values after each unicast trans-mission. The radio stack provides information on how manytransmission attempts were made to (un)successfully senda unicast packet (e.g., receiving a proper acknowledgmentwould indicate that the packet was successfully delivered).Using this report, TinyRPL updates its ETX to a node us-ing an exponentially weighted moving average (EWMA) of
Figure 5. The simulation topology consists of 40 nodes,39 sender nodes and one sink. The figure shows a sam-ple topology with both ContikiRPL nodes (lighter nodes)and TinyRPL nodes (darker nodes) coexist. We show thecommunication range of the sink (node 1).
= 0.5. Whenever a new ETX is set for a node in the parentset, TinyRPL re-evaluates the elements in its potential parentset to select the node with the best metric to be its desiredparent in the DODAG.
While implementing the basic features as specified in theIETF RoLL working groups proposed standards, TinyRPLtakes a pull-based re-connection scheme when a node istemporarily disconnected from the DODAG for any reason.Specifically, in TinyRPL, when a node is disconnected fromthe DODAG, the nodes local DIO trickle timer is reset andthe rank of the node is set to MAX RANK (e.g., 0xFFFF). Thisaction will result in triggering a multicast DIO transmissionwithin a short amount of time (e.g., minimum Trickle-timerinterval). When neighboring node receive these DIOs indi-cating a MAX RANK, they treat this message as a unicast DISmessage. In other words, the reception of a DIO with MAXRANK initiates a single DIO transmission without resettingthe Trickle timer. This implementation decision comes fromthe fact that a multicast DIS message (transmitted for seekingnew parent nodes) MUST reset the Trickle-timer for all thenodes that receive the DIS message; thus, heavily increasingthe routing overhead. On the other hand, initiating a unicastDIS message to all previously-known parents can cause lessoverhead but will prevent a node from finding new potentialparents (e.g., which were not previously known). Therefore,TinyRPLs pull-based DODAG recovery scheme is usedas a way to minimize the amount of routing overhead whileproviding the disconnected node with a good visibility of itsneighborhood.
4 EvaluationWe evaluate ContikiRPL and TinyRPL in two steps. We
first study the performance of the two implementations inisolation, proving that both implementations achieve highand comparable performance. We then proceed to running
Monday, April 11,
-
Contiki Evaluation
0.5
0.6
0.7
0.8
0.9
1
1 2 3 4 5 6 7 8Pa c
k et R
e ce p
t i on
R at i o
( PR R
)
Inter-packet Interval (sec)
Avg. Link PRR 100%Avg. Link PRR 78%Avg. Link PRR 56%
Monday, April 11,
-
TinyOS Evaluation
0.5
0.6
0.7
0.8
0.9
1
1 2 3 4 5 6 7 8Pa c
k et R
e ce p
t i on
R at i o
( PR R
)
Inter-packet Interval (sec)
Avg. Link PRR 100%Avg. Link PRR 78%Avg. Link PRR 56%
Monday, April 11,
-
When TinyOS and Contiki First Met
0.7 0.75 0.8
0.85 0.9
0.95 1
AllTinyRPL
AllContikiRPL
P ac k
e t R
e ce p
t i on
R at i o
( PR R
)
Avg. Link PRR 100%Avg. Link PRR 78%Avg. Link PRR 56%
TinyOS and Contiki with their original settingsMonday, April 11,
-
Why?
Same RPL-related parameters -- distributed using root-initiated DIOs
RPLs operations does not vary over different implementations
PRR decrease is not the effect of RPL itself!
Monday, April 11,
-
Effect of Lower Layers
Network layer: Message buffer sizes vary
MAC-layer Retransmission Timers/Limits vary
Need to align parameter values across all layers of the software stack
Monday, April 11,
-
TinyOS/Contiki Interoperability
0.7 0.75 0.8
0.85 0.9
0.95 1
AllTinyRPL
AllContikiRPL
P ac k
e t R
e ce p
t i on
R at i o
( PR R
)
Avg. Link PRR 100%Avg. Link PRR 78%Avg. Link PRR 56%
Monday, April 11,
-
Need for deeper investigation!
0 200 400 600 800
1000 1200
AllTinyRPL
AllContikiRPL
N um
b er o
f Pa r
e nt C
h an g
e s TinyRPL as RootContikiRPL as Root
The unexpected can happen! Even if PRR performance is high, we should
pay careful attention to other metrics as well.Monday, April 11,
-
Lessons Learned (1) Maintain the lowest common denominator
Implementation specific optimizations can interfere with the interoperability process
Leverage simulations Testbed experiments can show more realistic results but
have temporal and topological limitations
Visibility and control of the environments helps to understand the functionality
E.g., Average of 300 runs per PRR graph
Monday, April 11,
-
Lessons Learned (2)
Examine the performance at all layers All layers of the protocol stack will affect the overall
performance of interoperating systems
Monday, April 11,
-
Future Work
Point-to-Multipoint, Point-to-Point Traffic
Other objective functions Effect of radio duty cycling
Monday, April 11,
-
Conclusion IPv6/RPL interoperability and the
performance of the heterogeneous network between TinyOS and Contiki look promising
Interoperability testing is not enough and we should consider the performance of the overall system which is affected by multiple-layers in the protocol stack
Monday, April 11,
-
Questions
JeongGil Ko [email protected]
Monday, April 11,