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

28 thoughts on “The Internet of Things Protocol stack – from sensors to business value

  1. I like your approach with the diagram. A couple suggestions…

    – add power line carrier (PLC) to the PHY layer.
    – drop Zigbee. Its a full stack (802.15.4e covers this at the MAC layer)
    – I’d place 6LoWPAN up with IPv6 and also add RPL (IPv6 / 6LoWPAN / RPL).

    Thanks

  2. Thanks Paul, I will make those changes. I did struggle a bit with zigbee, maybe you are right I could drop them but they are “known” as a way to connect things so I wonder if they should still be somewhere.

  3. Nice diagram. I would overlay an end-to-end security model.

    FYI : Zigbee is very common and is currently deployed in 40% of the USA Smart Meters (Smart Grid – Utilities).

    Geoff.

    OASIS MQTT Secretary, OASIS MQTT Security Chair.
    CEO Machine-To-Machine Intelligence (M2Mi) Corp.

  4. Great start, I like the stack. Weightless is gaining some ground for wireless communication in sub 1Ghz bands. It could be added in the link protocol layer

  5. Thanks! This is an interesting article and shows how much work is still ahead of us. The OSGi Alliance works with other SDO’s on a device abstraction layer, that definitely can help to move forward. Also OSGi provides a dynamic software platform that enables the integration of many protocol API’s so that the interoperability of devices is secured. Have a look: http://www.osgi.org and get involved https://github.com/osgi/design/tree/master/rfcs/rfc0196 – the OSGi work is made available for public comments.

  6. I’m curious. The protocols in your IoT technology stack are already leading standards themselves. Are you suggesting that those be further standardized down to just but a handful, say 5? That doesn’t seem realistic. Couldn’t that impact creativity/innovation? Like businesses, technology is domain specific and protocols are no different. New problems will require new solutions and perhaps new protocols and standards and where old protocols fade or slowly wither away. The best old standards can hope for are to be abstracted into new frameworks and/or standards. Most people don’t use Corba objects directly anymore because of how well it has been incorporated into the Java environment. I do agree we are seeing an increase in speed of advancement of technology realizing net gains in business values. And ultimately, standards are funded by businesses in an attempt to solve technical problems and as long as there are businesses, it is a safe bet there will be more standards to come.

  7. These hardware require to be set up via a program plan in advance of it can run.
    Sometimes, the direct technique in marketing is
    too commercialist for anyone’s appreciation.

  8. Pingback: Internet of Things Landscape Beyond Things | Entrepreneurship Talk

  9. Pingback: Verteilung von Big Data: Eine Herausforderung im IoT-Umfeld – Business und Software Blog

  10. Somebody necessarily assist to make seriously articles I would
    state. That is the first time I frequented your website page and to this
    point? I surprised with the research you made to make this particular put
    up amazing. Magnificent task!

  11. This is an interesting Article.
    I just wanted to know in which layer TCP/IP, UDP protocl fits in this protocol stack ?

    • Hello Avinash, they would really be in the session layer (just above transport) but because I emerge communication protocols like MQTT with a pure session layer (where TCP and UDP would be) I didn’t really include then for the sake of simplicity. It would t be fair to have TCP and MQTT at the same level and having a stand alone layer for UDP and TCP was just overkill in my opinion. Cheers

  12. Hello apassemard, thanks for your Quick reply one more question is in connectivity layer you have ODB2. is it OBD which is for cars or any protocol ?

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s