Low-power Interoperability for the IPv6-based Internet of Things

Adam Dunkels, Joakim Eriksson, Nicolas Tsiftes

Swedish Institute of Computer Science
{adam,joakime,nvt}@sics.se

1 Introduction Layer Example protocol

The Internet of Things requires interoperability and low Application HTTP, CoAP
power consumption, but interoperability and low power con-
sumption have thus far been mutually exclusive. This talk Transport TCP, UDP
outlines the challenges in attaining low power operation for
the IPv6-based Internet of Things, how this affects interop- Network IPv6, RPL, 6lowpan
erability, and what must be done to combine the two.
Research and standardization has come a long way to- MAC CSMA

wards providing efficient protocols and specifications for

Radio duty cycling X−MAC/ContikiMAC
IPv6 for the Internet of Things. The efforts of the IETF 6low-
pan [9] and ROLL [13] working groups and the the IPSO
Link IEEE 802.15.4
Alliance [3] have resulted in protocols and interoperability
testing frameworks for those protocols. One recent result Figure 1. The low-power IPv6 stack consists of the stan-
is the IETF RPL IPv6 routing protocol for low-power, lossy dard IPv6 protocols at the network layer and transport
networks which was recently moved towards a standard RFC layers, and of new protocols from the network layer and
document [12, 13]. down.
The first step towards interoperability for the Internet of
Things is interoperability at the IPv6 layer. In a joint project
between Cisco, Atmel, and SICS, the Contiki operating sys- as IEEE 802.15.4 are simpler and have a lower output power
tem and its uIPv6 stack became the first low-power wireless than radios such as WiFi and Bluetooth. To attain a lifetime
operating system to provide a certified IPv6 Ready stack [4]. of years of batteries, however, the radio must be efficiently
The second step is interoperability at the routing layer. duty cycled so that it is kept off for most of the time. But
The RPL protocol provides a framework for interoperable radio duty cycling creates a new set of dynamics for which
routing. Recent versions of Contiki contains ContikiRPL, existing protocols have not been designed [2, 7].
one of the first implementations of the IETF RPL routing Existing interoperability experiments have not taken
protocol [6, 11]. ContikiRPL has previously been success- power consumption into account, but have been performed
fully tested for interoperability through the IPSO Alliance with an always-on radio layer. Contiki provides a set of ra-
interop program, where it was used on three different plat- dio duty cycling mechanisms such as ContikiMAC [2], X-
forms and ran over two different link layers, IEEE 802.15.4 MAC [1], and LPP [8]. By running uIPv6 and ContikiRPL
and the Watteco low-power power-line communication mod- over ContikiMAC, we have been able to attain as low power
ule. In a joint project between Johns Hopkins University, consumption with IPv6/RPL as with specialized sensor net-
UC Berkeley, and SICS, we have demonstrated interoper- work protocols such as Contiki Collect. Our results show
ability between the RPL implementations in Contiki and that the radio can be kept off more than 99% of the time
TinyOS [6]. Providing interoperability between two differ- while attaining full IPv6 communication, providing years of
ent operating systems was not without challenges: our re- lifetime on batteries. But these low-power results have been
sults show that the resulting system performance depends on achieved in a Contiki-only environment. Achieving full low-
numerous implementation-specific factors and that interop- power interoperability has yet to be done.
erability therefore is not necessarily a binary property. 2 IPv6 for Low-Power Wireless
The next step for interoperability is low-power interoper- The IPv6 stack for low-power wireless follows the IP tra-
ability. Existing protocols such as RPL are designed for run- ditional architecture but with a set of new protocols from the
ning over radio layers such as IEEE 802.15.4. Radios such network layer and down, as shown in Figure 1. Header com-
 Send data packets until ack received
pression is provided by the 6lowpan adaptation layer. Rout-
ing for low-power and lossy networks is provided by the RPL Sender D D D D A Reception window
protocol. D Data packet
Receiver
The headers of IPv6 packets tend to be large compared D A A Acknowledgement packet
to the typical amount of data in low-power wireless net-
Transmission detected
works. The header size adds to the energy required to trans-
Figure 2. ContikiMAC, from Dunkels et al. [2].
mit and receive packets and also increases the probability of
bit-errors in transit. To reduce the size of the headers, IP net- Send first data packet when receiver is known to listen
works traditionally use a technique called header compres-
Sender Reception window
sion. For low-power wireless networks, the IETF 6lowpan D D A

