SoftwareX 18 (2022) 101089

Contents lists available at ScienceDirect

SoftwareX
journal homepage: www.elsevier.com/locate/softx

Original software publication

The Contiki-NG open source operating system for next generation IoT
devices
∗
George Oikonomou a , , Simon Duquennoy b,c , Atis Elsts d , Joakim Eriksson b ,
Yasuyuki Tanaka e , Nicolas Tsiftes b
a
Electrical and Electronic Engineering, University of Bristol, Bristol, UK
b
RISE Research Institutes of Sweden, Kista, Sweden
c
Inria Lille - Nord Europe, France
d
Institute of Electronics and Computer Science (EDI), Riga, Latvia
e
Corporate Research and Development Center, Toshiba, Kawasaki, Japan

article info a b s t r a c t

Article history: Contiki-NG (Next Generation) is an open source, cross-platform operating system for severely con-
Received 12 August 2021 strained wireless embedded devices. It focuses on dependable (reliable and secure) low-power
Received in revised form 23 February 2022 communications and standardised protocols, such as 6LoWPAN, IPv6, 6TiSCH, RPL, and CoAP. Its
Accepted 13 April 2022
primary aims are to (i) facilitate rapid prototyping and evaluation of Internet of Things research ideas,
Keywords: (ii) reduce time-to-market for Internet of Things applications, and (iii) provide an easy-to-use platform
Contiki-NG for teaching embedded systems-related courses in higher education. Contiki-NG started as a fork of the
Internet of Things Contiki OS and retains many of its original features. In this paper, we discuss the motivation behind the
Resource-Constrained Devices creation of Contiki-NG, present the most recent version (v4.7), and highlight the impact of Contiki-NG
through specific examples.
© 2022 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license
(http://creativecommons.org/licenses/by/4.0/).

Code metadata

Current code version v4.7

Permanent link to code/repository used for this code version https://github.com/ElsevierSoftwareX/SOFTX-D-21-00149
Code Ocean compute capsule N/A
Legal Code License 3-Clause BSD
Code versioning system used git
Software code languages, tools, and services used C, Java (Cooja Simulator), Python (Multiple ecosystem tools)
Compilation requirements, operating environments & dependencies Linux, macOS, Windows (partial support)
If available Link to developer documentation/manual Guides and Tutorials: https://github.com/contiki-ng/contiki-ng/wiki
API Documentation: https://contiki-ng.readthedocs.io
Support email for questions Gitter: https://gitter.im/contiki-ng
GitHub Discussions: https://github.com/contiki-ng/contiki-ng/discussions
Stack overflow: https://stackoverflow.com/questions/tagged/contiki-ng

1. Motivation and significance operating system [2] used a purely event-based execution model
and a custom programming language called nesC.
Research in the field of Wireless Sensor Networks started
almost two decades ago [1]. During the initial years, research 1.1. Historical background — The original Contiki OS
activities targeted extremely resource-constrained devices (kB or
less of RAM, bit-level radio Application Programming Interface The original Contiki Operating System (OS) [3] was open
(API)), and utilising highly specialised application-specific soft- sourced in 2006, but development had started as early as 2003.
ware was the norm. As an example of this approach, the TinyOS It was designed for resource-constrained wireless sensor devices
with code memory in the order of 100 kB and less than 10 kB
∗ Corresponding author. of volatile memory. Contiki was a major step in the evolution of
E-mail address: [email protected] (George Oikonomou). modern IoT operating systems, with its main strengths being:

https://doi.org/10.1016/j.softx.2022.101089
2352-7110/© 2022 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).
George Oikonomou, Simon Duquennoy, Atis Elsts et al. SoftwareX 18 (2022) 101089

