1

Interoperable Services on Constrained Devices

in the Internet of Things
Hauke Petersen1 , Emmanuel Baccelli2 , and Matthias Wählisch1
1
Freie Universität Berlin, Germany
2
INRIA, France

Abstract—The Internet of Things (IoT) promises billions of equipped with memory management units (MMU), which de
constrained devices connected to the Internet in the near-future. facto rules out using operating systems such as Linux on such
The efficient integration of these massively deployments into devices.
service-oriented architectures requires light-weight and highly
automated mechanisms for device configuration and setup on all Remark 1—About software running on constrained devices.
layers of the network stack. In this paper we discuss two open The IoT is is currently held back by fragmentation due
problems. First, the set of existing solutions for configuration and to a plethora of too rudimentary, and too hardware-specific
service management (i.e., discovery, description, invocation) are software platforms, employed on constrained devices to ac-
insufficiently analyzed in the context of the IoT. Second, current commodate network stacks and applications. Only recently is
approaches do not comply with all the specific requirements and
characteristics of constrained devices, in terms of memory usage progress being made in this domain with the emergence of
and power consumption in particular. new operating systems (for instance RIOT [3], [4], or Contiki
[5]) which aim to provide an open source, modern, generic
software platform upon which one can conveniently build IoT
I. I NTRODUCTION application software. It is therefore likely that a couple of OS
will become dominant and thus defragment the IoT in the near
T HE Internet of Things (IoT) is currently emerging: the
next billions of machines [1] connected to the global IP
network are expected to consist in a variety of heterogeneous
future.
Remark 2—About the future of aforementioned constraints.
devices, ranging from wireless sensors to smart home appli- One might initially hope that, due to Moore’s Law (or
ances and many other types of machines that were typically something similar), these constraints will soon disappear and
not connected so far. These developments are expected to are thus mostly irrelevant. However, experience over the last
profoundly transform our environment, which will be heavily decade shows that such an evolution is in fact not taking place.
influenced by the new cyber-physical reality that is going result For example, the memory limitations of recent tiny IoT devices
from automated interaction between these devices – with or [6] are roughly the same as the limitations of wireless sensors
without humans in the loop. In effect, our interface to the introduced 10-15 years ago [7]. This may be explained by
Internet may soon no longer predominantly be our traditional the fact that advances in semiconductor technology enable not
keyboards, mouse and/or screens, but rather a multitude of only more powerful devices, but also lead to significant cost
heterogeneous, interconnected smart objects. reductions for constrained devices. As typical IoT deployments
The remainder of this paper is structured as follows. § II and will consist in large number of devices (hundreds to millions),
§ III discuss challenges and potentials of constrained devices extremely low costs will play a key role and will thus likely
and wireless environments respectively. § IV analyzes current lead to a future where the aforementioned constraints remain
building blocks for a service-oriented IoT, and § V concludes. relevant.

II. C ONSTRAINED D EVICES III. W IRELESS H YPER - CONNECTIVITY

The vast majority of devices that will constitue the IoT are When talking about the IoT, we are of course also talking
expected to be severely constrained in terms of memory, CPU about physical connectivity between smart objects and net-
as well as power capacities (e.g., running on tiny batteries). To work protocols running on these devices. Ten to fifteen years
that effect, the term constrained devices [2] was recently intro- ago, the Internet consisted mainly of servers, work-stations
duced to define a category of connected devices with stringent and personal computers that were connected predominantly
resource restrictions compared to common desktop computers, through a fixed, wired network infrastructure. In the early
such as (i) significantly reduced power consumption (mWatt 2000s the Internet started to evolve towards relying more and
vs. Watt), (ii) much less computation power (MegaFLOPS more on wireless communications to access the wired network
vs. TeraFLOPS), or (iii) orders of magnitude less memory infrastructure, via link-layer technologies such as IEEE 802.11
(KiloBytes vs. GigaBytes). Furthermore, constrained devices or cellular technologies such as UMTS and more recently LTE.
are typically based on micro-controllers that provide only Now, the Internet edge is pushing towards wireless hyper-
a limited set of functionalities e.g., they are typically not connectivity, whereby the density of wirelessly interconnected
 2

