RIOT OS Paves the Way for Implementation of High-Performance MAC Protocols Kévin Roussel, Ye-Qiong Song, Olivier Zendra
Total Page:16
File Type:pdf, Size:1020Kb
RIOT OS Paves the Way for Implementation of High-Performance MAC Protocols Kévin Roussel, Ye-Qiong Song, Olivier Zendra To cite this version: Kévin Roussel, Ye-Qiong Song, Olivier Zendra. RIOT OS Paves the Way for Implementation of High- Performance MAC Protocols. SENSORNETS 2015, INSTICC; ESEO Angers, Feb 2015, Angers, France. pp.5-14, 10.5220/0005237600050014. hal-01141496 HAL Id: hal-01141496 https://hal.archives-ouvertes.fr/hal-01141496 Submitted on 13 Apr 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. RIOT OS Paves the Way for Implementation of High-Performance MAC Protocols K´evinRoussel, Ye-Qiong Song and Olivier Zendra LORIA/INRIA Nancy Grand-Est, Universit´ede Lorraine, 615, rue du Jardin Botanique, 54600 Villers-L`es-Nancy,France fKevin.Roussel,Ye-Qiong.Song,[email protected] Keywords: Real-Time, Wireless Sensor Networks, Internet of Things, MAC protocols, RIOT OS Abstract: Implementing new, high-performance MAC protocols requires real-time features, to be able to synchronize correctly between different unrelated devices. Such features are highly desirable for operating wireless sensor networks (WSN) that are designed to be part of the Internet of Things (IoT). Unfortunately, the operating systems commonly used in this domain cannot provide such features. On the other hand, \bare-metal" development sacrifices portability, as well as the mul- titasking abilities needed to develop the rich applications that are useful in the domain of the Internet of Things. We describe in this paper how we helped solving these issues by contributing to the development of a port of RIOT OS on the MSP430 microcontroller, an architecture widely used in IoT-enabled motes. RIOT OS offers rich and advanced real-time features, especially the simultaneous use of as many hardware timers as the underlying platform (microcontroller) can offer. We then demon- strate the effectiveness of these features by presenting a new implementation, on RIOT OS, of S-CoSenS, an efficient MAC protocol that uses very low processing power and energy. 1 INTRODUCTION IoT motes are usually very compact devices: they are usually built around a central integrated When programming the small devices that chip that contains the main processing unit and constitutes the nodes of the Internet of Things several basic peripherals (such as timers, A/D (IoT), one has to adapt to the limitations of these and D/A converters, I/O controllers. ) called devices. microcontroller units or MCUs. Apart from the MCU, a mote generally only contains some Apart from their very limited processing \physical-world" sensors and a radio transceiver power (especially compared to the current per- for networking. The main radio communication sonal computers, and even mobile devices like protocol currently used in the IoT field is IEEE smartphones and tablets), the main specificity of 802.15.4. Some MCUs do integrate a 802.15.4 the devices is that they are operated on small transceiver on-chip. batteries (e.g.: AAA or button cells). Thus, one of the main challenges with these Among the various components that consti- motes is the need to reduce as much as possible tute a mote, the most power-consuming block is their energy consumption. We want their bat- the radio transceiver. Consequently, to reduce teries to last as long as possible, for economical the power consumption of IoT motes, a first key but also practical reasons: it may be difficult— point is to use the radio transceiver only when even almost impossible|to change the batteries needed, keeping it powered-off as much as possi- of some of these motes, because of their locations ble. The software element responsible to control (e.g.: on top of buildings, under roads, etc.) the radio transceiver in an adequate manner is the MAC / RDC (Media Access Control & Radio 2.1 TinyOS Duty Cycle) layer of the network stack. A efficient power-saving strategy for IoT The first widely used system in this domain was motes thus relies on finding the better trade-off TinyOS (Levis et al., 2005). It is an open-source between minimizing the radio duty cycle while OS, whose first stable release (1.0) was published keeping networking efficiency at the highest pos- in september 2002. It is very lightweight, and as sible level. This is achieved by developing new, such well adapted to limited devices like WSN \intelligent" MAC / RDC protocols. motes. It has brought many advances in this do- To implement new, high-performance MAC / main, like the ability to use Internet Protocol (IP) RDC protocols, one needs to be able to react and routing (RPL) on 802.15.4 networks, includ- to events with good reactivity (lowest latency ing the latest IPv6 version, and to simulate net- possible) and flexibility. These protocols rely works of TinyOS motes via TOSSIM (Levis et al., on precise timing to ensure efficient synchro- 2003). nization between the different motes and other Its main drawback is that one needs to learn radio-networked devices of a Personal Area Net- a specific language|named nesC|to be able to work (PAN), thus allowing to turn on the radio efficiently work within it. This language is quite transceivers only when needed. different from standard C and other common im- At the system level, being able to follow such perative programming languages, and as such can accurate timings means having very efficient in- be difficult to master. terruption management, and the extensive use of The presence of that specific language is no hardware timers, that are the most precise timing coincidence: TinyOS is built on its own specific source available. paradigms: it has an unique stack, from which The second most power-consuming element the different components of the OS are called as in a mote, after the radio transceiver, is the statically linked callbacks. This makes the pro- MCU itself: every current MCU offers \low- gramming of applications complex, especially for power modes", that consist in disabling the var- decomposing into various \tasks". The multitask- ious hardware blocks, beginning with the CPU ing part is also quite limited: tasks are run in a core. The main way to minimize energy consump- fixed, queue-like order. Finally, TinyOS requires tion with a MCU is thus to disable its features as a custom GNU-based toolchain to be built. much as possible, only using them when needed: All of these limitations, plus a relatively slow that effectively means putting the whole MCU to development pace (last stable version dates back sleep as much as possible. to august 2012) have harmed its adoption, and it is not the mainly used OS of the domain anymore. Like for the radio transceiver, using the MCU efficiently while keeping the system efficient and reactive means optimal use of interruptions, and 2.2 Contiki hardware timers for synchronization. Thus, in both cases, we need to optimally use The current reference OS in the domain of WSN interruptions as well as hardware timers. Be- and IoT is Contiki (Dunkels et al., 2004). It's ing able to use them both efficiently without too also an open-source OS, which was first released much hassle implies the use of a specialized op- in 2002. It is also at the origin of many assets: we erating system (OS), especially to easily benefit can mention, among others, the uIP Embedded from multitasking abilities. That is what we will TCP/IP Stack (Dunkels, 2003), that has been discuss in this paper. extended to uIPv6, the low-power Rime network stack (Dunkels, 2007), or the Cooja advanced net- work simulator (Osterlind¨ et al., 2006). While a bit more resource-demanding than 2 PREVIOUS WORK AND TinyOS, Contiki is also very lightweight and well PROBLEM STATEMENT adapted to motes. Its greatest advantage over TinyOS is that it is based on standard, well- known OS paradigms, and coded in standard C Specialized OSes for the resource-constrained language, which makes it relatively easy to learn devices that constitute wireless sensor networks and program. It offers an event-based kernel, im- have been designed, published, and made avail- plemented using cooperative multithreading, and able for quite a long time. a complete network stack. All of these features and advantages have made Contiki widespread, voked from rtimer, using other parts of Con- making it the reference OS when it comes to tiki's meaning almost certainly crash or un- WSN. predictable behaviour. This restriction prac- Contiki developers also have made advances tically makes it very difficult to write Contiki in the MAC/RDC domain: many of them have extensions (like network stack layer drivers) been implemented as part of the Contiki net- using rtimer. work stack, and a specifically developed, Con- Also note that this cooperative scheduler is tikiMAC, has been published in 2011 (Dunkels, designed to manage a specific kind of tasks: the 2011) and implemented into Contiki as the de- protothreads. This solution allows to manage dif- fault RDC protocol (designed to be used with ferent threads of execution, without needing each standard CSMA/CA as MAC layer). of them to have its own separate stack (Dunkels However, Contiki's extremely compact foot- et al., 2006). The great advantage of this mech- print and high optimization comes at the cost of anism is the ability to use an unique stack, thus some limitations that prevented us from using it greatly reducing the needed amount of RAM for as our software platform.