• Use of the standard C programming language1 ; application • Dependability (reliability and security) through modern de-
developers no longer needed to learn a bespoke language velopment practices, continuous integration using simula-
such as nesC. tions and a physical testbed, and security testing techniques.
• Event-based kernel. In conjunction with tickless, platform-
specific main loop code (implemented for some platforms) The first release (v4.0) was a fork of the Contiki OS. Besides
the aforementioned changes in the high-level focus of the OS,
it allowed for fast reaction time to external events and
Contiki-NG added a new configuration and logging system, a new
energy-efficient execution.
lightweight and reliable RPL implementation (RPL-Lite), and a
• Cooperative multi-threading based process API [4]. It greatly
network administration shell. It also brought with it an exten-
simplified application programming, reducing the need for
sive cleanup of the codebase, with legacy platforms, protocols
both explicit state machines and locks (compared to event-
and services removed, so as to eliminate constraints on future
based API and preemptive thread API, respectively).
developments. All Contiki-NG releases and their changelogs are
• Early, standards-compliant support for network protocols available at https://github.com/contiki-ng/contiki-ng/releases.
such as the Internet Protocol (IP) and IPv6 protocols through
the uIP [5] stack. It also featured some of the very early open 2. The Contiki-NG project
implementations of IPv6 over Low Power Wireless Personal
Area Networks (6LoWPAN) and of the Routing Protocol for Contiki-NG introduces many new features, but it also re-uses –
Low-Power and Lossy Networks (RPL). with or without modification – many of the features of the origi-
nal Contiki OS, such as the scheduler, the event-based kernel, data
The official Contiki distribution also included Cooja, a simula-
structure manipulation libraries and storage. Contiki-NG also uses
tor for IEEE 802.15.4 networks of devices running Contiki-based
with minor modifications multiple networking-related software
firmware. Alongside Cooja and other tools of its ecosystem, Con-
components, such as the original implementations of 6LoWPAN
tiki went on to become an extensively-used tool for academic
and RPL (henceforth called ‘‘RPL-Classic’’).
research in the Wireless Sensor Network (WSN) field. As an Contiki-NG primarily targets Arm Cortex-M platforms. The
indicator of Contiki’s impact, the authors of this paper identi- official repository includes support for hardware by Nordic Semi-
fied in excess of 2000 peer-reviewed publications by using the conductor, NXP, OpenMote, Texas Instruments, and Zolertia. All
‘‘Contiki AND OS’’ search string on the Scopus database. Among those platforms are powered by Cortex-M3 or -M4 chips. Out-
those papers, approximately 350 have been published in 2018 side the main repository exist numerous Contiki-NG forks that
alone. Moreover, according to Scopus one of the first publications have added support for other hardware, for example platforms
documenting Contiki [3] has been cited in excess of 1300 times. powered by ST Microelectronics chips such as those used at the
FIT IoT-Lab testbed. To the best of our knowledge, there is no
1.2. From Contiki to Contiki-NG reason why Contiki-NG would not run on Cortex-M0. Lastly, the
official repository also includes support for the 16-bit MSP430
As the Contiki OS gained traction and started being used architecture, which is mainly used inside the Cooja simulator
extensively, some limitations began to emerge: (Section 1.2). In terms of adding support for more hardware, most
of the effort revolves around the implementation of support for
• Large legacy of old, extremely resource-constrained plat- new Micro-controller (MCU) architectures and on-chip periph-
forms. The 8-bit and 16-bit low-power microcontrollers erals, including radio transceivers. Once this support has been
which Contiki was originally designed for became obsolete added, porting Contiki-NG to a new board is much less onerous.
over time; 32-bit ARM Cortex-M based devices with more Documentation of the steps required to port Contiki-NG to a new
sophisticated low-power modes are the new norm [6]. hardware platform can be found on the wiki.2
• Support for non-standard protocols. As the field of wireless Contiki-NG positions itself within the same landscape as other
sensor network research evolved to become one of the core operating systems for embedded devices (Table 1), such as RIOT
enabling technologies of the IoT, interoperability and stan- [7], Zephyr,3 Arm Mbed,4 Apache Mynewt,5 TinyOS and FreeR-
dards became increasingly important. Alongside standards- TOS. With its implementation of TSCH, RPL-Classic and RPL-Lite,
compliant protocol implementations, the Contiki code-base the authors of this paper feel that Contiki-NG fills the niche of
also featured older, experimental, non-standard protocols low-power, IEEE 801.15.4 wireless mesh networks. For compre-
initially contributed as research artefacts. One such example hensive quantitative or qualitative comparisons of IoT operating
is the Rime stack. systems, we refer the reader to already extensive literature, such
as [8,9].
This combination of legacy platform code and support for In the interest of brevity, the remainder of this section focuses
non-standard networking protocols increased maintenance com- on describing technical as well as non-technical aspects of the
plexity and impeded code evolution. project that are either entirely new, or that have undergone
Contiki-NG was first released in November 2017. Its aim was significant changes since the launch of the Contiki-NG project.
to eliminate some of Contiki’s limitations in order to enable easier Describing the operating system in full detail is considered by the
maintenance and quicker evolution. The main vision is to focus authors to be out of scope of this paper.
on:
2.1. The Contiki-NG architecture and features
• Standard protocols. Some of the standards supported by
Contiki-NG are IEEE 802.15.4 TSCH, 6LoWPAN, 6TiSCH, RPL, Broadly speaking, the Contiki-NG source base can be concep-
CoAP, MQTT, and LWM2M. tually broken down into two parts: (i) hardware-independent and
• Support for modern hardware platforms.
2 https://github.com/contiki-ng/contiki-ng/wiki/Porting-Contiki%E2%80%

1 Developers should not use C switch statements inside protothreads. This 90NG-to-new-platforms
3 https://www.zephyrproject.org/
was a limitation of the original Contiki OS and has been carried over
4 https://os.mbed.com/
to Contiki-NG. With the exception of this limitation, Contiki-NG is fully C
standards-compliant. 5 https://mynewt.apache.org/

2
George Oikonomou, Simon Duquennoy, Atis Elsts et al. SoftwareX 18 (2022) 101089

Table 1
Feature overview of embedded OSs.
Project Networking Licence Language Threading
Contiki-NG TSCH, 6LoWPAN, RPL BSD C, C++ Cooperative
Contiki TSCH, 6LoWPAN, RPL BSD C Cooperative
Apache Mynewt BLE, LoRa, TCP/IP Apache 2.0 C, C++ Preemptive
Arm Mbed BLE, LoRa, lwIP Apache 2.0 C++ Preemptive
FreeRTOS TCP/IP MIT C, C++ Preemptive
RIOT 6LoWPAN, BLE GNU LGPL C, C++ Preemptive
TinyOS 6LoWPAN BSD nesC Optional preemptive
Zephyr BLE, Thread, 6LoWPAN Apache 2.0 C, C++ Optional preemptive

