Background and Overview

RIOT is a free and open source operating system for the IoT. It is aimed towards low-power IoT devices and microcontrollers and supports a wide range of 8-, 16-, and 32-bit architectures, including AVR, MSP430, ARM Cortex-M, and MIPS. In a nutshell, if you cannot run Linux because of constrained hardware resources, you should run RIOT. RIOT is based on a real-time- and multi-threading-capable microkernel, ships a hardware abstraction layer, and supports high energy efficiency.

The community around RIOT is a grassroots community of users, developers, and experts in the field, which follows the IETF model of openness and rough consensus. While the development and discussions are mostly happening via mailing lists and GitHub, the community also meets face-to-face at the yearly RIOT Summit. Participating in the RIOT Summit is always free-of-charge thanks to the generous support of multiple companies and research institutions.

I've been personally involved the development for more than five years. This article expresses my experiences of the third RIOT Summit in Amsterdam in 2018. 

The first day of the RIOT Summit is dedicated to plenary talks, which cover a great range of topics all around RIOT and the IoT, while during breaks contributors had the opportunity to show-case their personal projects involving RIOT. On the second day, newcomers and long-term contributors alike had the chance to learn more about RIOT in the morning tutorials and discuss the future of RIOT during the break-out sessions in the afternoon.

Day 1: Talks

Keynote: From R&D to Product via Open Source/Standards

Jaime Jiménez, Master Researcher at Ericsson Research and co-chair of the IETF CoRE working group, gave the opening keynote about the open standardisation of IoT protocols in the IETF and other organisations and their impact on a wide range of commercially available IoT products (slides, video). He emphasised challenges that those products faced and how they solved these using open standards and in some cases open software.

Jaime Jiménez talking about open standards in commercial products (© Oleg Hahm)

This sparked several interesting discussions during the Q&A: First, questions were raised regarding the pros and cons of those standards in so called Industry 4.0 applications as industry leaders usually tend to go for homegrown solutions instead of open, interoperable solutions. No satisfying answers to overcome this problem were found, but regulations towards advocating open standards might help especially in those sectors. On the question of how to broaden the acceptance of open IoT protocols, Jaime stressed that it would be crucial for device manufacturers to choose IoT protocols open and flexible enough for users to "play around with". This potentially might spark a similar revolution for the IoT similar to how HTML and HTTP sparked one earlier for the wider Internet.

On the topic of integrating IoT devices into the cloud, he unhappily acknowledged the prevalence of the MQTT protocol compared to the Constrained Application Protocol CoAP. MQTT lacks a well-defined security support but is heavily provided by major cloud service companies. The reasons for this are basically two-fold. First, MQTT is very easy to implement as it offloads reliability to TCP, which on the contrary makes it not suitable for constrained scenarios. Second, MQTT was ready to use before the CoAP standard was finished. When it comes to actual implementation of IoT applications, many developers use what is currently available instead of following a long-term strategy.

Arguments about business models versus open standards were also discussed: Some companies believe that open solutions threaten their income. Jaime, a holder of several patents himself, suggested that for the wider deployment open standards should be used, while for specific solutions – such as optimisations – within these deployment patents can protect the intellectual property of companies. This perspective is perfectly in line with RIOT, which due to its LGPL v2.1 licensing allows for both an open core and closed modules.

IoT Networking

Szymon Janc (Codecoup) presented nimBLE, the Bluetooth 5.0 stack which was originally implemented in the Apache MyNewt operating system (slides, video). Thanks to the work at Codecoup, portability of nimBLE was increased, which finally allows to provide this BLE stack easily as external package in RIOT.

Following this, Morgan Kita from Zühlke talked about Protocol Buffers – an object serialisation format developed by Google – and how they were able to integrate it with embedded medical device projects using the open source library nanoPb (slides, video).

