"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.
6loWPAN is the Layer 2 protocol over IEEE802.15.4. This allows IPv6 packets to be transported across a low power IEEE802.15.4 wireless connection. But just like TCP and HTTP are run above IPv4 and IPv6, we need a generic protocol that will run about 6loWPAN. CoAP (Constrained Application Protocol) is one of the possibilities for this.
CoAP is designed on the REST architectural model. That is, it is essentially another implementation of REST on a different underlying protocol. The concepts are the same, the implementation is different.
There are a large number of protocols that run above IP. The most common are TCP and UDP. TCP is heavyweight for low power devices, so UDP is preferred. But UDP does not set up a session for request/response like TCP does. Nevertheless, CoAP is chosen to work over UDP, with missing features from TCP added into this protocol as needed.
Each CoAP message occupies the data section of one UDP datagram
Each message is either a method or response. A token Message ID is passed in each request method call and will be returned in a response to allow the client to link the two together. A request is carried in a Confirmable (CON) or Non-confirmable (NON) message. The response to a Confirmable message may be given in the corresponding ACK, or deferred until later. Note that the ACK is not the same as the Message ID token.
Strings are passed in UTF8 format. UTF8 is the 8-bit representation of Unicode characters. Unicode is a complex character set, designed for representing all of the world's languages (artifacts such as Klingon and Tolkein's elvish may also be represented!). Unicode attempts to be backward compatable to some features of prior character encodings. While the primary example is of the ASCII occupying the first 128 locations, there are more obscure cases: a character such as à (Latin small letter a with grave) can also be represented by the triple "a+backspace+grave". Unicode has a 'normalisation' mechanism to resolve this and related issues, but the algorithms are complex and not desirable for constrained devices. Consequently, all these edge cases are ignored and it is assumed that there is no need to normalise the strings so that they can be compared as opaque byte strings.
CoAP implements a lightweight reliability mechanism, without trying to re-create the full feature set of a transport like TCP. It has the following features:
Resources can be interacted with. You can query them for values (GET), and change values (PUT/POST). To do this, they must be running a a CoAP server. In a large network, there may be hundreds or thousands of these servers. A client needing to interact with, say, particular types of resources will firstly ahve to find the resources, work out which of them are the right type, and then interact with them. This is the realm of resource discovery.
This needs to be distinguished from host discovery, where you want to find the hosts on a network. That can be done by ARP requests orr by asking a DNS server, for example. We also need to distinguish from services, per se. We aren't looking for mail servers, HTTP servers, or even CoAP servers particularly. We are looking for resources and what we want to find are their URIs, or URLs.
Resources can make themselves available for discovery by listening on the multicast address 224.0.1.187 (IPv4) or FF0X::FD (IPv6), using the default CoAP port 5683. They must also run a CoAP server on the default port 5683 so that once the IP address is discovered, a clinet can interact with the resource on a known port.
Once a resource's URI is known, queries need to be made to discover what the resource is: its type, what content encodings it supports, what are its interfaces and so on. These are all specified by HATEOAS links, using conventions for the specific link types required by the IoT.
The IETF RFC 6690 repeats the link formats for HTML and adds specific link types for the IoT. The additional types include
For XML, presumably the XML Linking Language (XLink) would be used.
CoAP provides a lightweight implementation of REST. Designed for constrained devices, it would generally be used above protocols such as 6lowpan, but could also be used above other layer 3 protocols such as TCP. It adds resource discovery to the standard REST model to allow clients to discover deployed devices.
Copyright © Jan Newmarch, jan@newmarch.name
"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.
If you like this book, please donate using PayPal