原创 Understanding UDP and the embedded wireless Internet of Things (Part 1)

The addition of wireless sensor connectivity to the IPv6 protocol in the form of 6LoWPAN presents a plethora of challenges and opportunities to embedded systems developers. 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.

But if you dig deep enough you will find an old friend—UDP, a subset of the familiar TCP/IP that 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.

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 minimised, 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.

So where does the UDP play a role in the 6LoWPAN-driven, largely wireless Internet of Things (IoT), and how pivotal it is to the success of the IoT and the Web of Things (WoT)?

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.

[To be continued at Understanding UDP and the embedded wireless Internet of Things (Part 2)]