Fig. 1. Contiki-NG directory structure.

(ii) hardware-specific. The former hosts portable, cross-platform

implementations of all hardware-agnostic components of the OS,
including the kernel, software timers, data structure libraries, and
networking protocols.
The latter provides the code required to make the OS work on
specific devices. It consists of drivers for hardware components
including timers, radio interfaces and other on-chip and off-
chip peripherals, such as Universal Asynchronous Receiver/Trans-
mitter (UART), Serial Peripheral Interface (SPI), Inter-Integrated
Circuit (I2C), LEDs, user buttons and sensing elements. In order
to make the addition of support for more devices as effortless
as possible and in order to increase code portability, Contiki-NG
defines Hardware Abstraction Layers (HALs) for common inter-
faces, including General Purpose Input/Output (GPIO) and SPI. A
Hardware Abstraction Layer (HAL) for I2C is part of the short-term
roadmap. Those HALs include declarations of hardware-specific
functions that need to be implemented by the developer of a
new hardware port. This allows new platform developers to fo-
cus their effort on implementing the hardware-specific parts of
well-defined APIs without having to devise new programming
interfaces. Once chip-specific implementations have been devel-
oped, adding support for different platforms based on the same
chip merely requires trivial configuration. Where possible, within
the HALs Contiki-NG provides platform-independent functions Fig. 2. Contiki-NG network stack.
that can be used to access hardware elements. Those functions
will work on all supported platforms without any further effort.
For example, a developer can use spi_transfer() to send a
2.2. Networking support
sequence of bytes to an SPI peripheral; this function has well-
defined behaviour on all hardware platforms that implement the
As discussed in Section 1.2, among Contiki-NG’s main goals is
hardware-specific parts of the SPI HAL.
to provide standards-compliant, dependable low-power network-
ing for severely resource-constrained wireless embedded devices.
2.1.1. Repository structure Fig. 2 illustrates an overview of the Contiki-NG network stack. In
Fig. 1 illustrates the directory structure of the Contiki-NG the remainder of this subsection we provide an overview of the
codebase. All platform-independent code can be found under ‘os/’ Contiki-NG implementation of selected supported protocols and
and all hardware-specific drivers can be found under ‘arch/’. The specifications.
‘tests/’ directory hosts the automated Continuous Integration
testing suite (see Section 2.5), whereas ‘tools/’ contains helper 2.2.1. TSCH and 6TiSCH
utilities, such as scripts used to upload firmware to supported Time Slottted Channel Hopping (TSCH) is a Medium Access
devices, and to generate documentation. Control (MAC) layer defined in the IEEE 802.15.4-2015 standard
3
George Oikonomou, Simon Duquennoy, Atis Elsts et al. SoftwareX 18 (2022) 101089

