devices - All Articles - CISO Platform2024-03-29T10:20:37Zhttps://www.cisoplatform.com/profiles/blogs/feed/tag/devicesClassification of IoT Deviceshttps://www.cisoplatform.com/profiles/blogs/classification-of-iot-devices2017-02-18T09:00:00.000Z2017-02-18T09:00:00.000ZNagasaihttps://www.cisoplatform.com/members/Nagasai<div><p></p><p><span class="font-size-3"><a href="{{#staticFileLink}}8669812656,original{{/staticFileLink}}"><img src="{{#staticFileLink}}8669812656,original{{/staticFileLink}}" width="668" class="align-full" alt="8669812656?profile=original" /></a></span><span style="font-size:12pt;"><br /> 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.</span></p><p><span class="font-size-3">The <strong>gateway</strong>-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.</span></p><p><span class="font-size-3">The <strong>constrained devices</strong> 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.</span></p><p><span class="font-size-3"><a href="{{#staticFileLink}}8669812471,original{{/staticFileLink}}"><img src="{{#staticFileLink}}8669812471,original{{/staticFileLink}}" width="392" height="213" class="align-center" alt="8669812471?profile=original" /></a></span></p><p><span class="font-size-3">The constraints of these devices are</span></p><ul><li><span class="font-size-3">Code complexity (ROM/Flash), Size of state and buffers (RAM)</span></li><li><span class="font-size-3">Processing power</span></li><li><span class="font-size-3">Available power source and that has limits on reachability over time, if battery powered.</span></li><li><span class="font-size-3">User interface and accessibility in deployment</span></li><li><span class="font-size-3">Bitrate/Throughput</span></li><li><span class="font-size-3">Highly asymmetric link characteristics</span></li><li><span class="font-size-3">Cost</span></li><li><span class="font-size-3">Physical size</span></li></ul><p><span style="font-size:1.5em;" class="font-size-3">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.</span></p><p style="text-align:center;"><span style="font-size:1.5em;" class="font-size-3">Classes of Constrained Devices</span></p><p><span class="font-size-3"><a href="{{#staticFileLink}}8669812500,original{{/staticFileLink}}"><img src="{{#staticFileLink}}8669812500,original{{/staticFileLink}}" width="556" alt="8669812500?profile=original" /></a></span></p><p><span class="font-size-3"><span style="font-size:12pt;"><strong>Class 0:</strong> 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 </span><span style="font-size:12pt;">proxies, gateways, or servers for internet communication.</span></span></p><p><span class="font-size-3">An open source IoT OS like Contiki takes around 8-20 KiB of RAM and ~100 KiB of flash. </span><span style="font-size:12pt;">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.</span></p><p style="text-align:center;"><span class="font-size-2">Table 1</span></p><p><span style="font-size:12pt;" class="font-size-3"><a href="{{#staticFileLink}}8669813064,original{{/staticFileLink}}"><img src="{{#staticFileLink}}8669813064,original{{/staticFileLink}}" width="334" class="align-center" alt="8669813064?profile=original" /></a></span></p><p></p><p><span class="font-size-3">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.</span></p><p style="text-align:center;"><span class="font-size-2">Table 2</span></p><p><span style="font-size:12pt;" class="font-size-3"><a href="{{#staticFileLink}}8669812886,original{{/staticFileLink}}"><img src="{{#staticFileLink}}8669812886,original{{/staticFileLink}}" width="353" class="align-center" alt="8669812886?profile=original" /></a></span></p><p><span class="font-size-3">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</span></p><p><strong><span class="font-size-3">Class 1: </span></strong><span style="font-size:12pt;">Class 1 devices can have low power IoT stack [UDP, CoAP, leight weigh security protocols like DTLS etc] but </span><span style="font-size:12pt;">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. </span></p><p><span style="font-size:12pt;" class="font-size-3"><strong>Class 2:</strong> Class 2 devices are less constrained and can perform at par with mobiles phones/notebooks in</span><span style="font-size:12pt;"> supporting most the protocol stacks. They have to be</span><span style="font-size:12pt;"> lightweight with energy-efficient protocols and less bandwidth consumption. Using Class 2 devices might reduce development costs and increase the interoperability.</span></p><p><span style="font-size:12pt;text-decoration:underline;">References:</span></p><p><span class="font-size-3">1. C. Bormann, M. Ersue and A. Keranen , “Terminology for Constrained Node Networks” <a href="https://tools.ietf.org/html/rfc7228">https://tools.ietf.org/html/rfc7228</a></span></p><p><span class="font-size-3">2. Eclipse IoT White Paper, "The Three Software Stacks Required for IoT Architectures"</span></p><p><span class="font-size-3">3. Oikonomou, G., Phillips, I., Experiences from porting the Contiki operating system to a popular hardware platform.</span></p><p></p><p></p></div>