ContikiRPL and TinyRPL:

Happy Together
JeongGil Ko
Joakim Eriksson
Nicolas Tsiftes
Stephen Dawson-Haggerty
Andreas Terzis
Adam 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 structure
of the two systems is shown in Figure 3.
3.1 ContikiRPL
ContikiRPL implements the RPL protocol, as specied
in version 18 of the RPL specication [17], and two ob-
jective functionsOF0 and MRHOF. ContikiRPL has been
successfully 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, IEEE
802.15.4 and the Watteco low-power power-line communi-
cation module. ContikiRPL has also been used in two sensor
network deployments.
The ContikiRPL implementation separates protocol logic,
message construction and parsing, and objective functions
into different modules. The protocol logic module manages
DODAG information, maintains a set of candidate parents
and their associated information, communicates with objec-
tive function modules, and validates RPL messages at a log-
ical level according to the RPL specication. The message
construction and parsing module translates between RPLs
ICMPv6 message format and ContikiRPLs own abstract
data 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 per
packet, but sets up forwarding tables for uIPv6 and leaves the
actual packet forwarding to uIPv6. Outgoing IPv6 packets
ow from the uIPv6 layer to the 6LoWPAN layer for header
compression and fragmentation. The 6LoWPAN layer sends
outgoing packets to the MAC layer. The default Contiki
MAC 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 Control
Packets
Figure 4. The 6LoWPAN/RPL implementations in
TinyOS 2.x. TinyRPL implements the control plane of
the RPL routing protocol and interacts with the packet
forwarding plane supported by BLIP.
packets on a queue. Packets from the queue are transmitted
in order through the radio duty cycling (RDC) layer. The
RDC layer in turn transmits the packets through the radio
link layer. The MAC layer will retransmit packets until it
sees 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 congurable
threshold for the maximum number of transmissions.
An external neighbor information module provides link
cost estimation updates through a callback function. Within
1 sec of such an update, ContikiRPL recomputes the path
cost to the sink via the updated link, and checks with the
selected objective function whether to switch the preferred
parent. The link cost reects the per-neighbor ETX metric,
which is calculated using an exponentially-weighted moving
average function over the number of link-layer transmissions
with = 0.2. The ETX is used to compute the rank for the
MRHOF objective function and in parent selection for the
OF0 objective function. New neighbor table entries have an
initial ETX estimate of 5. The ContikiRPL neighbor eviction
policy is to keep neighbors that have good ETX estimates
and low ranks.
3.2 TinyRPL
The RPL implementations in TinyOS mostly consists of
two layers in the TinyOS software stack, BLIP, the TinyOS
6LoWPAN/IPv6 stack, and TinyRPL the actual implementa-
tion of the RPL specications.
The Berkeley Low-power IP stack, BLIP, is the de-facto
standard IPv6/6LoWPAN stack in TinyOS 2.x. Therefore,
the RPL implementations in TinyOS interacts heavily with
BLIP interfaces. Specically, 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
Benets: 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 specied)
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 ts 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 operations
once a node is assigned a global IPv6 address. Specically,
as Figure 4 shows, once TinyRPL establishes a route using
the 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 BLIPs
routing 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 for
each 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 header
to discover the existence of any routing loops [10]. Finally,
BLIP manages per-interface message queues which are used
to buffer outgoing packets, necessary to support bursts of
outgoing packets such as those generated from sending a
fragmented packet and that caused by head-of-line blocking
during retransmissions.
In addition to the core IPv6-related features, the BLIP
software stack also provides a number of components which
allow implementers to work on just one layer rather than
reinventing a large amount of new software. One impor-
tant piece for our experiments was the implementation of
the Point-to-Point protocol (PPP). PPP is a framing and con-
guration protocol for many types of links which provide a
byte-stream abstraction
On top of BLIP, TinyRPL is a prototype implementation
of 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 TinyRPL
simplies the implementation of additional objective func-
tions (OFs) or routing metrics. For both supported OFs, a
newnode is added to the parent set (e.g., the set of nodes with
lower rank values in a nodes single hop neighborhood) with
a local ETX value of 3.5. For OF0, which is essentially a
hop-count-based parent selection metric, the local ETX mea-
surements are used as a tie-breaker for potential parents with
the same hop count. When MRHOF is used, the local ETX
measurements and the parents path-ETX values (included in
the metric container option of the DIO) are used to compute
a nodes end-to-end path ETX to the root of the DODAG.
Due to TinyRPLs modular design, additional OFs can also
be supported easily.
TinyRPL updates the ETX values after each unicast trans-
mission. The radio stack provides information on how many
transmission attempts were made to (un)successfully send
a unicast packet (e.g., receiving a proper acknowledgment
would 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 gure shows a sam-
ple topology with both ContikiRPL nodes (lighter nodes)
and TinyRPL nodes (darker nodes) coexist. We show the
communication range of the sink (node 1).
=0.5. Whenever a new ETX is set for a node in the parent
set, TinyRPL re-evaluates the elements in its potential parent
set to select the node with the best metric to be its desired
parent in the DODAG.
While implementing the basic features as specied in the
IETF RoLL working groups proposed standards, TinyRPL
takes a pull-based re-connection scheme when a node is
temporarily disconnected from the DODAG for any reason.
Specically, in TinyRPL, when a node is disconnected from
the DODAG, the nodes local DIO trickle timer is reset and
the rank of the node is set to MAX RANK (e.g., 0xFFFF). This
action will result in triggering a multicast DIO transmission
within a short amount of time (e.g., minimum Trickle-timer
interval). When neighboring node receive these DIOs indi-
cating a MAX RANK, they treat this message as a unicast DIS
message. In other words, the reception of a DIO with MAX
RANK initiates a single DIO transmission without resetting
the Trickle timer. This implementation decision comes from
the fact that a multicast DIS message (transmitted for seeking
new parent nodes) MUST reset the Trickle-timer for all the
nodes that receive the DIS message; thus, heavily increasing
the routing overhead. On the other hand, initiating a unicast
DIS message to all previously-known parents can cause less
overhead but will prevent a node from nding new potential
parents (e.g., which were not previously known). Therefore,
TinyRPLs pull-based DODAG recovery scheme is used
as a way to minimize the amount of routing overhead while
providing the disconnected node with a good visibility of its
neighborhood.
4 Evaluation
We evaluate ContikiRPL and TinyRPL in two steps. We
rst study the performance of the two implementations in
isolation, proving that both implementations achieve high
and 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 8
P
a
c
k
e
t

R
e
c
e
p
t
i
o
n

R
a
t
i
o

(
P
R
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 8
P
a
c
k
e
t

R
e
c
e
p
t
i
o
n

R
a
t
i
o

(
P
R
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
All
TinyRPL
All
ContikiRPL
P
a
c
k
e
t

R
e
c
e
p
t
i
o
n

R
a
t
i
o

(
P
R
R
)
Avg. Link PRR 100%
Avg. Link PRR 78%
Avg. Link PRR 56%
TinyOS and Contiki with their original settings
Monday, 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
All
TinyRPL
All
ContikiRPL
P
a
c
k
e
t

R
e
c
e
p
t
i
o
n

R
a
t
i
o

(
P
R
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
All
TinyRPL
All
ContikiRPL
N
u
m
b
e
r

o
f

P
a
r
e
n
t

C
h
a
n
g
e
s
TinyRPL as Root
ContikiRPL 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 specic 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
Trafc
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
jgko@cs.jhu.edu
Monday, April 11,