Higher-level protocols for the Internet of Things (IoT) offer various features that make them suitable for a broad range of applications. For example, SNMP has been used for many years to manage network devices and configure networks and DDNS has been used to provide browser access to web devices. Either protocol can also be used for managing and configuring a variety of home devices. In comparison, CoAP is more suited to very small sensor deployments with tiny hardware and completely different security. A deeper understanding of these protocols and the applications requirements is necessary to properly select which protocol is most suitable for the application at hand.

Once the correct protocol or set of a few protocols is known to have the right characteristics for the application deployment, management and application support, the best implementation of each protocol should be understood. From this understanding, the designer can select the optimal implementation of each protocol for the system and then from these, select the best protocol implementation for the system.

The protocol selection problem is closely tied to the implementation of the protocol and the components that support the protocol are often essential in the final design. This makes the decision a very complex one. All aspects of deployment, operation, management, and security must be considered as part of the protocol selection including the implementation environment.

In addition, there are not any converged standards for particular applications, and these standards are generally selected by the market. This is a problem and an opportunity because the protocol selected for an application today may become obsolete in the future and may need to be replaced, or could become the standard if done correctly. As a developer, using specific features of the environment, to satisfy system requirements, that, in turn, rely on the details of the protocol, can make change in the future very difficult.

This article examines the range of protocols available, the specific requirements that drive the features of these protocols and considers the implementation requirements to build a complete system.

Protocols and vendors

Higher-level protocols for Internet of Things have various features and offer different capabilities. Most of these protocols were developed by specific vendors, and these vendors typically promote their own protocol choices, don’t clearly define their assumptions, and ignore the other alternatives. For this reason, relying on vendor information to select IoT protocols is problematic and most comparisons that have been produced are insufficient to understand tradeoffs.

IoT protocols are often bound to a business model. Sometimes these protocols are incomplete and/or used to support existing business models and approaches. Other times, they offer a more complete solution but the resource requirements are unacceptable for smaller sensors. In addition, the key assumptions behind the use of the protocol are not clearly stated which makes comparison difficult.

The fundamental assumptions associated with IoT applications are:

·      Various wireless connections will be used

·      Devices will range from tiny MCUs to high-performance systems with the emphasis on small MCUs

·      Security is a core requirement

·      Data will be stored in the cloud and may be processed in the cloud

·      Connections back to the cloud storage are required

·      Routing of information through wireless and wireline connections to the cloud storage is required

Other assumptions made by the protocol developers require deeper investigation and will strongly influence their choices. By looking at the key features of these protocols and looking at the key implementation requirements, designers can develop a clearer understanding of exactly what is required in both the protocol area and in the supporting features area to improve their designs. Before we look at this, let’s review the protocols in question.

IoT or M2M protocols

There is a broad set of protocols that are promoted as the silver bullet of IoT communication for the higher-level M2M protocol in the protocol stack. Note that these IoT or M2M protocols focus on the application data transfer and processing. The following list summarizes the protocols generally considered.

·      CoAP

·      Continua – Home Health Devices

·      DDS

·      DPWS: WS-Discovery, SOAP, WSAddressing, WDSL, and XML Schema

·      HTTP/REST

·      MQTT

·      UPnP

·      XMPP

·      ZeroMQ

These protocols have their features summarized in Figure 1. Several key factors related to infrastructure and deployment are considered separately below.

Key protocol features

Communications in the Internet of Things (IoT) is based on the Internet TCP/UDP protocols and the associated Internet protocols for setup. For basic communication, this means either UDP datagrams of TCP stream sockets. Developers of smaller devices claim that UDP offers large advantages in performance and size, which will in turn minimize cost. Although true, it is not significant in many instances.

Stream sockets suffer a performance hit but they do guarantee in-order delivery of all data. The performance hit on sending sensor data on an STM32F4 at 167 MHz is less than 16.7 percent (measured with 2 KB packets – smaller packets reduce the performance hit). By taking the approach of stream sockets, standard security protocols can also be used which simplifies the environment (although DTLS could be used with UDP if available).

Similarly, the difference in memory cost for an additional 20 KB of flash and 8 KB of RAM to upgrade to TCP is generally small. For trivial applications and sensors with huge volume, this may be meaningful but generally does not affect designs for ARM Cortex-M3 and greater or other architectures like RX, PIC32 and ARM Cortex-Ax.

Messaging the common IoT approach is very important and many protocols have migrated to a publish/subscribe model. With many nodes connecting and disconnecting, and these nodes needing to connect to various applications in the cloud, the publish/subscribe request/response model has an advantage. It responds dynamically to random on/off operation and can support many nodes.

Two protocols, CoAP and HTTP/REST, are both based on request response without a publish/subscribe approach. In the case of CoAP, the use of 6LoWPAN and the automatic addressing of IPv6 is used to uniquely identify nodes. In the case of HTTP/REST the approach is different in that the request can be anything including a request to publish or a request to subscribe so in fact it becomes the general case if designed in this way. Today, these protocols are being merged to provide a complete publish/subscribe request/response model.

System architectures are varied, including client server, tree or star, bus, and P2P. The majority use client-server but others use bus and P2P approaches. A star is a truncated tree approach. Performance issues exist for these various architectures with the best performance generally found in P2P and bus architectures. Simulation approaches or prototype approaches are preferred early in design to safeguard against surprises.

Scalability depends on adding many nodes in the field, and having the cloud resources easily increased to service these new nodes. The various architectures have different properties. For client server architectures, increasing the pool of available servers is sufficient and easy. For bus and P2P architectures, scale is inherent in the architecture but there are no cloud services. In the case of tree or star connected architectures, there can be issues associated with adding extra leaves on the tree, which burdens the communication nodes.

