UDP and the embedded wireless Internet of Things

With the addition of wireless sensor connectivity to the IPv6 protocol in the form of 6LoWPAN, embedded systems developers are faced with a bewildering array of challenges and opportunities. They are also faced with an array of specialized commands such as GET, POST and PUT; old protocols such as XML and JSON used in new ways; and a variety of newly minted and unfamiliar ones such as COAP, IoT. LLN. REST. ROLL, RPL and WoT (Definitions for these acronyms can be viewed in a separate window by clicking here.)

But if you dig deep enough you will find an old friend - UDP, a subset of the familiar TCP/IPthat underpins the now ubiquitous Internet.

When the Internet burst upon us in the early 1990s, embedded systems developers were among the first to jump on board and use its connectivity. But in addition, they started taking its protocols apart to see if there were other ways they could be used in their designs. Some early design articles on Embedded.com and in ESD Magazine on this general topic include: “Speed packet throughput with compressed UDP,” “TCP/IP for transactions,” and “The basics of TCP/IP.”

The problem they ran into was that in the drive to guarantee reliability of transmissions, the full TCP/IP suite is anything but real time and deterministic. In simplistic terms, all it does is guarantee delivery of a packet, not when that packet is delivered. The sending device has to wait until there is a response from the receiving node that the packet has arrive. During that period, no new instances of the same connection can be established. Great for reliability, but death on deterministic response times.

But embedded developers found ways to improve response time and make apps more deterministic. They did this by stripping away that portion of the TCP/IP responsible for guaranteeing the reliability and delivery and using only the UDP subset. Because of its lack of a reliability mechanism, UDP has nothing to slow it down, so packets can be sent at full speed and as fast as the underlying physical device can send them.

In many resource-constrained embedded designs, UDP's lack of overhead makes a big difference in throughput when compared to TCP. Also, unlike TCP, UDP is connectionless and, therefore without a connection state to be maintained, so memory size/usage is not much of an issue. And because a UDP transaction requires only two UDP datagrams, one in each direction, load on the network is minimized, further reducing response times.

The downside, of course, is reliability, since if a UDP datagram is dropped the transaction is not completed. But in these early designs UDP was used only within closed wired networks, where everything is known: the nature of the connections, the number and location of the recipients, what each needs to get from the transmission, and what the response time of each node is.

In such cases, the thinking went, many of TCP’s reliability mechanisms were not necessary because all of the characteristics and status of the senders – and receivers – are known and therefore no response was needed to guarantee delivery. If it was necessary for the data transfer to be reliable, this reliability was built into the application layer of the design at much lower cost in terms of resources and response time.

To understand that you first have to understand the function of 6LoWPAN, which is to enable the use of IPv6 in what are called Low-power and Lossy Networks (LLNs), such as those based on IEEE 802.15.4, as well as a second one for smart object internetworking over LLNs, called IPv6 Routing Protocol for Low-power and Lossy networks (RPL) . Its aim is to enable the use of standard web services, such as REST, XML, JSON, and others over LLNs without using application server gateways, in configurations somewhat akin to what Sun called “confederations of devices.”

This combination makes it possible for smart objects sitting out on wireless phones or sensors to be not only integrated with the Internet but also with the WoT and the IoT. If it works as its designers plan, smart object applications can be built on top of familiar Representational State Transfer (REST) architectures, which will allow apps to take advantage of loosely coupled Web services which can be shared and reused.

In REST there is something called a Universal Resource Intentifier (URI) which represents resources controlled by the server. In this framework, the resources are decoupled by the services and can be arbitrarily represented by means of various formats, such as the now familiar XML or JSON. The resources are accessed and manipulated by an application protocol based on client/server request/responses.

While REST is not tied to a particular application protocol at present, most of the REST implementations I’m aware of still make use of the Hypertext Transfer Protocol (HTTP) to manipulate resources by means of GET, POST, PUT, etc.

By this means, IoT and Machine-to-Machine (M2M) apps which can be shared and reused are developed on top of web services. Wirelessly connected sensors in such an environment become abstract resources identified by URIs, represented with arbitrary formats, and can be used with the same methods as HTTP. Such RESTful WSNs drastically reduce the application development complexity, an important factor in most embedded designs.

But as a consequence of the differences between traditional Internet apps and often wirelessly connected IoT or M2M applications, the use of web services in LLNs is not straightforward especially when any degree of real-time or deterministic operation is required. Also complicating the issue is that a lot of embedded IoT or M2M applications are short-lived. Because of their wireless nature, the web services that may reside in battery operated sensors and devices will most of the time be in the sleep mode and will wake up and are available only when needed.

