-
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,