[10]. It is aimed towards Industrial Internet of Things and other command line tools, as well as with node-coap7 Interoperability
use cases that require high reliability, low latency, and low energy with the former is tested automatically as part of our GitHub
consumption. 6TiSCH [11] is a set of existing and upcoming IETF actions CI workflow (Section 2.5) to prevent regressions. The
standards that aim to describe a complete TSCH-enabled IPv6 implementation is also interoperable with the ‘‘Copper (Cu)’’8 and
network stack for these use cases. Contiki-NG supports TSCH [10], ‘‘Copper for Chrome (Cu4Cr)’’9 browser addons.
the IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) minimal Contiki-NG also supports version 1.0 of the Open Mobile
configuration [12], the 6top Protocol (6P) [13], RPL [14], and other Alliance (OMA) Lightweight M2M (LWM2M) specification with
protocols for 6TiSCH. The TSCH and 6TiSCH implementations [15] plain text, JavaScript Object Notation (JSON) and Type-Length-
of Contiki-NG have been validated in a number of IETF interop- Value (TLV) data formats. The implementation supports the
erability events and were shown to be interoperable with other LWM2M security mode with pre-shared keys and the server and
security objects for configuring security. The LWM2M engine
implementations, including OpenWSN.
implementation is accompanied by an implementation of the
Two 6TiSCH scheduling functions are available on Contiki-NG:
LWM2M ‘‘IP for Smart Objects’’ (IPSO) objects, which be used
Orchestra [16] and the Minimal Scheduling Function (MSF) [17].
as an example starting point by developers wishing to adopt
Orchestra is a fully autonomous scheduling function which does
LWM2M for their work. The implementation is interoperable with
not need any signalling traffic to configure TSCH links. On the Eclipse Leshan10 as well as with Eclipse Wakama11 . Interoper-
other hand, MSF uses 6P for TSCH link allocations, and adapts its ability with Leshan is also tested as part of our CI workflow
schedule to traffic changes. (Section 2.5).
The original Contiki OS supports CoAP as well as LWM2M, but
2.2.2. RPL-Classic and RPL-lite both implementations have been reworked and evolved exten-
RPL is a protocol defined by the IETF RFC6550 [14] for routing sively by the Contiki-NG project.
over low-power and lossy networks. In a nutshell, nodes build a
multi-hop Directed Acyclic Graph (DAG) topology, enabling rout- 2.2.5. MQTT
ing towards a root (along a gradient) or towards any other node Contiki-NG features a lightweight client implementation of
(following either routing tables or via source routing). The Contiki Message Queuing Telemetry Transport (MQTT), an open publish/-
OS provided one of the earliest open RPL implementations already subscribe protocol. The implementation supports MQTT versions
back in 2010 (‘‘RPL-Classic’’), which was evidenced as being in- 3.1 (adopted from Contiki OS) and v3.1.1 (contributed by Contiki-
teroperable with the version of RPL distributed with TinyOS [18]. NG). Support for MQTT version 5 has already been merged into
Contiki-NG adopted this implementation and contributed a new the development branch and will be included in the next release.
version, called ‘‘RPL-Lite’’. Contiki-NG also provides a platform-independent MQTT client
RPL-Lite achieves two things: (i) It retains only a selected example that is interoperable with the Eclipse Mosquitto MQTT
subset of relevant modes of operation from the very flexible broker, as well as with the IBM Watson IoT Platform.12 Inter-
operability with Mosquitto is tested as part of our CI workflow
standard, based on years of experience from RPL-Classic, and (ii)
(Section 2.5) to prevent regressions.
it offers a complete re-factoring of a code-base that had accu-
mulated a substantial amount of technical debt over the years. 2.2.6. Limitations
As such, RPL-Lite only supports one single DAG at a time, one Currently, Contiki-NG does not officially support: (i) The Co-
single ‘‘RPL instance’’, and only the non-storing mode of opera- ordinated Sampled Listening (CSL) mode of IEEE 802.15.4; (ii)
tion. These choices minimise the amount of state maintained at 6LoWPAN Neighbor Discovery; (iii) 6LoWPAN ‘‘Mesh-Under’’ op-
each constrained node in the network, allowing for more robust eration (only ‘‘Route-Over’’ is supported); and (iv) secure mes-
operation. RPL-Lite was implemented in parallel with research on sages in RPL. Open source implementations for Contiki-NG do
ultra-reliable RPL [19], and benefits from many of the reliability exist in mirror repositories and adding official support is among
mechanisms devised as part of this research. the project’s long-term ambitions.

2.2.3. Multicast support 2.3. Responsible disclosure and security advisories

The Contiki-NG kernel supports IPv6 multicast forwarding in
6LoWPANs through an API that allows the easy addition of new Contiki-NG places increased focus on software security through
multicast forwarding engines. Contiki-NG contributes a standards- fuzz testing and other methods. The project has a dedicated
compliant implementation of the Multicast Protocol for Low- email address that can be used for responsible disclosure of
Power and Lossy Networks (MPL): A multicast forwarding security vulnerabilities. As a result of internal testing processes
protocol proposed by the Internet Engineering Task Force (IETF) and community reports, the project recently released its first
security advisories.
[20]. MPL support accompanies the two multicast engines adopted
from the original Contiki OS: (i) Stateless Multicast RPL Forward-
2.4. Documentation
ing (SMRF) [21,22] and (ii) Enhanced SMRF (ESMRF) [23].
Contiki-NG is documented in a GitHub-hosted wiki13 that
2.2.4. CoAP and LWM2M contains an extensive list of guides and tutorials for beginners as
The Constrained Application Protocol (CoAP) [24] is an applica- well as for more advanced users.
tion layer protocol similar to HTTP, but it has been designed to be Moreover, the Contiki-NG source codebase is annotated with
more suitable for constrained environments. Contiki-NG’s CoAP Doxygen14 comments that are used to generate an HTML-based
implementation supports many key CoAP features including: (i)
Block-wise transfers [25] for transporting large blocks of data that 7 https://www.npmjs.com/package/coap
cannot fit in a single packet, and (ii) CoAP observations [26]. The 8 https://github.com/mkovatsc/Copper
implementation and respective API make it easy to add new CoAP 9 https://github.com/mkovatsc/Copper4Cr
resources registered on a specific path, as well as more complex 10 https://www.eclipse.org/leshan/
resource handlers that can be invoked on all CoAP requests. 11 https://github.com/eclipse/wakaama
The CoAP implementation is interoperable with the libcoap.6 12 https://quickstart.internetofthings.ibmcloud.com
13 https://github.com/contiki-ng/contiki-ng/wiki
6 https://libcoap.net/ 14 http://www.doxygen.nl/

4
George Oikonomou, Simon Duquennoy, Atis Elsts et al. SoftwareX 18 (2022) 101089

API documentation. The API documents can be built and viewed # include " contiki .h " 1
by users locally on their computers, but are also hosted online # include " net/ipv6/simple -udp.h " 2
# include " net/mac/tsch/tsch.h "
on ‘‘Read the Docs’’15 . This automatically-updated online space
3
# include " lib/ random .h " 4
hosts multiple versions of the API documents: One per Contiki- # include " sys/node -id.h " 5
NG release (since v4.2 when the feature was first introduced), as 6

