Standards for connected objects (including motes)
This post is technical, I explain the internet of things protocol stack for wireless sensors. In my previous post I described the internet of things as
A “thing” is any object with an embedded circuit board that is programmable. This object would have a virtual address and network connection. The “internet of things” is connected objects that can send and receive messages to communicate with each other.
This can be re-stated in even more technical language. I could say something like: a thing is any object which has a programmable microcontroller and 6LoWPAN radio module on top of which I can securely run a MQTT client server. 6LoWPAN and MQTT are protocols. 6LoWPAN comes preloaded on embedded circuits and handles sending and receiving data. Software engineers add application messages to the data sent by 6LoWPAN using MQTT.
A sensor network is designed for resilience and battery power efficiency and MQTT helps software engineers design and build machine to machine systems. The standards have been evolving for the past decade and are mature. All the pieces of the technology jigsaw are in place for the predicted explosion in M2M communications.
We can build M2M, internet of things today. We’re moments away from another internet revolution.
6LoWPAN, Zigbee & 802.15.4
6LoWPAN is an IETF project, based on RFC6282, to adapt IPv6 for low power hardware. 6LoWPAN has a new, nicely named, routing algorithm called LOAD. 6LoWPAN handles service discovery. Higher up the stack, the frame size and transmission speed of TCP and UDP have been adjusted to be resistant against transmission errors; packets have a very short length. Linux 3.2 has 6LoWPAN support.
These protocol families are the building blocks on which connected objects send messages to one another. The ecosystem of connected objects can have a mesh, star or peer to peer network topography.
The “internet of things” transmits and receives on a tiny fraction of electromagnetic spectrum, 868/915 MHz bands in Europe. 868/915 MHz offers better distance over 2.4GHz where WiFi operates.
MQTT is a publish and subscribe protocol for M2M communications over low latency or constrained networks. It is used by Facebook in their mobile messaging app. MQTT-S was originally developed for running on top of the ZigBee and most importantly, it solves several common problems associated with M2M environments including
- managing thousands of remote sensors in 6LoWPAN IPv6 networks.
- collecting data from sensors and sending it to applications.
- communicating actions back to sensors.
- managing the real-time, deterministic nature of such communications.
MQTT is data-centric, it separates data (payload) from metadata (topic). Sensors/Nodes produce information (publishers) on “topics” (e.g., temperature) by publishing “samples”. It delivers the samples to all subscribers that declare an interest in the topic. Publish and subscribe architectures suffer at scale. As nodes increase, the network slows down and suffers from load surges. However, Facebook plan for client numbers in the billions. There are two parts to the MQTT, clients and servers/brokers. In a sensor network clients are sensors and brokers may be a mobile app or a gateway to connect the sensor network to the cloud.
MQTT is broadcast, 1-to-many, where the messages fan-out across the system. Topics have hierarchal structures like a filesystem, that support wildcards. For example
Clients can provide a Last Will and Testament (LWT) message, during connection, to be published if the client disconnects unexpectedly. Clients can also use sticky (non-clean) sessions to ensure they receive messages published whilst they were disconnected.
MQTT has three QOS levels. They’re not always fully supported by MQTT implementations.
The lightweight nature of MQTT is important in constrained environments. This is the reason given by Facebook for their decision to use it in their mobile apps. The publish and subscribe messages are 4 bit codes. This is important given the very short 6LoWPAN packet length.
|1||CONNECT||Client request to connect to Server|
|5||PUBREC||Publish Received (assured delivery – 1st step)|
|6||PUBREL||Publish Release (assured delivery – 2nd step)|
|7||PUB COMP||Publish Complete (assured delivery – 3rd step)|
|8||SUBSCRIBE||Client Subscribe request|
|10||UNSUBSCRIBE||Client Unsubscribe request|
|14||DISCONNECT||Client is Disconnecting|
In 2011 IBM and EuroTech donated MQTT to Eclipse MGM WG.