Another aspect of scalability is dealing with a large number of changing nodes and linking these nodes to cloud applications. As discussed, publish/subscribe request/response systems are intended for scalability because they deal with nodes that go off line for a variety of reasons, which allows applications to receive specific data when they decide to subscribe and request data resulting in fine data flow control. Less robust approaches don’t scale nearly as well.

Low-Power and Lossy Networks have nodes that go on and off. This dynamic behaviour may affect entire sections of the network so protocols are designed for multiple paths dynamic reconfiguration. Specific dynamic routing protocols found in ZigBee, ZigBee IP (using 6LoWPAN), and native 6LoWPAN ensure that the network adapts. Without these features, dealing with these nodes becomes one of discontinuous operation and makes the resource requirements of the nodes much higher

Resource requirements are key as application volume increases. Microcontrollers offer intelligence at very low cost, and have the capacity to deal with the issues listed above. Some protocols are simply too resource-intensive to be practical on small nodes. There will be limitations around discontinuous operation and big data storage unless significant amounts of serial flash or other storage media are included. As resources are increased, to reduce overall system costs, aggregation nodes are more likely to be added to provide additional shared storage resources.

Interoperability is essential for most devices in the future. Thus far the industry has seen sets of point solutions, but ultimately users want sensors and devices to work together. By using a set of standardized protocols as well as standardized messaging, devices can be separated from the cloud services that support them. This approach could provide complete device interoperability. Also, using intelligent publish/subscribe options, different devices could even use the same cloud services, and provide different features. Using an open approach, application standards will emerge, but today the M2M standards are just emerging and the applications standards are years in the future. All the main protocols are being standardized today.

Security using standard information technology security solutions are the core security mechanisms for most of these protocols that offer security. These security approaches are based on:

·      TLS

·      IPSec / VPN

·      SSH

·      SFTP

·      Secure bootloader and automatic fallback

·      Filtering

·      HTTPS

·      SNMP v3

·      Encryption and decryption

·      DTLS (for UDP-only security)

As systems will be fielded for many years, design with security as part of the package is essential.

Implementation requirements

Privacy is an essential implementation requirement. Supported by privacy laws, almost all systems require secure communication to the cloud to ensure personal data cannot be accessed or modified and liabilities are eliminated. Furthermore, the management of devices and the data that appears in the cloud need to be managed separately. Without this feature, users’ critical personal information is not protected properly and available to anyone with management access.

In the system architecture diagram we show the two separate components inside the cloud required for system management and application processing to satisfy privacy laws. Both components may have separate billing options and can run in separate environments. The management station may also include:

·      System initialization

·      Remote field service options (such as field upgrades, reset to default parameters, and remote test)

·      Control for billing purposes (such as account disable, account enable, and billing features)

·      Control for theft purposes (the equivalent of bricking the device)

Given this type of architecture, there are additional protocols and programs that should be considered:

·      Custom developed management applications on cloud systems

·      SNMP management for collections of sensor nodes

·      Billing integration programs in the cloud

·      Support for discontinuous operation using SQLite running on Unison OS to store and selectively update data to the cloud

Billing is a critical aspect of commercial systems. Telecoms operators have demonstrated that the monthly pay model is the best revenue choice. In addition, automatic service selection and integration for seamless billing is important. Also credit card dependence creates issues including over the limit issues, expired cards and deleted accounts.

Self-supporting users are a key to implementation success, too. This includes things like remote field service so devices never return to the factory, intelligent or automatic configuration, online help, community help, and very intuitive products are all key.

Application integration is also important. Today point systems predominate, but in the future the key will be making sensors available to a broad set of applications that the user chooses. Accuracy and reliability can substantially influence results application results and competition is expected in this area as soon as standard interfaces emerge. Indirect access via a server ensures security, evolution without application changes and billing control.

Discontinuous Operation and Big Data go hand in hand. With devices connecting and disconnecting randomly, a need to preserve data for the sensors and update the cloud later is required. Storage limitations exist for both power and cost reasons. If some data is critical, it may be saved while other data is discarded. All data might be saved and a selective update to the cloud performed later. Algorithms to process the data can run in either the cloud or the sensors or any intermediate nodes. All of these options present particular challenges to the sensor, cloud, communications, and external applications.

Multiple connection sensor access is also a requirement to make sensors truly available to a broad set of applications. This connection will most likely happen through a server to simplify the sensors and eliminate power requirements for duplicate messages.

IoT protocols for the Unison OS

The Unison RTOS is targeted at small microprocessors and microcontrollers for IoT applications. As such it offers many of the things that designers would expect are required. Unison’s features include:

·      POSIX APIs

·      Extensive Internet protocol support

·      All types of wireless support

·      Remote field service

·      USB

·      File systems

·      SQLite

·      Security modules

This is in addition to off-the-shelf support and factory support for the wide set of protocols discussed here.

By providing a complete set of features and modules for IoT development along with a modular architecture, developers can insert their protocols of choice for IoT development. Building protocol gateways is also possible. This approach minimizes risk by eliminating lock-in and shortening time to market.

Unison is also scalable, which allows it to fit into tiny microcontrollers and also provide comprehensive support on powerful microprocessors. The memory footprint is tiny which leads directly to a very fast implementation.

Protocols for the Internet of Things

Many protocols are being touted as ideal Internet of Things (IoT) solutions. Often the correct protocol choices are obscured by vendors with vested interests in their offerings. Users must understand their specific requirements and limitations and have a precise system specification to make sure that the correct set of protocols is chosen for the various management, application and communications features and make sure that all implementation specifications are met.

RoweBots Unison RTOS is suited to address IoT requirements with off-the-shelf modules for a variety of protocols and a complete set of supporting modules for fast and easy development.

Kim Rowe is Founder of RoweBots Limited.