A typical architecture of an IoT solution consists of constrained devices, gateways or border routers and the cloud platform. On a high level architecture perspective there are two types of devices: constrained devices and gateway-like devices.
The gateway-like devices use powerful processors, extendable memories and no constraints on power source. They can route data to the cloud servers or aggregate/store data to deal with network latencies. Typically they run Linux operating system with application containers and provision for remote management.
The constrained devices are end nodes with sensors/actuators that can handle a specific application purpose. They are usually connected to gateway-like devices, low power lossy network, and in-turn communicates with the IoT cloud platforms. Typically they communicate via low power wireless protocols like BLE, 802.15.4 (6LoWPAN, Zigbee, Thread, WirelessHART etc), LPWAN etc and mostly battery powered with low data rate.
The constraints of these devices are
- Code complexity (ROM/Flash), Size of state and buffers (RAM)
- Processing power
- Available power source and that has limits on reachability over time, if battery powered.
- User interface and accessibility in deployment
- Bitrate/Throughput
- Highly asymmetric link characteristics
- Cost
- Physical size
In order to simplify the overwhelming variety of constrained devices that could be connected to the internet, IETF has published an RFC 7228 that classifies the constrained devices into three categories as shown in the table below.
Classes of Constrained Devices
Class 0: Class 0 devices have constraints in memory(<<10KiB of RAM and <<100KiB of Flash) and processing capabilities. These devices has severe constraints to communicate securely with internet, so they typically pre-configured and are connected to proxies, gateways, or servers for internet communication.
An open source IoT OS like Contiki takes around 8-20 KiB of RAM and ~100 KiB of flash. In table 1 and table 2, by Oikonomou, G et al, the code and memory footprint for various components of the Contiki operating system were listed. Table 1 consists of message generation and handling and does not include routing table processing or packet forwarding. So the complete stack (without security and routing) needs around 90 kiB of flash and 5.5 kiB of RAM. Enabling TCP increases the code by 11 KiB and RAM usage by about 600 bytes.
Table 1
As the number of nodes increases, the size requirements for the routing and neighbour tables increases in Contiki. As shown in Table 2, it takes from 5.5 KiB to 9 KiB of RAM size.
Table 2
From the above tables, minimal network stack takes up most of the resources of class 0 devices and it is tough to fit anything more like security layer and application layer protocols like MQTT, CoAP, EXI etc
Class 1: Class 1 devices can have low power IoT stack [UDP, CoAP, leight weigh security protocols like DTLS etc] but quite constrained in code space and processing capabilities to employing a full protocol stack such as using HTTP, TLS, and related security protocols and data representations with out a gateway.
Class 2: Class 2 devices are less constrained and can perform at par with mobiles phones/notebooks in supporting most the protocol stacks. They have to be lightweight with energy-efficient protocols and less bandwidth consumption. Using Class 2 devices might reduce development costs and increase the interoperability.
References:
1. C. Bormann, M. Ersue and A. Keranen , “Terminology for Constrained Node Networks” https://tools.ietf.org/html/rfc7228
2. Eclipse IoT White Paper, "The Three Software Stacks Required for IoT Architectures"
3. Oikonomou, G., Phillips, I., Experiences from porting the Contiki operating system to a popular hardware platform.
Comments