Dave Hughes, CEO of software provider HCC Embedded, says: “Increasingly, we see IP moving down to the controllers.”
Once you have IP running on the node, what is the best way to get data onto and off it? Broadly, there are two competing models for passing information between sensor nodes and controllers across the internet. One is the classic IT client-server model, albeit given a web-focused makeover.
The idea behind ‘representational state transfer’ – or RESTful design – has become synonymous with HTTP, which underpins almost all web applications. However, many embedded software providers have implemented much simpler web servers that fit into kilobytes, rather than Megabytes.
The Constrained Applications Protocol (CoAP) is an attempt by the Internet Engineering Task Force to reduce the load on embedded systems even further. Using the same basic commands – ‘get’, ‘put’, ‘post’ and ‘delete’ – an application can grab status updates, issue orders and control internal databases through the remote node’s internal webserver.
To save on network bandwidth, CoAP uses binary encoding instead of HTTP’s textual formatting. But it also dispenses with TCP’s ability to confirm data delivery, using instead the simpler UDP datagram frame format. So, CoAP has to check for successful transmission itself. “People spent 20 years debugging TCP to make it work properly,” Hughes notes.
Developed by IBM, Message Queue Telemetry Transport (MQTT) represents one of a group of protocols that adopts a different model to REST-based protocols. Instead, it uses the same basic approach as the automotive industry’s Controller Area Network or the IEEE 61850 standard for managing data in high-voltage electrical grids. Sensors publish data values that can be picked up by any other node that is interested in them. In principle, the sensors responsible for each variable published on the network can change: the constant is the variable, not the device producing it. However, that can also be true of CoAP devices, as long as they work with consistent URIs. This is being harnessed in an extension to the CoAP standard that lets the protocol support publish-subscribe behaviour.
In the IoT world, where countless wireless networks will be joined across the internet, MQTT relies on brokers to take in and distribute data to interested nodes. These brokers offload the work of updating multiple systems from the end nodes by sorting data for clients. As MQTT is hierarchical, subscribers using wildcards could, for example, get updates on all temperature sensors in a factory.
In principle, these broker functions could sit inside gateways that concentrate data from many local devices and then feed data to other gateways, as well as remote cloud servers. In practice, that does not seem to be happening.
Dirk Akemann, marketing manager at Segger, says: “We haven’t seen people implement their own MQTT broker so far; instead, they use third-party services. Many of the gateways have been running Linux, but more gateways are now running an RTOS because the MCU has to be more powerful to run Linux. But gateways are getting simpler.”
Segger's MQTT client helps devices to communicate with each other over wired or wireless links
MQTT and CoAP both support secure transmissions through variants of the Transaction Level Security (TLS) protocol used by most web servers today. Whether or not device manufacturers want to increase the processing overhead by adding cryptography will depend on the sensitivity of the data. Low-end devices that measure environmental variables may send their data unprotected to gateways, but the increased value of aggregated data will most likely see encryption applied.
In terms of overall performance, however, the differences between CoAP and MQTT seem to be subtle. Experiments made in 2014 on a comparatively simple network by a team from the National University of Singapore found that, when the packet loss is low, CoAP has less overhead than MQTT. As long as the messages are small enough to fit into a UDP packet, this continues as congestion increases. But, for larger messages, CoAP’s need to retransmit entire messages instead of relying on TCP’s ability to support partial retransmission, meant MQTT started to perform better.
More recent work by researchers from Crete, Dubai and the UK found the processor overhead of MQTT running on Beaglebone and Beagleboard hardware is higher than that of CoAP because of the number of inter-device interactions. MQTT’s memory overhead remained lower than that of CoAP in their tests.
Express Logic’s president Bill Lamie says: “The way I see it right now is there are competing solutions with no clear winner.”
While Lamie says the company plans to support both, for the moment, enquiries about MQTT are more common than for CoAP. “The basic idea behind CoAP/DTLS is that it would be less resource intensive than MQTT/TLS. However, this doesn’t appear to be as big an advantage as hoped.”
“The basic idea behind CoAP/DTLS is that it would be less resource intensive than MQTT/TLS. However, this doesn’t appear to be as big an advantage as hoped.” |
Although CoAP saves on network bandwidth through its binary coding –which may be useful on constrained wireless connections – manufacturers may simply use HTTP with data compression for its greater compatibility with existing web software, with MQTT being used to support specific project needs.
Akemann says Segger decided to implement MQTT before moving onto CoAP, due to customer requests. “They are both very different: With CoAP, you need a constant connection between client and server; with MQTT, you can put your device to sleep, wake it once you have a new message for the broker, then have it go back to sleep.”
Following its acquisition of InterNiche, HCC Embedded also decided to implement MQTT. Hughes says: “We’ve had a lot of input, including from silicon manufacturers. People are probably more interested in MQTT than anything else.”
Development tools are also likely to influence protocol choices. Last year, RS Components assembled a miniature smart greenhouse to show how sensors and actuators can work together in an IoT environment. The developers used IBM’s Node Red software to create the application, which made decisions on ventilation and artificial lighting based on sensor readings. Node Red supports MQTT natively, although there are also Github-based downloads for CoAP, so the RS engineers used MQTT to handle communication with the sensors.
However, use of applications like Node Red is more likely to be found among IoT startups, rather than the mainstream embedded user base. “Traditional customers are not working in the same way,” says Akemann.
MQTT users also have to deal with the protocol’s one-way nature. “You can make MQTT bidirectional by having subscribers also act as publishers,” he adds, “but its nature is as a one-way connection.” The protocol would therefore need to sit alongside something else, such as HTTP, to cater for firmware downloads and other functions.
“MQTT would be good for broadcasting to devices that a firmware update is available, but you would then use a different protocol to fetch the update,” Akemann adds.
The competition between IP-based embedded protocols is not clear cut. But as the requirements for individual systems become clearer, device and systems manufacturers will start to determine which of the competing IP-based networking models will dominate.
