This is part 1 of the blog series “IoT Constrained Node Networks”. Part 1 is about “Introduction to IoT Constrained Node Networks”. Part 2 is about “Guidelines for Securing Data in IoT Constrained Node Networks”.
Internet of Things (IoT) transforms human lives through computing capabilities and smart automation and has become an inevitable part of human activities. IoT is spreading to various domains such as Industrial, Agriculture, Medical, Consumer, and Smart City. The main enablers for this IoT acceptance are the rapid growth in the Software, Networking, Sensors and Artificial Intelligence (AI). IoT means giving the networking capability to the ‘things’. These ‘things’ can be physical or virtual. Physical things include humans, wearables, vehicles, home, computers, and embedded devices. Virtual things include virtual machines, virtual networks, and social media sites. Connecting all these things through internet is called “Internet of Things”.
“Connecting all the physical and virtual things through internet is called Internet of Things”
This blog presents a brief introduction about IoT, its building blocks and computing capabilities, and then focuses on the constrained node networks, their characteristics, protocols used and the recommended firmware.
What are the Building Blocks of an IoT System?
An end-to-end IoT system can be classified into three networks: edge network, fog network and cloud network. These classifications are based on the type of edge devices and applications running in those networks.
- Edge Network
- Edge Devices: Embedded devices, sensors and actuators, gateways; devices may be constrained (limited resources) or unconstrained
- Applications: Sensing, monitoring, actuating, and operations with the external world
- Fog Network (and Fog Computing Architecture)
- Devices: Gateway and high-end servers
- Applications: Broker, data acquisition and processing, commanding, real time analytics, database, etc.
- Cloud Network
- Devices: Cloud platforms and high-end servers
- Applications: Storage, Machine Learning, Deep Learning
Constrained Node Networks
An edge system consists of constrained or non-constrained edge devices, or both. This blog discusses only the constrained edge devices.
What is a Constrained Node?
Edge devices with limited resources like memory, processing capacity, and power are called constrained nodes.
What are the Classes of Constrained Nodes?
There are three classes of constrained nodes as shown in Table 1.
Class | RAM | Flash |
---|---|---|
Class 0 | < 10 KiB | < 100 KiB |
Class 1 | ~ 10 KiB | ~ 100 KiB |
Class 2 | ~ 50 KiB | ~ 250 KiB |
Table 1 - Classes of Constrained Nodes
The support for network stack and security for these constrained nodes are shown in Table 2.
Class | Network Stack | Security |
Class 0 | No support | No support |
Class 1 | Specifically designed network stack for constrained nodes. | Supports security functions like authentication, confidentiality, and integrity |
Class 2 | Capable of supporting the same network stack as used on servers; however, using the same network stack as used in class 1 devices increases the inter-operability | Supports security functions like authentication, confidentiality, and integrity |
Table 2 - Support for Network Stack and Security
What is a Constrained Network?
A constrained network exhibits below characteristics:
- Low bit-rate/throughput
- High packet loss and high variability of packet loss
- Highly asymmetric link characteristics
- Lack of advanced network services like multi-cast
The possible reasons for the characteristics of constrained network are below:
- Cost
- Constraints posed by the nodes
- Physical constraints, e.g., power constraints or environmental constraints
- iTechnology constraints such as using legacy technologies
What is a Constrained Node Network?
A constrained network is composed of a significant portion of constrained nodes. Mostly, these constrained node networks are deployed in the edge network of an IoT system.
Constrained node networks are deployed in the edge network of an IoT system.
Building Blocks of Constrained Node Network
- Sensors – A sensor is an electronic utility that measures physical properties and gives electrical output. E.g. temperature sensor and acceleration sensor.
- Actuators - An actuator is a device which takes electronic input and gives physical output; e.g. motors.
- Cluster - A cluster is a group of sensors and actuators.
- Communication Channel - A communication channel is a medium through which data is transferred; e.g. wired or wireless.
- Aggregators – An aggregator is a device used to aggregate all the data from sensors and sometimes give the command to actuators. It is the gateway device.
- eUtility – It is a software or hardware or services which support aggregators for feeding data and computing.
- Decision Trigger – A decision trigger is a software which performs computing and takes action if needed.
Refer [2] for more details on these blocks. Figure 2 shows a high-level view of a constrained node network with its building blocks.
Figure 2 – Building blocks of Constrained Node Network Source - NIST SP 800-183
Any Special Network Stack needed for Constrained Node Network?
Constrained networks cannot use a conventional TCP/IP stack and need a new network stack because of the constraining nature of its resources.
Layer | Protocols in Conventional Network | Protocols in Constrained Node Network |
Data Link | Ethernet, WiFi | WirelessHart, Zigbee, BLE, Z-Wave, Thread, DASH7, HomePlug, G.9959, LTE-A, LoRaWAN, Weightless, Dect/ULE |
Adaptation | NA | To encapsulate IPv6 datagrams Ex: 6LoWPAN, 6TiSCH, 6Lo, IPv6 over BLE |
Network | IPv4, IPv6, OSPF, RIP, etc. | IPv6 was chosen rather than IPv4 to avoid address exhaustion issues |
Transport | TCP, UDP | TCP is huge in size so UDP is used in constrained node networks |
Presentation | Data is represented using XML or JSON | Data is represented using CBOR (Concise Binary Object Representation) |
Application | HTTP | CoAP (Constrained Application Protocol) has been specifically designed for constrained nodes |
Inter-Operability | NA | Applications use CoAP and its features in their own custom way. To support inter-operability, the following standards are used, e.g. Dotdot, OpenWeave, and LWM2M. |
Table 3 - Comparison of Protocols in Conventional Networks and Constrained Node Networks
Constrained Node – Firmware Comparison
The firmware for an IoT device needs to meet the following requirements: energy efficient, real-time capabilities, network connectivity, security, safety, and small footprint.
The firmware design relies heavily on the type of data link layer protocol used in a constrained node. The table below shows a comparison between some of the commonly used link layer technologies:
Technology | Link Layer Standard | Frequency | Max Range | No. of Devices | Max Data Rate | Native IP Support | 6LoWPAN Support |
---|---|---|---|---|---|---|---|
BLE | Bluetooth SIG | 2.4 GHz | 150m | 32000 | 1 Mbps | No | Yes |
Thread | IEEE 802.15.4 | 2.4 GHz | 30m | 250-300 | 250 Kbps | Yes | Yes |
Z-Wave | Zensys | 800-900 MHz | 30m | 232 | 100 Kbps | No | No |
Zigbee | IEEE 802.15.4 | 900MHz 2.4 GHz | 100m | 65000 | 250 Kbps | Yes | Yes |
Table 4 – Comparison of Constrained Node Technology
The key points that make the thread the preferred technology are listed below:
- Thread is an open source implementation of an open specification.
- Thread has inherent IP support. Zigbee has recently got IP support as an enhancement.
- Thread and Zigbee support Dotdot which is an application layer protocol for inter-operability. The number of Zigbee devices in the world is significant. Since thread supports Dotdot, it can also communicate with Zigbee devices in a seamless way.
- Thread is supported by Google, ARM, Nordic, Cascoda, NXP, Particle, Qorvo, Qualcomm, Samsung, Silicon Labs, STMicroelectronics, Synopsys, TI, Zephyr, and Apple since 2018. This raises the hope that thread protocol will become the de facto technology for constrained nodes.
Conclusion
This blog gives an introduction to IoT and computing capabilities, constrained node networks, and how constrained node networks are used in an IoT system. It also presents the firmware requirements and the network protocols meant for constrained nodes. The firmware comparison in Table 2, clearly shows that thread protocol has an edge over the other technologies and is the recommended firmware for constrained nodes in IoT.
References
- NISTIR 8200 “Interagency Report on Status of International Cybersecurity Standardization for the Internet of Things (IoT)”
- NIST SP 800-183 - “Networks of ‘Things’”
- RFC 7228 – Terminology for Constrained-Node Networks
- Whitepaper “Internet of Things Protocols and Standards” by Tara Salman under the guidance of Prof. Raj Jain
- https://openthread.io/
- https://en.wikipedia.org/wiki/Thread_(network_protocol)