D Data packet
group has specified a header compression mechanism for Receiver D A A Acknowledgement packet
low-power wireless networks based on the IEEE 802.15.4
standard [9]. Because the IEEE 802.15.4 maximum frame Transmission detected
size is small (127 bytes), the group also devised a link-layer Figure 3. ContikiMAC sender phase-lock.
fragmentation and reassembly mechanism.
Low-power wireless networks tend to be multi-hop since Send data packets during entire period
the physical range of each device is small. To reach de-
Sender D D D D D D Reception window
vices in a multi-hop network, a routing protocol is needed.
In the IP architecture, routing occurs at the IP level. For D Data packet
Receiver D
low-power wireless networks, the IETF ROLL group have
designed a routing protocol called RPL [12, 13]. RPL is op-
Transmission detected
timized for the many-to-one traffic pattern that is common
Figure 4. ContikiMAC broadcast.
in many low-power wireless applications but also supports
any-to-any routing. In RPL, a root node builds a directed
acyclic graph through which IPv6 packets are routed. Since To allow low-power wireless devices to actively partici-
different low-power wireless applications have different de- pate in a low-power wireless network while maintaining a
mands on the network traffic, RPL supports different metrics low power consumption, the radio transceiver must be duty
by which the graph can be constructed. Likewise, after the cycled. With radio duty cycling, the radio is switched off
graph has been constructed, different parent selection strate- most of the time, but switched on often enough to allow the
gies are supported. In RPL, these are called objective func- device to receive transmissions from other nodes. Over the
tions. years, many different duty cycling schemes have been de-
At the MAC, radio duty cycling, and link layers, the signed [1, 2, 5, 10].
IETF does not specify what mechanisms that should be To illustrate the concept of duty cycling, we look at Con-
used. These layers are typically defined by other organiza- tikiMAC, the default duty cycling mechanism in Contiki [2].
tions such as the IEEE. For low-power wireless IPv6, the The principles of ContikiMAC is illustrated in Figure 2,
most common is to use CSMA at the MAC layer and IEEE Figure 3, and Figure 4. In ContikiMAC, nodes periodi-
802.15.4 at the link layer. At the radio duty cycling layer, no cally wake up to check for a transmission from a neigh-
standard or default mechanisms have yet been defined. bor. To transmit a message, the sender repeatedly trans-
3 Low-Power Implies Duty Cycling mits the packet until an acknowledgment is received from
Radio duty cycling is essential to attaining low power the receiver. After a successful transmission, the sender has
consumption. Without duty cycling, network lifetime is learned the wake-up phase of the receiver, and subsequently
counted in days. To reach a network lifetime of years, duty needs to send fewer transmissions. A broadcast transmission
cycling is needed. must wake up all neighbors. The sender therefore extends
The radio transceiver is the most power-consuming com- the packet train for a full wake-up period.
ponent of many low-power wireless devices. To reduce Radio duty cycling gives a low power consumption but
power consumption and to extend system lifetime, the ra- both brings costs in terms of reduced bandwidth and intro-
dio transceiver must be efficiently managed. But the radio duces new network dynamics [2, 7]. Different types of trans-
transceiver consumes as much power when it is in idle lis- missions have different implications in terms of power con-
tening mode as it is when actively transmitting messages. sumption and radio interference. Broadcast transmissions
Therefore, it is not enough to reduce transmissions: to save typically cost more than unicast transmissions, as shown in
power, the radio transceiver must be completely switched off Figure 4. Existing protocols such as RPL do not take these
for most of the time. But when the transceiver is switched dynamics into account. How radio duty cycling affects the
off, the device cannot receive messages from neighbors, behavior and performance of protocols such as RPL is still
making it difficult to participate in the network. an area of open research.
 TinyOS Contiki Contiki simulation environment is an important tool in ad-
Application Application
dressing the challenges of low-power IPv6 interoperability.
UDP UDP 5 Conclusions
TinyRPL ContikiRPL
IPv6 provides interoperability for the Internet of Things,
but attaining low-power interoperability still is an open prob-
BLIP uIPv6 lem due to at least two issues. Existing protocols for low-
power wireless typically have not been designed for duty cy-
CSMA CSMA
cling and existing duty cycling mechanisms have not been
Low Power Control * Radio Duty Cycling * designed for interoperability. Solving low-power interoper-
ability is crucial to making the Internet of Things a reality.
IEEE 802.15.4 Radio IEEE 802.15.4 Radio
Acknowledgments
IEEE 802.15.4 Frame Exchange This work was funded by the Swedish Strategic Research
* Both software stacks have the capability of supporting a low power MAC. Foundation and the EU Commission.
However, they are disabled for our evaluations presented in this work.

Figure 5. Contiki and TinyOS IPv6 interoperability, 6 References

