The Internet of Things Protocol stack – from sensors to business value

There is no doubt that we are entering a new era.. An era that will change the world more than the Internet did 15/20 years ago. This era is the Internet of Things, or IoT. John Chambers, the CEO of Cisco is going on a crusade to tell the world about and is driving many conversation with his potential $19T in economical impact from efficiency gains to pure economical growth. I have personally never seen a number that big, and it’s starting today.

Granted connecting objects is not something new, we have had connected machine for more than 15 years. Axeda, one of the leading solution providers in connected machine, has been in business since 2001! What has changed is that now: 1- it’s becoming cheap to connect machines to the internet. Very cheap. Hardware is affordable and even open source: Raspberry Pi announced it’s 2M unit sales in November 2013! Knowing that they compete with Arduino, Mbed and others, I am astounded by the cheer volume of supposedly “hardware enthusiasts”. This not a hobbyist game anymore, it’s everywhere. I personally played around with an Mbed and a Spark Core using Cloud based backend from Xively. It’s so easy, it amazed me and got my imagination going on a few projects.

But where is the catch? I’ll be honest: Standardization. The IoT landscape is a mess! Too many protocols, too many wannabe standards, too many revolutions. It will calm down and consolidate but for now it’s creating more mess with every new device that comes out on the market.

I’ve decided to give a try at describing that mess through a protocol stack that I’m hoping to be useful for others. My goal was not to be exhaustive in anyway, I don’t even think it’s possible. But I hope that I captured the most common protocols that people encounter on in a day in the life of an guy in IoT.

IoT protocols stack

 

[Note: This diagram has been updated based on comments and feedback received since Jan 29]

What I found important in this stack was to add a Business value layer, because what’s the point of connecting devices if in the end there is no business value.

Some will find similarities with the ISO stack (Link layer, Transport, Session, etc..) and there are some, but I wasn’t particularly trying to map to it. It just happens that the ISO stack is foundational to the Internet and as a consequence in the DNA of everything Internet.

Protocols you will find in there:

Connectivity layer: What kind of physical connectors you can find. RJ45 (the physical connector, usually for Ethernet), PLC, RS-232, RS-485, ModBus, USB (as a connector type, not the communication protocol), SPI, ODB2 (in Cars), and Wireless (no connector!). You will sometimes find gateways that will convert any of those physical connectors into wireless.

Link Protocol: How do those device actually send the data. Ethernet 802.3, Wifi 802.11a/b/g/n, BlueTooth, BLE, Dash 7, ZigBee, RFid, GSM, 6LoWPAN, 802.14.5e. The last two are really focused on the IoT use case. I have put ZigBee here only but I am well aware that ZigBee covers a large portion of the entire stack. To avoid too many redundancy, I had to make a decision on where it would fit best.

Transport: IPv4 and IPv6. I also added 6LoWPAN and RPL despite the fact that they are both based on Ipv6. The IPv6 has been a long time coming and was supposed to be adopted by everyone 10 years ago, but now with the projection of having 50 Billions devices connected in 2020 (according to Gartner), we have to go to IPv6! What was interesting is that I haven’t found much of anything beside the IP protocol out there which proves the dominance it has acquired through the rise of the Internet.

Session / Communication: This section is an interesting bunch with a lot of new protocols that have been build for super high volumes and large networks of things. The most famous right now is MQTT, a subscribe and publish protocol that is used by Facebook for its mobile app. You will also find CoAP (kind of a REST Based protocol but much more efficient than its HTTP counterpart), DDS, XMPP and AMQP that are all well suited for IoT and will map different use cases. One will still find older protocols like FTP, Telnet and SSH, but even though they are working very well, they are resource intensive, power intensive, and do not fit well with the low power, unreliable bandwidth of the IoT realm.

Data Aggregation / Processing: This is where it gets really interesting. When device send data, lots of data, you need an end point to do something with it. Be it processing it in real time (with Storm), but at minimum getting the data and sending it somewhere else at very large scale, which Kafka is a great example of. Other solution exists like RapidMQ, Scribe, Plume, Luxun, Fluentd (although more on the translation to JSON side)

Data Storage / Retrieval: The realm of Big Data backend and NoSQL solutions. Hadoop, HBase, MongoDB and Cassandra dominate the field. There are others, like the google AppEngine,  but I may add them later on if they start appearing more in IoT use cases.

Business Model: This is a new addition fro, the initial post. This layer is trying to capture the fact that business value and business processes always rely on an underlying business model. Open or Closed, Integrated or platform, direct sales or indirect, cloud based or on-premise (or private cloud), on-demand pricing, etc.

Business Value: I’ve split it in three. One part if around Device Management, the provisioning, registration, firmware management, remote access, but also the product and asset structure as well as Security (tremendously important, especially as we just went through the first massive Connected Devices attack just a couple of weeks ago. The second section is to highlight the birth or transformation of Service for smart devices, Marketing for owners of smart devices and the impact on manufacturing those smart devices.  Finally, the analytics piece shows how much technology could be applied to the data gathered, With machine learning algorithms, data mining, and all the insights and visualization that can be derived from it.

With such a representation of the most common protocols, the need for consolidation really becomes obvious, the IoT cannot keep going with so many protocols if the dream of having any devices talk to other devices in a fully connected world wants to come true. In any case, it’s fascinating.

Advertisements