In the third talk of this session, Christian Amsüss summarised the ongoing work of the IETF CoRE working group with a special focus on the CoRE resource directory and OSCORE (slides, video). After a short recap on the CoAP protocol and the IETF IoT protocol suite, he elaborated on the CoRE resource directory: It is assumed devices within a network know the address or are able to find the resource directory which itself is a CoAP server. As soon as devices are able to register their resource paths via a CoAP request at the directory server, the resources of the device are available via CoAP or will be proxied via HTTP to the wider Internet. As one of the central features of CoAP includes proxying (either to other CoAP domains or to HTTP), normal transport layer security is not good enough. This is were OSCORE (previously known as OSCoAP) steps in: OSCORE provides a mechanism to encapsulate encrypted CoAP requests within other CoAP requests, providing security for request type, resource target, and the content. Christian finished his talk by highlighting new building blocks the CoRE working group is working on, such as CoAP Management Interfaces, CoRECONF, and CoAP PubSub.

IoT Applications

The following two talks stirred a lot of interest among the participants since they showed some practical use of RIOT in the wild. Bas Stottelaar (Allego) automated his home based on RIOT (slides, video). He wrote his own implementation of the KNX protocol stack – an open protocol (ISO/IEC 14543) for commercial and domestic building automation – on top of the RIOT default network stack. Bas' solution is thus not bound to any specific hardware, as long as they support the KNX protocol which is mature and well known in the building automation domain.

Gilles Doffe (Savoir-faire Linux) used RIOT to build an autonomous robot named CORTEX for the Eurobot contest, utilising the real-time capabilities of RIOT to control the robot reliably (slides, video).

IoT Security

After lunch, Olaf Bergman (TZI Bremen) summarised the current state-of-the-art of security features in RIOT (slides, video). After giving a short overview on the current building blocks such as cryptography libraries and transport layer security, he introduced the current approaches of user-facing APIs as well as their connection to transport layer security features that are currently under proposal in RIOT. Pointing out that the current approaches don't include the exchange of credentials for the encryption of those features, he presented the DCAF protocol for a key exchange over trusted relationships in the backbone of the constrained nodes.

Peter Kietzmann (HAW Hamburg) presented an approach to hardware random number generation and device identification: Physical Unclonable Functions (PUFs) which utilise "secrets" hidden in the physical structure of a device (slides, video). The motivation behind his work is that both the problem of device identification and generating entropy is not generally solved for embedded devices. Especially on microcontrollers, where programs run far more deterministic than on classic hardware, a good source of randomness does not exist, unless explicitly provided. As an example he presented and analysed the behaviour of his SRAM-based implementation for RIOT.

Extracting entropy from SRAM PUFs (© Oleg Hahm)

Afterwards, Daniele Lacamera (WolfSSL) talked about TLS v1.3 protocol, which due to its faster, stripped down handshake and its ticket-based session resumption mechanism is more suitable for constrained devices than previous versions of TLS or SSL (slides, video). He also present the current implementation state of WolfSSL (including TLS v1.3) and future plans for the integration of the WolfSSL library into RIOT as a package.

Anton Gerasimov (HERE Technologies) presented Uptane as an alternative to the SUIT manifest format for over-the-air updates and how he and his company implemented a deployment solution for it with RIOT (slides, video).

Future IoT Security & Ethics

After that, Joost Rijneveld (Radboud University) presented a fast Post-Quantum Crypto implementation for Cortex-M4 (PQM4) by his colleagues and himself. There is an early port for RIOT available (slides, video).

Elmer Lastdrager (SIDN Labs) later reported how many currently available IoT devices connect to services, the user often doesn't even know about (slides, video). This may provide a backdoor into the device, posing a thread, such as the DDoS attacks from IoT devices we observed in the past, for the wider Internet. As a solution to this problem he presented SPIN – a hardware platform based on OpenWrt to secure IoT devices better via the informed consent of their user and manufacturer usage description (MUD) exchanges between the user's devices and the infrastructure of the ISP.

Last, but not least, Vesna Manojlovic (RIPE NCC) talked about ethics in technology by taking the RIPE Atlas measurements infrastructure as an example (slides, video). She described how RIPE Atlas was constructed with the informed consent and thus ethical principles in mind. On the flip-side, many studies which analye Internet censorship found that RIPE Atlas is insufficient for their analysis for exactly that reason, since it is purely based on traffic not generated by user data. One specific example is the exclusion of HTTP measurements in RIPE Atlas, as they pose a risk for users, since certain websites might not be allowed to be accessed in certain legislatures.

Open Mic and Social Event