To deal with such issues, the Internet Engineering Task Force (IETF) Constrained RESTful environments (CoRE) Working Group has come up with a REST- based web transfer protocol called Constrained Application Protocol (CoAP), that seems to depend on the ability of UDP to achieve something close to real time and deterministic operation.

CoAP is a web transfer protocol optimized for resource constrained networks typical of IoT and M2M applications. It is based on a REST architecture in which resources are server-controlled abstractions made available by an application process and identified by Universal Resource Identifiers (URIs).

The first significant difference between HTTP and CoAP is in the transport layer upon which they rely. HTTP relies on the Transmission Control Protocol (TCP), which uses a flow control mechanism ill-suited for LLNs. Moreover, its overhead is considered too high for short-lived transactions.

By comparison, CoAP is built on top of the UDP and therefore has significantly lower overhead and is capable of multicast support. To maintain all of the performance and resource advantages of UDP without giving up the reliability of the full TCP/IP, CoAP is organized into two layers.

The Transaction layer handles the single message exchange between end points. Four types of messages are handled by this layer: Confirmable (requires an acknowledgment), Non-confirmable (does not need to be acknowledged), Acknowledgment (acknowledges a Confirmable message) and Reset (indicates that a Confirmable message has been receive but context is missing to be processed).

The Request/Response layer is responsible for the transmission of requests and responses for the resource manipulation and transmission. This is the layer where the REST-based communication occurs. A REST request is piggybacked on a Confirmable or Non-confirmable message, while a REST response is piggybacked on the related Acknowledgment message.

Everything I read by the proponents of COAP argues that the use of this dual layer approach allows it to provide reliability mechanisms even without the use of TCP as the transport protocol. This is because a Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends the Acknowledgement message. An important aspect of COAP as far as response time is that when a server receives a request which it is not able to handle immediately, it first acknowledges the reception of the message and sends back the response in an off-line fashion.

To keep the message overhead as small as possible and avoid the significant overhead that the standard HTTP mechanism requires, COAP uses a number of techniques that will require embedded developers to carefully parse their impact on system response times and deterministic operation.

First, CoAP uses a short, fixed-length, compact binary header of 4 bytes followed by compact binary options. A typical request has a total header of about 10-20 bytes. Because a resource on a CoAP server will more often than not change over time, the protocol’s been designed to allow a client to constantly observe the resources. The way this is done is that the client (the observer) registers itself to the resource (the subject) by means of a modified GET request sent to the server.

The server establishes an observation relationship between the client and the resource. Whenever the state of the resource changes, the server notifies each client having an observation relationship with the resource. The duration of the observation relationship is negotiated during the registration procedure. While not as neat and efficient as a purely UDP approach, it seems to resolve many of the performance issues.

Second, CoAP also supports other payload encoding standards, such as the widely used Extensible Markup Language (XML), but not your common ordinary garden-varity version. As it is presently implemented, the verbosity and parsing complexity of XML makes it inappropriate for constrained devices. One alternative is the more compact data representation in JSON.

JSON (JavaScript Object Notation)is a lightweight, text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures. But what JSON lacks is the flexibility of XML. As a result there are ongoing efforts to develop more compact binary XML-based representations such as the Extensible XML Interchange (EXI).

There is still a lot to learn about the impact of 6LoWPAN, COAP, and other protocols and how embedded developers can take advantage of them. I am still wading my way through the many articles and standards documents trying to learn as much as I can as fast as I can. In relation to COAP and its use of UDP, I still have a lot of questions.

First, even with all the thought that’s been put into 6LoWPAN and into such protocols as COAP, will it be enough to penetrate more than the a small portion of embedded applications, especially those in hard real-time and deterministic applications in machine control and industrial control? The original uses of UDP were in wired networking applications that were by-and-large isolated from the outside network and so could make compromises on security and reliability. Not so in 6LoWPAN environments, which are naked to the world and require connectivity to the wider Internet.

Second, compared to the minimalistic UDP implementations that I have seen in the past, the UDP implementation within COAP is positively pudgy. Would this eliminate its use in most sensor networks using 8- and 16-bit MCUs?

Third, why was the UDP subset the one that was chosen? Because of the sparse resources it requires, it was certainly most obvious choice. However, there are other variations, such as the TCP extensions for Transactions (T/TCP) that might have been a better starting point. While more complicated and less resource-efficient, T/TCP would be a case of taking one step back in order to take two steps forward: Even though it requires slightly more memory and is less efficient in terms of bandwidth than UDP, it has features that the COAP implementers had to add in to their UDP-derived scheme after the fact.

What is missing in almost everything I have read is an informed embedded systems developer’s perspective. For that I look to you, in your comments here, in emails to me, or in blogs and design articles you can contribute for use on Embedded.com or in ESD Magazine.