Match new IoT protocols with the advanced IP stack
October 02, 2017
All manner of small devices?from electric meters to thermostats to pulse oximeters and more?will be generating and consuming data and expanding in number.
The roaring expansion of the Internet of Things (IoT) has outstripped the original design of the Internet. Estimates of the number of connected small devices now range into the multiple billions. All manner of small devices—from electric meters to thermostats to pulse oximeters and more—will be generating and consuming data and expanding in number. Fortunately, the Internet Engineering Task force (IETF) has met the initial challenge of sheer addressability with IPv6, the enhanced Internet protocol that uses a 128-bit address size providing 3.4 x 1038 addresses, which should hold us for a while.
However, mere addressability is not sufficient to accommodate all these small devices and their data. With their requirements for battery power, small memory, inexpensive CPUs and real-time performance, they are making demands on the existing TCP/IP protocols that are hard-pressed to support them. This has in turn led to the development of several new connectivity protocols. However, not every protocol is appropriate for all applications and not all protocols from the growing number of vendors meet industrial reliability requirements. Additionally, this should be done with minimal memory requirements—ideally under 25 KB. The developer is now faced with evaluation and choices regarding the protocols and the “IP stack challenge.” The most popular of these protocols are MQTT, CoAP, LWM2M, and 6LoWPAN.
Connectivity protocols aimed at IoT
MQ Telemetry Transport (MQTT) is a publish/subscribe protocol that employs a client/server model where every sensor is a client and connects to a server—or “broker”—over TCP. This model lets MQTT clients communicate one-to-one, one-to-many, and many-to-one. Even though MQTT is designed to be lightweight, it has two drawbacks for very constrained devices. First, every MQTT client must support TCP and will typically hold a connection open to the broker at all times. Second, MQTT topic names are often long strings which make them impractical for 802.15.4 (low-power, low-speed wireless radio).
The Constrained application Protocol (CoAP) enables constrained devices to communicate with the Internet using similar protocols. CoAP is designed for use between devices on the same constrained network, between devices and general nodes on the Internet, and between devices on different constrained networks, joined by an Internet. CoAP is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialized requirements such as multicast support, very low overhead, and simplicity. Unlike MQTT, which requires TCP, CoAP uses the smaller and simpler UDP, which is extremely important for resource-constrained IoT devices.
Lightweight M2M (LwM2M) is an open industry protocol built to provide a lightweight, low-cost means to remotely perform service enablement and application management for IoT devices over wireless connections. It is a communication protocol for use between client software on an M2M device and server software on an M2M management and service platform. LWM2M was designed to overcome issues from technical fragmentation, find a suitable mechanism to cater to the needs of constrained M2M devices, and to generate benefits from decoupling system components via standardized interfaces.
IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN) originated from the idea that "the Internet Protocol could and should be applied even to the smallest devices," and that low-power devices with limited processing capabilities should be able to participate in the IoT. 6LoWPAN is a mesh network protocol, allowing IPv6 datagrams to be transmitted by low-power, short-range radio such as IEEE 802.15.4, which typically has a span of 30 feet, with low bandwidth (in the kilobits per second range), and small packet size (128 bytes). 6LoWPAN bridges IPv6 and the low-power radio network.
The critical TCP/IPv6 stack
Each of the protocols described relies on an underlying IP stack for IPv6 communication. The new protocols are designed at the application level (except for 6LoWPAN), without regard for the means of transport (i.e., Ethernet, Wi-Fi, or cellular). As such, much of the heavy lifting is relegated to the IP stack, which is significantly larger than the cloud protocols themselves. Therefore the underlying IP stack is much more complex, and much more critical to the exchange of information, even though it is more general in design. It must, of course, support IPv6. When choosing cloud protocols, it is equally critical—if not more so—to select the right IP stack on which these cloud protocols will rely for proper and efficient operation.
The IP stack must be small so that it, along with the selected protocol, can fit into the device’s memory. It must be safe because many devices require safety certification and it must be secure for the same reasons. It must be able to communicate with the latest protocols beyond the cloud (e.g., AutoIP, DNS, DHCP, etc.). And it must be fast and easy to use so that developers can get to market quickly and confidently. Such stacks that take less than 25 KB are now available, excluding RTOS and application code.
The new cloud protocols extend the IoT from device to cloud, and are best-suited for use with small-memory, limited-performance microcontrollers. To do so, they must be small and efficient and must be designed for use on top of a capable, small, fast IP stack. Designers must make a careful evaluation of the underlying IP stack before committing to any cloud-only solution.
[Figure 1 | An advanced dual IPv4/IPv6 TCP/IP stack built on top of the RTOS. The industrial-grade platform adds new IoT protocol support including 6LoWPAN, MQTT, CoAP, and LWM2M for securely connecting the smallest of IoT devices to the cloud.]