well as one for the latest version of the develop branch. # define UDP_PORT 8765 7
# define SEND_INTERVAL (60 * CLOCK_SECOND ) 8
9
2.5. Continuous integration testing PROCESS ( node_process , " RPL Node " ); 10
AUTOSTART_PROCESSES (& node_process ); 11
Contiki-NG is automatically tested using a Continuous Inte- simple_udp_callback rx_callback ; /* Defined in the file 12
rx_callback .c */
gration (CI) workflow on GitHub Actions. This workflow replaced 13
the older test suite on the Travis-CI16 platform with the release PROCESS_THREAD ( node_process , ev , data) 14
of version v4.6. The test suite is triggered automatically each { 15

time a code change gets merged into one of Contiki-NG’s main static struct simple_udp_connection udp_conn ; 16
static struct etimer periodic_timer ; 17
git branches, as well as each time a pull request is opened or uip_ipaddr_t dst; 18
updated. All pull requests must pass all CI tests before they can 19
be considered for inclusion in the official source codebase. All PROCESS_BEGIN (); 20
21
source code changes must take place through a pull request,
/* Initialization ; ‘rx_callback ‘ is the function for 22
including code changes proposed by members of the Contiki-NG packet reception */
maintainers team. This strategy enforces scrutiny by peers, there- simple_udp_register (& udp_conn , UDP_PORT , NULL , UDP_PORT 23
fore increasing overall code quality and reducing the likelihood of , rx_callback );
etimer_set (& periodic_timer , random_rand () if( node_id 24
introducing errors. == 1) { /* Running on the root? */
The Contiki-NG test suite comprises seventeen jobs, with each NETSTACK_ROUTING . root_start (); 25
job executing multiple CI tests. The test suite covers the following } 26
27
code elements:
/* Main loop */ 28

• Successful compilation of code examples for multiple hard- while (1) { 29

PROCESS_WAIT_EVENT_UNTIL ( etimer_expired (& 30
ware platforms under multiple different configurations. periodic_timer ));
• Validation of the correct operation of various elements of if( NETSTACK_ROUTING . node_is_reachable () 31
the networking subsystem through multiple Cooja simula- && NETSTACK_ROUTING . get_root_ipaddr (& dst)) { 32
/* Send network uptime timestamp to the network 33
tions and native code execution scenarios. root node */
• Successful compilation of the doxygen API documentation uint64_t network_uptime = 34
(Section 2.4). tsch_get_network_uptime_ticks ();
simple_udp_sendto (& udp_conn , & network_uptime , 35
Users who wish to exercise their code with Contiki-NG’s CI sizeof ( uint64_t ), &dst);
workflow can do so trivially by enabling GitHub Actions on their } 36
etimer_set (& periodic_timer , SEND_INTERVAL ); 37
fork repository. Alternatively, the Contiki-NG docker image pro- } 38
vides all tools required to execute the test suite locally on their 39
computers. PROCESS_END (); 40
} 41

2.6. Nightly builds Listing 1: Network-wide time synchronisation example

In addition to the per-contribution CI described above, we
perform automated nightly testbed runs on real hardware: a 3. Illustrative example
bespoke, 25-node testbed installed at RISE SICS. Each node con-
sists of both a control device (Raspberry PI) and a set of sensors As an indicative Contiki-NG user application example, we se-
(at the time of writing, a Zolertia Firefly and a JN516x don- lect the network-wide time synchronisation demo project.18 The
gle). Every night, a cron job schedules four 2-hour experiments, purpose of the example is to demonstrate how an application
each with a different configuration of the network stack. Control developer can use the time synchronisation provided by TSCH
nodes deploy to all 25 Firefly devices a firmware that performs in order to determine the delay between the time of packet
response–request communication between the root node and
origination by a source network node and the reception time on
every other node in the network. Each experiment involves over
the destination node, which also acts as the network time source.
10k round-trip network packet exchanges over multiple hops
This example was selected because the application code (Listing
on power-saving devices. A log file post-processing script ex-
1) remains simple while demonstrating multiple key interfaces:
tracts key metrics from each run: end-to-end round-trip delivery
Contiki-NG process initialisation (lines 23–27); waiting for timer
ratio, latency, radio duty cycle, hop counts, and frequency of
events (line 31); sending network packets (line 36); packet recep-
network topology changes. Raw log files and processed statistics
tion (present in the full source code, with the respective function
are pushed automatically to a public website for visualization and
monitoring.17 prototype shown in line 12 of the listing); and how to interact
The benefits of nightly builds are twofold. Firstly, they pro- with routing and TSCH protocols from the application layer.
vide automated testing on real hardware, as opposed to simula- The example hides a lot of the advanced Contiki-NG func-
tion/emulation used in CI. Secondly, they give developers feed- tionality under the hood; some details of how the Contiki-NG
back, and the ability to compare the performance of various network stack handles it are shown in Fig. 3. From the perspec-
network stack configurations and to spot performance degrada- tive of transmitting and receiving traffic, the application only
tion. has a direct interface with the transport layer (the UDP imple-
mentation in this particular example) through the simple_udp_
15 https://contiki-ng.readthedocs.io API. However, the application also has an indirect interface with
16 https://travis-ci.org/contiki-ng/contiki-ng
17 https://contiki-ng.github.io/testbed/ 18 Found under examples/6tisch/timesync-demo of the source tree

5
George Oikonomou, Simon Duquennoy, Atis Elsts et al. SoftwareX 18 (2022) 101089

4. Impact

Since its open source release in 2006, the original Contiki OS

has been used by numerous research projects funded by a host
of organisations, for example: (i) The European Commission (EC)
under Horizon Europe, Horizon 2020 (H2020), as well as by previ-
ous framework programmes, (ii) Various national research fund-
ing bodies, such as the UK’s Engineering and Physical Sciences
Research Council (EPSRC) or the Swedish Knowledge Foundation.
The added value and benefits of Contiki-NG can be sum-
marised as:
• Simplified porting to new hardware platforms due to re-
moval of legacy code, and due to new, platform-independent
system initialisation, main loop code and HALs.
• Simplified development of new features due to improved
documentation and cleaner examples.
• Increased code quality due to modern development prac-
tices including the git-flow workflow, continuous integra-
tion, nightly testbed runs, and a script to test in excess of
1200 project builds for all platforms.
Fig. 3. Contiki-NG networking stack as used by the network-wide time
synchronisation example when executed in the Cooja simulator. Due to these features, Contiki-NG is both an off-the-shelf tool
for building multihop, low-power, constrained wireless networks
with five-nines reliability [19], as well as a research platform
RPL and TSCH (dotted lines in Fig. 3). In the former case, the for innovation in low-power wireless embedded systems at all
NETSTACK_ROUTING API is used in order to determine whether levels of the networking stack, including for example 6TiSCH
the device has successfully joined the network before it tries scheduling, routing, security, and power-saving MAC layers.
Despite its relatively short history, Contiki-NG has already
to transmit. In the latter case, tsch_get_network_uptime_
facilitated the research published in a number of peer-reviewed
ticks() is used in order to retrieve accurate time information.
papers, including ones authored by teams not affiliated with the
On the receive path and depending on network stack configu-
project, for example [6,27–31].
ration, frame reception is either handled through interrupts, or by
Contiki-NG has been particularly successful in enabling novel
polling the radio driver inside TSCH RX timeslots. In the former
research in IEEE 802.15.4 TSCH and IETF 6TiSCH networks
case of interrupt-based operation, interrupts are processed in
[30–32]. Contiki / Contiki-NG offers one of only two open source
architecture-specific handler functions. For radios that form part
IEEE 802.15.4 TSCH implementations for real hardware, the other
of a System-on-Chip, a dedicated radio interrupt is asserted when
one offered by OpenWSN [33]. The authors of this paper do not
a frame has been received in full without errors. For SPI radios, consider OpenWSN as a direct competitor, as it is a network stack,
frame reception triggers a GPIO interrupt. The corresponding in- not a complete operating system.
terrupt handler typically polls the radio driver’s main process and Contiki-NG enables future research in many directions, in-
returns immediately, thus limiting the time spent executing code cluding but not limited to IoT security; energy harvesting; net-
instructions inside an interrupt context. The polled radio driver work mobility; multi-protocol/multi-radio/multi-frequency band
process is subsequently called outside the interrupt context, reads IoT communications.
the frame from the radio hardware’s buffer and places it in main Beyond scientific publications, Contiki-NG is starting to make
RAM, alongside relevant frame reception attributes such as the an impact through getting used: (i) to support the work under-
Received Signal Strength Indicator (RSSI). In the case of TSCH, taken as part of funded research projects in multiple disciplines
radio interrupts are disabled. Using the NETSTACK_RADIO API, (e.g. Industrial IoT, digital health, smart cities), (ii) for teaching in
the platform-independent TSCH implementation polls the radio higher education.
driver for received frames at the correct time during timeslot Table 2 lists a small number of funded R&D projects that have
operation, thus ensuring the timing accuracy required by TSCH. made extensive use of Contiki-NG. Presenting a comprehensive
Frames get processed by the implementation of the respective list of such projects would be prohibitively long and is considered
protocol as they are handed upwards the network stack, and the out of scope of this paper.
application code gets notified by way of a function callback. Contiki-NG is used as the basis of multiple commercial prod-
Under the /examples directory, Contiki-NG provides numer- ucts. This list includes consumer/home applications, for example
ous example projects that can be used as first steps with Contiki- smart home heating systems and smart light bulbs. The list also
NG, or as a starting point by users who wish to develop their own includes industrial applications, such as asset monitoring/track-
application. These examples cover all elements of the network ing, and smart agriculture.
stack described in this paper, as well as all hardware abstractions.
To try out the example in this section, or any of the other 5. Conclusions
existing examples on the repository, we recommend using the
Contiki-NG Docker container image19 and accompanying wiki This paper has discussed the Contiki-NG operating system for
documentation. This image provides all necessary compilers and severely-constrained wireless embedded devices. It has provided
tools, including the Cooja simulator that allows experimentation the reader with an overview of the project’s architecture and
without access to Contiki-NG supported hardware. some of its key non-technical features. It has highlighted the
value that Contiki-NG adds to the research community compared
to its predecessor. Lastly, it has provided some indicators about
19 https://hub.docker.com/r/contiker/contiki-ng its impact on research and higher education.
6
George Oikonomou, Simon Duquennoy, Atis Elsts et al. SoftwareX 18 (2022) 101089

Table 2
Funded research projects using Contiki-NG.
Project title Funder Ref.
F-Interop H2020
5G-CORAL H2020 [34]
SPHERE UK EPSRC
EurValve H2020 [32]
Vessedia H2020 [35]
E-care@home Swedish Knowledge Foundation [36]
aSSIsT Swedish Foundation for Strategic Research
SYNERGIA Innovate UK

Contiki-NG comes with a roadmap that can be accessed di- [7] Baccelli E, Hahm O, Günes M, Wählisch M, Schmidt TC. RIOT OS: TOwards
rectly on GitHub. Updates that are currently in the pipeline are an OS for the internet of things. In: 2013 IEEE conference on computer
communications workshops. IEEE; 2013, p. 79–80.
labelled with ‘‘roadmap’’, while features in the project’s longer-
[8] Javed F, Afzal MK, Sharif M, Kim B-S. Internet of things (IoT) operating
term wish list are labelled with ‘‘roadmap/long-term’’20 systems support, networking technologies, applications, and challenges: A
comparative review. IEEE Commun Surv Tutor 2018;20(3):2062–100.
Declaration of competing interest [9] Silva M, Cerdeira D, Pinto S, Gomes T. Operating systems for internet of
things low-end devices: Analysis and benchmarking. IEEE Internet Things
J 2019;6(6):10375–83.
The authors declare that they have no known competing finan- [10] IEEE. 802.15.4-2015 - IEEE Standard for low-rate wireless networks. 2016,
cial interests or personal relationships that could have appeared IEEE Std 802.15.4-2015.
to influence the work reported in this paper. [11] Thubert P. An architecture for IPv6 over the time-slotted channel hopping
mode of IEEE 802.15.4 (6tisch). 2021, RFC 9030.
[12] Vilajosana X, Pister K, Watteyne T. Minimal IPv6 over the TSCH mode of
Acknowledgements IEEE 802.15.4e (6tisch) configuration. 2017, RFC 8180.
[13] Wang Q, Vilajosana X, Watteyne T. 6TiSCH operation sublayer (6top)
The authors are the individuals among the current group of protocol (6P). 2018, RFC 8480.
Contiki-NG maintainers who were available to contribute to the [14] Alexander R, Brandt A, Vasseur J, Hui J, Pister K, Thubert P, et al. RPL: IPV6
routing protocol for low-power and lossy networks. 2012, RFC 6550.
preparation of this manuscript. While the authors have written a
[15] Duquennoy S, Elsts A, Al Nahas B, Oikonomou G. TSCH And 6tisch for
very significant proportion of the source code, we do not claim contiki: challenges, design and evaluation. In: Proc. IEEE DCOSS. IEEE; 2017,
ownership of the entire codebase. Over the years, source code p. 11–3.
has been developed and contributed by in excess of 250 indi- [16] Duquennoy S, Nahas BA, Landsiedel O, Watteyne T. Orchestra: Robust mesh
viduals, including hobbyists, students, researchers and industry networks through autonomously scheduled TSCH. In: Proceedings of the
international conference on embedded networked sensor systems. Seoul,
professionals. The GitHub ‘‘contributors’’ page21 provides a list of South Korea; 2015.
contributors within the last 10 years, but the full code history [17] Chang T, Vučinić M, Vilajosana X, Duquennoy S, Dujovne D. 6TiSCH
dates back to 2006. minimal scheduling function (MSF). 2021, RFC 9033.
With that in mind, first and foremost we gratefully acknowl- [18] Ko J, Eriksson J, Tsiftes N, Dawson-Haggerty S, Terzis A, Dunkels A, et al.
ContikiRPL and TinyRPL: Happy together. In: Workshop on extending the
edge individuals who have contributed their work to Contiki-NG
internet to low power and lossy networks (IP+ SN). Vol. 570. Citeseer;
and the original Contiki OS since its first open source release 2011.
in 2006. We acknowledge Adam Dunkels – the inventor of the [19] Duquennoy S, Eriksson J, Voigt T. Five-nines reliable downward routing in
original Contiki OS – and all individuals who have acted as project RPL. 2017, arXiv.
[20] Hui JW, Kelsey R. Multicast protocol for low-power and lossy networks
maintainers over the years.
(MPL). 2016, RFC 7731.
This work has been partially supported by VINNOVA and the [21] Oikonomou G, Phillips I. Stateless multicast forwarding with RPL in 6low-
Swedish Foundation for Strategic Research through the aSSIsT pan sensor networks. In: Proc. IEEE international conference on pervasive
project. computing and communications workshops. Lugano, Switzerland: IEEE;
2012, p. 272–7.
[22] Oikonomou G, Phillips I, Tryfonas T. IPV6 multicast forwarding in RPL-
References based wireless sensor networks. Wirel Pers Commun 2013;73(3):1089–
116.
[1] Akyildiz IF, Su W, Sankarasubramaniam Y, Cayirci E. Wireless sensor [23] Abdel Fadeel KQ, El Sayed K. ESMRF: Enhanced stateless multicast RPL
networks: a survey. Comput Netw 2002;38(4):393–422. forwarding for IPv6-based low-power and lossy networks. In: Proc. 2015
[2] Levis P, Madden S, Polastre J, Szewczyk R, Whitehouse K, Woo A, et al. workshop on IoT challenges in mobile and industrial systems. IoT-Sys ’15,
TinyOS: An operating system for sensor networks. In: Ambient intelligence. New York, NY, USA: ACM; 2015, p. 19–24.
Springer; 2005, p. 115–48. [24] Shelby Z, Hartke K, Bormann C. The constrained application protocol
[3] Dunkels A, Gronvall B, Voigt T. Contiki - a lightweight and flexible operat- (CoAP). 2014, RFC 7252.
ing system for tiny networked sensors. In: 29th Annual IEEE international [25] Bormann C, Shelby Z. Block-wise transfers in the constrained application
conference on local computer networks. 2004, p. 455–62. protocol (CoAP). 2016, RFC 7959.
[4] Dunkels A, Schmidt O, Voigt T, Ali M. Protothreads: Simplifying event- [26] Hartke K. Observing resources in the constrained application protocol
driven programming of memory-constrained embedded systems. In: (CoAP). 2015, RFC 7641.
Proceedings of the 4th international conference on embedded networked [27] Tomasic I, Khosraviani K, Rosengren P, Jörntén-Karlsson M, Lindén M.
sensor systems. New York, NY, USA: ACM; 2006, p. 29–42. Enabling IoT based monitoring of patients’ environmental parameters:
[5] Dunkels A. Full TCP/IP for 8-bit architectures. In: Proceedings of the 1st Experiences from using OpenMote with openwsn and contiki-NG. In:
international conference on mobile systems, applications and services. 2018 41st International convention on information and communication
MobiSys ’03, New York, NY, USA: ACM; 2003, p. 85–98. technology, electronics and microelectronics. IEEE; 2018, p. 0330–4.
[6] Kim H-S, Andersen MP, Chen K, Kumar S, Zhao WJ, Ma K, et al. System [28] Algora CMG, Reguera VA, Fernández EMG, Steenhaut K. Parallel
architecture directions for post-soc/32-bit networked sensors. In: Proceed- rendezvous-based association for IEEE 802.15.4 tsch networks. IEEE Sens J
ings of the 16th ACM conference on embedded networked sensor systems. 2018;18(21):9005–20.
ACM; 2018, p. 264–77. [29] Yang G, Urke AR, Øvsthus K. Mobility support of IoT solution in home
care wireless sensor network. In: 2018 Ubiquitous positioning, indoor
navigation and location-based services. IEEE; 2018, p. 475–80.
20 https://github.com/contiki-ng/contiki-ng/issues?q=is%3Aopen+is%3Aissue+
[30] Cheng X, Sha M. Cracking the TSCH channel hopping in IEEE 802.15.4e.
label%3Aroadmap In: Proceedings of the 2018 ACM SIGSAC conference on computer and
21 https://github.com/contiki-ng/contiki-ng/graphs/contributors communications security. ACM; 2018, p. 2210–2.

7
George Oikonomou, Simon Duquennoy, Atis Elsts et al. SoftwareX 18 (2022) 101089

[31] Lee S-B, Kim E-J, Lim Y. Contiki-NG-based IEEE 802.15.4 TSCH throughput [34] Li C-Y, Chien H-T, editors. Communication, dissemination, standardisation
evaluation. In: Proceedings of the Korean institute of information and and exploitation achievements of Y1 and plans for Y2. 2018, 5G-CORAL
commucation sciences conference. The Korea Institute of Information and Deliverable D5.1.
Commucation Engineering; 2018, p. 577–8. [35] Peyrard A, Kosmatov N, Duquennoy S, Raza S. Towards formal verification
[32] Elsts A, Pope J, Fafoutis X, Piechocki R, Oikonomou G. Instant: A TSCH of contiki: Analysis of the AES–ccm* modules with frama-c. In: Proc.
schedule for data collection from mobile nodes. In: Proc. 2019 international workshop on recent advances in secure management of data and resources
conference on embedded wireless systems and networks. EWSN, 2019. in the IoT. RED-IOT, Madrid, Spain; 2018.
[33] Watteyne T, Vilajosana X, Kerkez B, Chraim F, Weekly K, Wang Q, [36] Alirezaie M, Renoux J, Köckemann U, Kristoffersson A, Karlsson L,
et al. OpenWSN: a standards-based low-power wireless development Blomqvist E, et al. An ontology-based context-aware system for smart
environment. Trans Emerg Telecommun Technol 2012;23(5):480–93. homes: E-care@home. Sensors 2017;17(7):1586.