devices increases dramatically and most devices have multiple [10]. The key idea behind this is a system abstraction that
wireless interfaces. enables functional system design by focusing on the actual
Remark 3—About IoT communication technologies. functionality and end-user benefit rather than on underlying
One can expect that multiple link layer wireless technologies technology. The building blocks of such systems are consid-
are here to stay. However, approaches are emerging at the ered as services, such as data providers (e.g., sensors).
network layer, able to simultaneously harness and interconnect At the service level, neither the actual physical character-
heterogeneous (existing and future) link layer technologies that istics of the device providing a service, nor the nature of the
are relevant for the IoT: a good example of such an approach, underlying network need to be dealt with. This approach thus
based on open standards, is IPv6 combined with optimizations enables the development of services without prior knowledge
at various layers e.g., UDP/RPL/IPv6/6LoWPAN. We expect of device-specific implementation details, as such development
that such an inclusive, layered approach will defragment the can focus on the service(s) the device will offer. The concept of
IoT in the near future. service-oriented architecture suits well with the requirements
Remark 4—About IoT network architecture. of IoT deployment, by drastically reducing the complexity
The availability of densely deployed, multi-radio interface of dealing with large numbers of heterogeneous devices.
devices and goals such as local interaction between devices However, to this day, building blocks and tools to implement
to enable resilient, ubiquitous environment automation will this concept for IoT and constrained devices are not available.
likely lead to a network architecture that will both leverage The deployment and maintenance of IoT devices consist in
not only traditional, infrastructure-based network paradigms, mainly three different aspects, which are (i) configuration and
but also spontaneous wireless network paradigms [8]. Spon- management of the network layer, (ii) configuration and man-
taneous wireless networking allows devices to dynamically agement of the security mechanisms, and (iii) configuration
self-organize the relaying of data towards destinations – even and management of the services of a device. For the first two
without the help of infrastructure and pre-provisioned access aspects there are already solutions available that at least partly
points. This enriched network architecture will fuel a new provide means for automated or effort-less configuration. For
world of distributed IoT processes and applications, that can example, IPv6 stateless autoconfiguration [11] and 6LoWPAN
seamlessly interconnect with one another or with the cloud. neighbor discovery enhancements [12] enable network config-
uration mostly without manual interaction. DTLS [13] enables
IV. O PEN S TANDARDS : B UILDING B LOCKS FOR security mechanisms. In the following, we will not discuss
A PPLICATIONS AND S ERVICES IN THE I OT the completeness of these solutions or their adequacy with
The Internet of Things introduces two challenges. First, IoT scenarios and constrained devices, but rather focus on the
a significant number (billions) of additional devices will be third aspect mentioned above: configuration and management
connected to the Internet, most deployments consisting in large of the services of an IoT device.
batches of devices. Second, the majority of these devices will To the best of our knowledge, autoconfiguration, discovery
be using predominantly machine-to-machine (M2M) commu- and usage of high-level services is to date only partly solved.
nication, i.e., such devices will only present external interfaces Most of the protocols employed in this domain (such as DNS-
that are not primarily designed for human interaction. Thus, SD [14] and SSDP [15]) aim only for service advertisement
for both scalability reasons and interface design reasons, and discovery. Using the services then still require the im-
approaches which reduce management and configuration tasks plementation of the actual service protocols. However, while
to a minimum are necessary. Hence, autoconfiguration mech- this approach may have worked so far in the Internet, IoT
anisms are needed on all layers of the network stack. devices would greatly benefit from a coherent and standardized
While autoconfiguration mechanisms already exist for other service implementation model, which could both (i) decrease
types of machines connected to the Internet, there are however the requirements with respect to local resources e.g., memory
several issues to be addressed for IoT devices autoconfigu- and (ii) better fit the M2M paradigm.
ration. On one hand, many standard autoconfiguration solu-
tions still require manual interaction to some extent. On the
other hand, standard autoconfiguration mechanisms where not B. Towards Service-oriented Design for IoT Devices
designed to fit the extreme memory and energy constraints The lack of a coherent set of open building blocks inhibits
that software running on IoT devices must comply with. application development based on a service-oriented design
Furthermore, existing autoconfiguration solutions focus on approach. We argue that this gap should be filled with solutions
specific services. that enable applications to use automatically and coherently
In the following, for reasons including scalability and con- services offered by interconnected service providers (some of
venience, we thus argue not only for completely automated which being IoT devices). In the following, we briefly discuss
configuration solutions for IoT devices, but also for additional first steps towards this direction.
mechanisms enabling automated generic service deployment 1) Virtual Machine & Interpreted Language Aspects: A
in this context. possible approach to close this gap is to tie concepts of VM-
based or interpreted programming languages to the concepts
A. Beyond Autoconfiguration: Service-oriented Architecture of SOAP [16] or remote procedure calls (RPC). In conjunction
To cope with the increasing complexity of distributed sys- with automated code generation based on service description
tems the concept of service-oriented design has emerged [9], languages, such an approach could enable easy adoption of
 3

isolated and simplified setups, while low power networks have

precise requirements in terms of reduced network activity,
maximized sleep times, and low memory footprints.

