IoT Protocols

IoT Protocols: Introduction

Constrained Devices and Networks

• The IoT market differs from the web browser market due to its focus on small microprocessors and constrained environments.

• IoT growth is driven by constrained devices in constrained networks.

• Examples of applications include:

  • Building automation

  • Remote control

  • Industrial monitoring

  • Low power lighting control

  • Smart meter reading

• Microprocessors in these applications need to operate for extended periods (e.g., 2-10 years) without maintenance, powered by long-lasting batteries.

• The IETF defines constrained devices, with class one devices being typical for IoT.

• Raspberry Pi is not considered a constrained IoT device due to its high processing power; IoT devices are significantly less powerful.

• Class one devices typically cannot employ a full HTTP over TLS stack.

Constrained Environments

• Cheapness is a key factor due to the desire for massive deployment (10,000,000+ devices).

• Target cost is around $1-$2 per device.

• Processors need to be cheap and have long lifespans.

• Networks can be extremely variable; Wi-Fi can be surprisingly unreliable even within a home.

• Low bit rates (e.g., 10 kilobits per second) are common.

• Flash memory size significantly impacts device costs; increasing flash from 100KB to 300KB can raise the price from $1 to $6.

• Common network technologies include:

  • 802.15.4

  • ZigBee

  • 6LoWPAN

  • Bluetooth Low Energy

• Nest devices use two microprocessors:

  • ARM Cortex A8 (expensive) for external communication.

  • ARM Cortex M0 (class one device) for internal communication within a mesh network of Nest devices.

Constrained Application Protocol (CoAP)

• CoAP is a less known protocol that avoids hype and has seen steady development.

• Developed initially by a Finnish startup (later acquired by ARM), it's an open protocol standardized by the IETF.

• It sits on top of UDP instead of TCP.

• Logically, CoAP has two layers: one interacting with the application and another with UDP.

• It's modeled on HTTP, including methods like GET, PUT, and DELETE.

• The message component manages reliability since it uses UDP instead of TCP.

• A CoAP message consists of:

  • A four-byte header with version information.

  • A handle or token.

  • Various options.

  • A payload.

• Headers are small (10-30 bytes compared to potentially thousands in HTTP).

• The code within the header is a binary representation of HTTP methods.

• CoAP uses a peer-to-peer (or person-to-person) request-response model where each node can be both a client and a server.

Message to Server

• A client sends a confirmed or unconfirmed message to a server.

• Unconfirmed requests are used to save bandwidth when the response isn't critical.

• The URI scheme supports standard schemes and SMS:

  • coap://...

  • coap+sms://...

• SMS can be used to communicate with devices lacking an IP address or to provision them with one.

• Resource discovery: servers have a .well-known file listing available resources.

• Devices can broadcast a request for the .well-known file to discover resources.

• Resource types (RT) can be queried; for example:

  • get well-known core?rt=radiation

• This will return information about radiation resources, such as a Geiger counter.

• RT is a noun (resource type), and IF is a verb (interface), indicating what can be done with the resource.

• The size command (SZ) allows clients to request resources smaller than a specified size to avoid memory constraints.

Additional Memory and Protocol

• Clients can specify constraints like resource type, content type, interface (verb), and size when requesting resources.

• The observe pattern allows clients to continuously observe resources instead of sending repeated requests.

• A client sends an observe command to a server to indicate interest in continuous updates.

• The server confirms the observation and sends updates with a token identifying the client.

• Confirmed messages (CON) require an acknowledgement from the client.

• If no acknowledgement is received, the server may retransmit the message and eventually stop sending updates if the client is considered dead.

• The observe pattern is essentially a push mechanism.

• Security is implemented using Datagram TLS (DTLS) instead of TLS, which is more complex to implement with UDP.

• It is recommended to use existing DTLS libraries instead of developing a custom implementation.

• There are many publicly available CoAP implementations; however, their adherence to specifications should be carefully verified.

• A Firefox plugin is available for testing and experimenting with CoAP.

• Writing a CoAP client from scratch (around 70 lines of code in assembler, or 120 in Go without security) is a good way to learn the protocol.

Conclusion

• CoAP is being used by the Open Mobile Alliance (OMA) to create a device management protocol for configuring, provisioning, fault managing, and upgrading devices in constrained environments.

• Arm, Vodafone, and Ericsson are exploring the use of CoAP for various endpoints like cars, planes, washing machines, and TVs.