Site Loader

Before comparing the chosen operating systems we want to classify them. Because of IoT’s diversity and complexity we announce two fields of applications:egin{enumerate}item Sensor nodes /sensing applications: potential systems are Contiki-NG and RIOTitem Gateways /aggregating applications: potential systems are Contiki-NG, RIOT, Android Things and Windows 10 IOT Coreend{enumerate}Both fields have slightly different characteristics and therefore different functionalities to fulfill.Sensors for instance are used for gathering any kind of data depending on the sensors type. After detecting changes in its environment such as different temperature, humidity, light or movement the end node transfers the collected information to a gateway. According to a sensor’s nature there are some requirements the operating systems needs to consider. End nodes are usually very tiny devices, which entails restrained memory capacity. Therefore the operating system itself needs to have a small memory footprint. Another important requirement is energy efficiency. Many sensors are running on batteries that cannot be charged often or easily, or that can only be replaced at high costs. Thus, low power solutions and sleep modes are main goals for the operating system. A third aspect to consider is the network connectivity. Because sensors need to transfer their data to gateways they need a reliable connection and should support common technologies and protocol such as Wi-Fi~cite{80211} and Bluetooth.~cite{IoTOSSurvey}After the transfer occurred the gateway’s task is to process and aggregate the received data which is more complex according to some functionalities. For instance the operating system on a gateway should not just support wired and wireless standards such as Ethernet, Wi-Fi~cite{80211}, but also web protocols such as CoAP~cite{CoAP}, MQTT~cite{MQTT} and UDP~cite{UDP} for transmission with low overhead. Another task at the gateway instance is processing and handling the received data. Therefore, decisions need to be made fast by processes, maybe even in real-time. The structure of sensor and gateway interaction is shown in Figure 3. Now that the classification is established, the chosen operating systems can be explained in detail and compared.egin{figure}includegraphicswidth=240pt{mySensorGateway.JPG}smallFig. 3. Common topologies of Wireless Sensor Networks. end{figure}
ewlinesection{IoT Operating Systems}subsection{Contiki-NG}A popular representative of systems for IoT devices is Contiki. It was created by Adam Dunkels and initially released in 2003. The operating system is open source and available under BSD License. Most common topics to use it in are city sound monitoring, remote house monitoring, street lights and alarm systems in commercial as well as in non-commercial systems. The reason for its popularity is due to its small memory footprint and support of major network protocols. Furthermore it works on low power and is energy efficient.~cite{Contiki} Since 2017 a new version of Contiki is available as open source: Contiki-NG, standing for Contiki New Generation, is a fork of Contiki which focuses on the new generation of protocols and platforms for the Internet of Things. It is also available under a 3-clause BSD license. The first released version is Contiki-NG 4.0.
ewlineAccording to hardware requirements Contiki is able to run on various MCUs such as the ARM Cortex-M3 for high energy efficiency. Its needed RAM is less than 10 kB and even its ROM is underneath 30 kB. The total code footprint amounts to about 100 kB. Under the terms of the Internet Engineering Task Force Contiki-NG’s Hardware requirements belong to Class 0 or possibly up to Class 1.~cite{ClassesIETF}
ewlineContiki-NG’s programming model is based on event-driven Protothreads, which are cooperatively scheduled, but also preemptive Multithreading is offered through additional libraries.~cite{ContikiNG} Protothreads are a suitable solution for constrained devices because its necessary RAM is just 2 Bytes per Protothread and no further stacks are needed.~cite{ProtothreadsAdam}
ewlineComing to the implementation of the network stack, Contiki-NG focuses on protocols that are useful in the context of low power and lossy networks. According to the OSI stack it supports IEEE 802.15.4 on low layers for wireless communication using Time-Slotted Channel Hopping (TSCH). TSCH ensures high end-to-end reliability. Currently 6TiSCH – a working group of the IETF – is developing solutions for IPv6 over TSCH in low power scenarios. As a Routing Protocol ‘Routing Protocol for Low Power and Lossy Networks’ (RPL) is used which takes a Destination-Oriented Directed Acyclic Graph (DODAG) as a basis. In Contiki-NG there are two different implementations available:egin{enumerate}item RPL Classic (or ContikiRPL) is Contiki’s original implementation of RPL which supports diverse complex options such as multicasting, DODAGs and much more that is specified in RPL’s RFC specification. Thus, the memory footprint became large over years.item RPL Lite however is the slim and default version for Contiki-NG with focus on basic functionalities and stable performance. It does not have some functionalities such as support for storing mode or DODAGs which can be problematic when interacting with other implementations. But therefore, its ROM footprint is smaller and acts better according to terms of performance.end{enumerate}Further protocols supported in Contiki-NG are: egin{itemize}item 6LoWPAN working with header compression and encapsulation mechanisms on top of IEEE 802.15.4 in order to transfer IPv6 packets,item TCP and UDP,item CoAP, WebSockets and more.end{itemize}Further Contiki-NG’s network stack is implemented RFC-compliant.
ewlineAccording to energy the operating system is very efficient: Supported hardware works on low power and also software (e.g. network stack) is implemented to run economically with power resources.~cite{ContikiNG}

Post Author: admin

x

Hi!
I'm Lewis!

Would you like to get a custom essay? How about receiving a customized one?

Check it out