[1] M. Buettner, G. V. Yee, E. Anderson, and R. Han. X-MAC: a short
from Ko et al. [6]. We demonstrated interoperability at preamble MAC protocol for duty-cycled wireless sensor networks. In
the network layer, the MAC layer, and the link layer, but Proceedings of the International Conference on Embedded Networked
without radio duty cycling. Sensor Systems (ACM SenSys), Boulder, Colorado, USA, 2006.
[2] A. Dunkels, L. Mottola, N. Tsiftes, F. Österlind, J. Eriksson, and
N. Finne. The announcement layer: Beacon coordination for the sen-
sornet stack. In Proceedings of the European Conference on Wireless
4 Low-Power Interoperability Sensor Networks (EWSN), 2011.
To attain low-power interoperability for IPv6 for the Inter- [3] A. Dunkels and J-P Vasseur. IP for Smart Objects, September 2008.
IPSO Alliance White Paper 1, available from www.ipso-alliance.org.
net of Things, interoperable radio duty cycling is essential.
We have demonstrated interoperability between Contiki and [4] M. Durvy, J. Abeillé, P. Wetterwald, C. O’Flynn, B. Leverett,
E. Gnoske, M. Vidales, G. Mulligan, N. Tsiftes, N. Finne, and
TinyOS [6], but with an always-on radio layer. Our experi- A. Dunkels. Making Sensor Networks IPv6 Ready. In Proceedings
ments showed that interoperability is not a binary property: of the International Conference on Embedded Networked Sensor Sys-
two implementations that have good performance on their tems (ACM SenSys), Raleigh, North Carolina, USA, November 2008.
own can have a suboptimal performance in a mixed network. [5] J. Hui and D. Culler. IP is Dead, Long Live IP for Wireless Sensor Net-
works. In Proceedings of the International Conference on Embedded
This is due to subtle variations in implementation choices Networked Sensor Systems (ACM SenSys), Raleigh, North Carolina,
and low-level details. Our results suggest that implementa- USA, November 2008.
tions of Internet of Things protocols need to be tested not just [6] J. Ko, J. Eriksson, N. Tsiftes, S. Dawson-Haggerty, A. Terzis,
for correctness but also for performance. Given that interop- A. Dunkels, and D. Culler. ContikiRPL and TinyRPL: Happy To-
erability in the simpler case of an always-on radio provides gether. In Proceedings of the workshop on Extending the Internet to
Low power and Lossy Networks (IP+SN 2011), Chicago, IL, USA,
such unexpected results, we have reason to believe that inter- April 2011.
operability with duty cycling will provide many unforeseen [7] M. Lunden and A. Dunkels. The politecast communcation primtive
challenges. for low-power wireless. The ACM SIGCOMM Computer Communi-
We see at least three challenges in attaining low-power cations Review, April 2011.
interoperability. First, existing duty cycling mechanisms [8] R. Musaloiu-E., C-J. M. Liang, and A. Terzis. Koala: Ultra-Low
Power Data Retrieval in Wireless Sensor Networks. In Proceedings
have not been designed for interoperability. Mechanisms of the International Conference on Information Processing in Sensor
such as ContikiMAC and the TinyOS BoX-MAC protocols Networks (ACM/IEEE IPSN), St. Louis, Missouri, USA, 2008.
are defined by their implementations and no formal speci- [9] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP
fications have been developed. Standardization within the Version 6 (IPv6). RFC 2461, December 1998.
IEEE 802.15.4e group have taken the first steps in this di- [10] Y. Sun, O. Gurewitz, and D. Johnson. RI-MAC: A Receiver-Initiated
rection. Second, duty cycling protocols are typically timing- Asynchronous Duty Cycle MAC Protocol for Dynamic Traffic Loads
in Wireless Sensor Networks. In Proceedings of the International
sensitive, making it difficult to develop and test interopera- Conference on Embedded Networked Sensor Systems (ACM SenSys),
ble implementations. Third, traditional interoperability test- Raleigh, NC, USA, 2008.
ing practices, which are based on physical meetings that are [11] N. Tsiftes, J. Eriksson, and A. Dunkels. Low-Power Wireless IPv6
bounded in time, have not been well-suited for testing inter- Routing with ContikiRPL. In Proceedings of the International Con-
operability between duty cycling protocols. ference on Information Processing in Sensor Networks (ACM/IEEE
IPSN), Stockholm, Sweden, April 2010.
The Contiki simulation environment provides a way to de- [12] J.P. Vasseur and A. Dunkels. Interconnecting Smart Objects with IP:
velop and test interoperability between duty cycling mech- The Next Internet. Morgan Kaufmann, 2010.
anisms across operating systems. We have already used [13] T. Winter (Ed.), P. Thubert (Ed.), and RPL Author Team. RPL: IPv6
the Contiki simulation environment to demonstrate interop- Routing Protocol for Low power and Lossy Networks. Internet Draft
erability between Contiki and TinyOS. We believe that the draft-ietf-roll-rpl-18, work in progress.