IoT communication protocols

There are a lot of protocols and communication methods available to IoT based projects and devices. They operate at different levels within the hierarchy and each have different pros and cons for a project like this. I wanted to briefly lay out some of the different options to give some comparison and background.

A lot of what is going on in IoT protocols takes place at the application layer of the protocol stack. The application layer is built on top of the transport layer. In TCP/IP this means either the TCP protocol or the UDP protocol. Different application layer protocols use different transport protocols. This is important to note because the transport protocol used can affect how the system performs, so taking this into consideration when choosing an application layer protocol is important. TCP is a connection based protocol, which means that it is reliable. Eventually, TCP will get your data to where it is going. It may have to retry a bunch of time, lose packets, timeout, and try again. This is good if your data is important, but it could incur very bad power efficiency if you have a spotty connection, and if your data isn’t so important that is has to go out right now, it may not be the best choice, especially if you know you are likely to have intermittent network issues. UDP on the other hand is unreliable, its the fire-and-forget protocol that plays it fast and loose. This means your data may never make it to its destination, but whatever your device will already be passed out on the couch again.

The following are some of the different application layer protocols that could be used to implement communication with an IoT device.

WebSockets

One method for bi-directional, on demand communication is websockets. WebSockets are part of the HTML5 specification and is largely used for real-time pushing of data from a server to a web-client. In traditional AJAX, most if not all communication begins on the client, requesting dynamic content from the server. This is used to update the UI dynamically without refreshing the page. This has drawbacks however, what if you are viewing “shared data” that can be updated by someone other than you, if this happens your data is out of date. Polling has been used for a long time to refresh that data, but WebSockets allow for a real time bidirectional connection between the server and the client, so the server can update any and all clients immediately when their data is out of date.

This is very cool from a embedded systems perspective, and I implemented a very rudimentary version of this for a independent study class (when I say very I mean very, it was just a physical LED and switch tied to a virtual LED and switch, the virtual switch turned on the physical LED and the physical switch turned on the virtual LED), but this was before I knew of WebSockets (and I was very inexperienced at javascript at the time) so I fell back on long polling  to get things done (which was pretty ugly tbh). Using HTML5 style websockets would require either a) implementing them myself in straight TCP sockets on the server and client (doable, probably in straight C and simplified), b) finding an embedded system library or a platform that already allows for this (better, more mature solution, but might limit my platform choices). This kind of real time async communication, while neat, doesn’t really lend itself to a battery powered remote system like mine, because I am more interested in trends rather than instantaneous values.

6LowPAN

Another option for server-originated communication is the 6lowpan technique, which since I first started reading about went from a “roll your own if you want it” option to now where you can actually buy 6lowpan hardware and development kits (that probably are somewhat proprietary and non-standard). The central idea here is that you have a 802.15.4 (*Bee) network in some star configuration with an “edge router” (I’ve seen it called that, not sure if that is the standard name or not) that serves as a translator between an IPv6 network and the *Bee network. In addition to the link/mac layer 802.15.4 traffic (which does not define a network or above layer, so no way to route data between networks), the 6lowpan spec defines a very minimized set of IP headers that make the *bee packets routable, which is very slick. The result is a system where you could have a big network of low-powered *bee based devices that have IPv6 addresses, these devices could host a web server/services (REST, SOAP [probably not]) that actually serves dynamic content on demand. The different here would be, instead of the device pushing the data to a remote database that then I would access when I wanted it, I would actually access the device directly and pull data from it. This means much more real-time access, in fact I could initiate a sensor reading right then and there to get some real fresh compost data (ew). However, this type of system requires more hardware, and the power management software on the device would have to be much more complicated to be able to wake up the device when a connection comes in and then put it back to sleep afterwards. I only have 1 device in mind right now which makes the hardware overhead pretty high, but this is cool as hell and I might try to implement it later.

The physical layer in this case is not that interesting, it is going to be RF for sure, which leaves either 802.15.4 or 802.11x or some proprietary low-frequency transceiver based dealy. As I may have mentioned before, I already have a WiFly unit and you can’t get cheaper than on-hand, right? This hardware selection picks a lot of levels of protocols for me actually, physical from 802.11b/g, link/mac (WiFi), transport (TCP or UDP) and optionally HTTP/FTP/etc on the application layer (which is optional with the WiFly).

I’ll try to be pretty brief in describing other choices here. If I went with a *Bee (802.15.4) wireless device here that would only handle the physical and link/mac layers for me (link is the lowest-level addressing layer, the ability to tell the difference between two network devices, while the MAC part of layer 2 describes how multiple networking devices share the same medium, ie the electromagnetic spectrum). The only real reason to go with *Bee would be to a) get a lower powered device or something that runs in the 900Mhz spectrum (longer ranges, better penetration of walls, obstacles) OR to run a 6LowPAN network like was discussed above. Now, if I wanted to go really cheap, I could go with a transceiver based setup where all I get is the physical layer and I have to write everything else in software (why is that kind of appealing?). This would be a great learning experience but in reality if my time is worth $0.01/hr, the $30 bucks for an *Bee or *Fi device will be well spent. Plus I do want to see those hot compost readings sometime soon, right? This is an area of optimization if you wanted to make a commercial product down the road, but I’m not thinking about that right now.