V. P ERSPECTIVES
The Internet of Things is already here from the hardware
perspective. Massive deployment of constrained devices are
already taking place or are planned in the near-future. The
sheer number of new devices expected to be connected to
the Internet calls for (i) efficient and automated configuration
Fig. 1. Available protocols for different layers of service-oriented applications.
and management capabilities, on all layers of the network
stack, and (ii) new application development paradigms such
as service-oriented design that can reduce the complexity of
gluing high-level applications to the actual devices that are
connected to physical world. However, constrained devices
differ from other networking devices in terms of processing,
memory and power capacities. Moreover, constrained devices
will be used prevalently in M2M scenarios. Existing protocols
and mechanisms for device configuration are mainly devel-
oped for conventional Internet devices which do not have
the aforementioned, stringent constraints, and generally do
not possess the agility to adapt for this new heterogeneity.
Fig. 2. Comparison of protocols in the conventional web network stack and Future work thus has to be undertaken to (i) analyze existing
the envisioned network stack for constrained devices. configuration protocols with focus on power consumption and
memory requirements and (ii) develop a unified software stack
that enables the coherent integration of constrained devices
services. While such concepts work well in specific scenarios,
into service-oriented environments.
there are drawbacks, especially when applied on constrained
devices. For machines with very limited amount of memory it R EFERENCES
is not feasible to introduce additional software layers (e.g.,
[1] Ericsson, “More than 50 billion devices,” Ericsson White Paper, Tech.
virtual machines or heavy-weight middlewares) on top of Rep., 2011.
the operating system (which must itself be as lightweight as [2] C. Bormann, M. Ersue, and A. Keranen, “Terminology for Constrained-
possible). Such approaches thus cannot be deployed on very Node Networks,” IETF, RFC 7228, May 2014.
[3] “RIOT - The friendly OS for the IoT.” [Online]. Available:
constrained devices, which is a significant issue since seamless https://www.riot-os.org
interoperability requires the widest possible applicability of [4] E. Baccelli, O. Hahm, M. Günes, M. Wählisch, and T. C. Schmidt,
the solution, across all IoT devices. In the near-future, a “RIOT OS: Towards an OS for the Internet of Things,” in Proc. of the
32nd IEEE INFOCOM. Poster. Piscataway, NJ, USA: IEEE Press,
thorough assessment is thus needed concerning how efficient 2013.
such approaches can be in practice with respect to minimum [5] “Contiki.” [Online]. Available: http://www.contiki-os.org
memory footprint. [6] “ARM Cortex-M0.” [Online]. Available:
http://www.arm.com/products/processors/cortex-m/cortex-m0.php
2) Application Layer Communication Protocols Aspects: [7] “Texas Instruments MSP430.” [Online]. Available:
Figure 1 shows a set of standard application layer protocols http://www.ti.com/lsds/ti/microcontroller/16-bit msp430/overview.page
[8] J. Cordero, J. Yi, T. Clausen, and E. Baccelli, “Enabling Multihop Com-
that are frequently-used to implement services. However, when munication in Spontaneous Wireless Networks,” in ACM SIGCOMM
it comes to constrained devices, the applicability of these eBook on ”Recent Advances in Networking”, Volume 1, Chapter 9, pp.
protocols is limited. For instance, data encoding schemes 413-457. ACM, 2013.
[9] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D. Savio, “Interacting
and transport protocols that are based on human readable with the soa-based internet of things: Discovery, query, selection, and
encoded data are verbose and thus not efficient enough when on-demand provisioning of web services,” Services Computing, IEEE
memory and energy resources are limited. Recently, binary- Transactions on, vol. 3, no. 3, pp. 223–235, 2010.
[10] D. Guinard, V. Trifa, and E. Wilde, “A resource oriented architecture
based protocols such as CoAP [17] and CBOR [18] have for the web of things,” in Internet of Things (IOT), 2010. IEEE, 2010,
been introduced to better fit M2M and IoT requirements on pp. 1–8.
constrained devices. [11] S. Thomson, T. Narten, and T. Jinmei, “IPv6 Stateless Address Auto-
configuration,” IETF, RFC 4862, September 2007.
Moreover, the chattiness of these protocols is yet to be [12] Z. Shelby, S. Chakrabarti, E. Nordmark, and C. Bormann, “Neighbor
tested in the context of the required energy efficiency imposed Discovery Optimization for IPv6 over Low-Power Wireless Personal
by IoT constraints. In the near-future, a more comprehensive Area Networks (6LoWPANs),” IETF, RFC 6775, November 2012.
[13] E. Rescorla and N. Modadugu, “Datagram Transport Layer Security
study of these protocols working together as a protocol stack Version 1.2,” IETF, RFC 6347, January 2012.
will have to be conducted. Performance evaluation is required [14] S. Cheshire and M. Krochmal, “DNS-Based Service Discovery,” IETF,
with respect to memory consumption, and more importantly, RFC 6763, February 2013.
[15] Y. Goland et al., “Simple Service Discovery Protocol/1.0 Operating
with respect to energy consumption. In particular, energy without an Arbiter,” https://tools.ietf.org/html/draft-cai-ssdp-v1, IETF,
consumption of these solutions has only been studied in Internet Draft, 1999.
 4

[16] “Simple Object Access Protocol 1.2 (SOAP),” 2007. [Online]. Available:
http://www.w3.org/TR/soap12-part1
[17] Z. Shelby, K. Hartke, and C. Bormann, “Constrained Application Pro-
tocol (CoAP),” http://www.ietf.org/id/draft-ietf-core-coap-18.txt, IETF,
Internet Draft, 2013.
[18] C. Bormann and P. Hoffman, “Concise Binary Object Representation
(CBOR),” IETF, RFC 7049, October 2013.