In the final session of the first day, the community had the opportunity to discuss all remaining topics (video). This open mic session included some interesting points. Among those were proposals to collaborate with hardware vendors and third-party distributors to ship IoT devices with a running RIOT version by default. The current RIOT community would be quite happy to welcome new contributors from core manufactures. Another topic was about increased usability and friendliness for beginners, which is a topic close to the heart of the RIOT community. This spun into a discussion about IDE integration and how the community can support users with their specific IDE. As RIOT tries to be inclusive as possible, we will work on improving the current situation but will not enforce the usage of heavyweight tools.

After some nice and warming words of first-time attendees who highly appreciated the current state of RIOT, we went from the conference centre via a nice ferry ride to the social event at Rolling Rock Kitchen in Amsterdam Noord. There, we continued a lot of interesting discussions all around RIOT and the IoT in the more personal environment of this untouched, industry-like event place, and finished the evening with drinks, barbecue, and a warming campfire.

RIOT by campfire (© Peter Kietzmann)

Day 1: Demos

Among the most interesting demonstrations during the breaks was a showcase of energy harvesting by Michel Rottleuthner. He was able to run a RIOT-based board with radio on-board without any connected power source or battery, just by utilising the power-saving features of the microcontroller, solar power, and super-capacitors for power storage.

Juan Ignazio Carrano presented an early version of a Lua scripting prototype, which allows a user to implement and test scripts within a web browser and deploy it on real hardware utilising his recent integration work of the LUA interpreter into RIOT.

IoT in the wild! (© Peter Kietzmann)

Ken Bannister presented the deployment of a large multi-hop sensor network (up to six hops) using the 6TSCH implementation by OpenWSN (but sadly at the moment not based on RIOT), and Koen Zandberg was able to use a RIOT board as a sound device for his laptop based on his newly implemented USB stack.

Hendrik van Essen showcased his homegrown home automation system using RIOT on ESP8266 with MQTT-SN, while Kevin Weiss and Sebastian Meiling presented a hardware-in-the-loop solution for RIOT's CI environment, which will allow for better testing, including edge-case testing of RIOT's peripheral interfaces on a number of platforms.

Day 2: Tutorials and Break-out Sessions

In the morning of the second day of the summit, two tutorials were offered: one for beginners and one for maintainers. The beginners tutorials not also gave an introduction into the RIOT basics but also included instructions how to join a LoRAWAN network and thus was also very interesting for people already quite knowledgeable in RIOT (video). Furthermore, the exercises were practiced on the FIT IoT-LAB, so participants also learned how to use this large-scale testbed with RIOT.

In the other room, the maintainer tutorial was tailored to improve collaboration between the maintainers of RIOT. It summarised the maintainer guidelines and continued with discussions around how to improve both those guidelines and the pull request review process of RIOT in general.

In the afternoon, several break-out sessions have been organised in which the future of RIOT was discussed (video). First, the team around the upcoming over-the-air update (OTA) features of RIOT presented there current progress. This spawned discussions about several components of the OTA mechanism that may help the team with future decisions. The community greatly benefited from the attendance of members from other communities, such as MyNewt’s developer community or the IETF who were present during this session. In parallel the new testing infrastructure for RIOT’s continuous integration environment, components of which were already showcased the day before during the demo sessions, was presented and discussed.

After that, the whole community came together to discuss and brainstorm about a future configuration management system for RIOT. The objective of this configuration management is to simplify the usage of RIOT and to ease the first steps for beginners.

Towards an easier configuration of RIOT (© Peter Kietzmann)

Finally, all attendees were invited to participate in the first maintainer assembly meeting to shape decision processes within the RIOT community.

Final Thoughts

Discussions over lunch (© Peter Kietzmann)

For me as a long-time contributor, the RIOT Summit is always a highlight. It does not only provide an opportunity to learn new things about RIOT (even for me), but also gives room for fruitful discussions and exchanges with other contributors. Again, it showed to me the importance of face-to-face meetings in community projects such as RIOT: These different kind of interactions between the members of the community add a lot more nuance and understanding to our usual, purely remote exchange. Judging from the tremendous follow-up work that has already happened since our two days in Amsterdam, the RIOT Summit was a huge long-lasting success.

See you at the RIOT Summit 2019!

Links

Slides and video recordings of the talks, selected break-out sessions, and tutorials are available online. Direct links to the respective talks and sessions can be found in the text above.