Ok that wasn’t that brief but if you are new to this stuff its helpful to have it broken down. Now to the interesting part of the protocol dicussion, the application layer. You might notice I skipped the network layer and transport layer, the reason for this is that a) the network layer for me is going to be IPv4 for now since I don’t really need any of the added features of IPv6 and I’m not even sure my WiFly supports it. Transport is either TCP or UDP, depending on which application layer+ protocols I choose.

HTTP+

What the + means here is that while the application layer is the highest layer of the TCP/IP model (not the OSI model though), there are other “protocols” that can be build on top of an application layer protocol (the most notable application layer protocol being HTTP). The HTTP protocol is by no means the only application layer protocol that could be used here, in fact there is a lot of work in the IoT space to develop more nimble, efficient protocols for IoT data. The reason for this is because the HTTP protocol has a lot of overhead since its main job has been for many years to serve up static content (web pages). It has been modified and adapted to serve up all kinds of other content though like dynamic HTML, XML, and most recently and popularly, JSON. Serving up and receiving JSON formatted data is the bread and butter of the REST web service architecture. RESTful web services use HTTP (on top of TCP) as the plumbing for writing cozy API’s that are nice to work with with AJAX. This is not a bad option for me because there are TCP and HTTP features on the WiFly to. In addition, a lot of my work involves REST API’s so the learning curve is much lower. There are however some alternatives that are more in the IoT realm that I am considering so as to get some experience in real IoT technology that might look good on a resume down the road.  Since HTTP is built on TCP, it is reliable and I can expect my readings to get recorded or my device will (literally) die trying.

MQTT

MQTT has been around for a while and began its life at IBM. I am not an expert in MQTT but I have been doing a lot of reading about it and trying to understand whether it would make a good fit for my project. Here is a good example of MQTT in action. My understanding of MQTT is that it is somewhat like the Observer design pattern with a few differences. In the observer pattern, any entity can implement the subject interface, which gives it the ability to be subscribed to by objects that implement the observer interface. This means when something changes on the subject, the subject calls the notify() method on all of the objects that are subscribed. An object can be both an observer and a subject, which means two objects could be interested in what each other does, so they are both subjects and both observers, passing updates back and forth. MQTT has a similar publish/subscribe paradigm where each node can be both a publisher and subscriber to different “feeds” (my term) that are loosely defined. The difference here seems to be that there is some kind of central system to which all of the nodes are connected, which is like a server. There seem to be a lot of MQTT servers out there, one of which at least is based off of IBM WebSphere. Each node that wants to publish and subscribe could be implemented in totally different ways, you could have a phone app, embedded system, desktop system, RSS Feed, Twitter bot etc that all have publish/subscribe abilities in the MQTT network, they just have to implement the interfaces that allow them to connect to the MQTT server. With the beauty of abstraction, the connections between the MQTT server and connected devices could be lots of different things. For instance, using MQTT I could have a web service that was subscribed to my compost monitor whose sole job was to make tweets when my compost monitor publishes a new datapoint. My compost monitor could subscribe to configuration settings like how often to sample. How often to sample could be published by my phone, my desktop, or even remote users on my twitter (I don’t actually twitter really its just an example). Another subscriber could be a storage system that uses MongoDB and a nodejs REST API to make the information available forever. From a power consumption standpoint, my embedded system would probably just be a publisher, else we run into the same situation with 6LowPAN and WebSockets, but it is a very elegant solution to how to organize a whole house full of instrumented things! MQTT is designed to use TCP by my understanding, but there are discussions on the webs about MQTT as an unreliable (UDP) protocol.

CoAP

CoAP is another effort to reduce overhead in the application layer for IoT type (constrained) devices. CoAP is cool because it is designed to be closely compatible with HTTP and REST, but rather than simply compressing HTTP headers, it is a totally seperarate protocol that maintains the same stateless interactions that HTTP does but with vastly lower overhead. This means that CoAP requests and responses can be easily mapped to full blow HTTP requests and responses, allowing the transition to the web to be a lot easier. My reading about CoAP has left me with the sense that it might be overly complex for my needs, but this presentation indicates some of the promise of using it. What it would entail would be much like MQTT, running a specialized UDP based server to be the endpoint for the CoAP traffic, converting CoAP requests to HTTP and converting the HTTP responses back to CoAP responses.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s