Here is my Internet of Thing communications model:
This model tries to cover at least the most IoT situations.
The idea in this model is to describe the IoT communications at suitably accurate level to cover normal situations. A real-life implementation can have all those part or it can have more than one step of the model integrated into one device. In real-life networks there can be less firewall than this model (some of the firewalls are replaced with just routers).
Let’s consider situation where there is an IoT sensor that measures something (for example temperature) and sends the data to IoT cloud where the results can be read or processes.
This model on the left there is the sensor that measures the temperature. Typically the sensors itself do not communicate directly with Internet. The data goes to IoT gateway that converts the sensor data suitable to be sent over Internet. Typically sensors are connected to IoT gateway using a communications channel that does not use TCP/IP. Typical interfaces between sensor with digital interface and IoT gateway are wired serial buses (RS232,RS485,SPI,I2C, etc.) and short range wireless networks (Bluetooth, Zigbee etc..).
The IoT gateway takes the measurement data, converts it to suitable format so that it can be transported over Internet to IoT cloud service. The communications between IoT gateway and IoT cloud typically uses some higher layer protocol (for example XML-RPC, JSON-RPC, RESTful API or a custom made protocol) running over TCP/IP (TCP socket, WebSocket etc.). A typical IoT gateway nowadays is a small embedded computer running Linux. It typically has some form of built-in firewall.
From IoT gateday the data goes to Access Network. That access network is typically wired Ethernet LAN, wireless LAN system (typically WLAN base station + Ethernet network after it), a cellular phone network (GPRS, 3G, 4G) or something similar.
From Access Network the data goes to public Internet. There is a router between Access Network, and typically nowadays there is some sort of firewall functionality in it. Typically in corporate networks this firewall has nowadays passes only some services, has some form of state-full firewall in it (for example allows the connection opened from Access Network to Internet direction) and there can be NAT functionality (allows the connection opened from Access Network to Internet direction and changes IP address and port numbers).
The public Internet carries the data toward IoT cloud service. Typically the cloud service data center has a firewall. This cloud service firewall can be a simple firewall or a complicated firewall that carefully validates data before it enters the IoT cloud servers. Sometimes the firewall can have also built-in load distribution service (distributes incoming data evenly to a cluster of IoT servers). Typically the IoT cloud server collects the incoming data so some form of database (SQL or NoSQL database) where it can be accessed through some API provided by the cloud service provider. Typically the data stored on measurements is the measurement value and time stamp when measurement was made. When you collect data from lots of sensors for a long time you have easily a very huge amount of data (=Big Data).
I plan to use this model in some future postings on IoT. The IoT field is so large and varying that it would be impossible to put all the details on one posting.
14 Comments
Tomi Engdahl says:
The Internet of Things is creating tremendous hype, sometimes with seemingly little substance. There is real power and value to the concept, but it requires a new approach to make it work.
Traditional client-server network protocols and master-slave industrial protocols don’t scale to the IoT
Existing network infrastructures aren’t ready for the numbers of connections that are forecast
And the best kept secret of the industrial IoT, over 85% of the billions of new connections that are forecasted are devices and assets that are already deployed
Tomi Engdahl says:
3 architectures dominate the Internet of Things
http://www.edn.com/electronics-blogs/eye-on-iot-/4436960/3-Architectures-Dominate-the-Internet-of-Things?_mc=NL_EDN_EDT_EDN_weekly_20141106
In many discussions, especially around standards, the Internet of Things (IoT) is treated as though it were a single technology. But one reason there are many standards and technologies vying for a role in the IoT is that a single approach will not fit all the use cases. There are at least three main architectures for IoT system design in play, each imposing different requirements and constraints on device design.
The hub-and-spoke model is used when the IoT device is a reduced-resource (thin client) design that links to a hub or gateway device for ultimately connecting to the Internet. The hub/gateway handles the relatively compute-intensive tasks of network security and pre-processing of data as well as all the protocols associated with communicating to the wide area network and application services.
Front-loaded IoT designs use devices more capable than the thin-client designs of the hub-and-spoke architecture. These devices are capable of handling their own wide area network interfaces and preprocessing of data using more powerful processors and radios. They often communicate to the Internet for reporting and control as individuals, either directly or through a local area network router that is acting simply as a relay point, not a control center.
Smart client designs take things one step further. These are relatively autonomous devices that devices process their own data locally and act upon that data autonomously. They are also able to exchange information and exercise control peer-to-peer within their local network. They use their wide area network connectivity primarily as a means for sending in data for deeper analysis.
Yet in the design and standards discussions about the IoT I have seldom heard things prefaced with a declaration of which architecture is being talked about. Arguments of WiFi vs. Zigbee or CoAP vs. MQTT vs. XMPP can be totally unproductive if the proponents of competing alternatives are also envisioning differing architectures. Let’s start such discussions by first declaring which IoT system architecture
Tomi Engdahl says:
Why HTTP won’t work for IoT
http://www.edn.com/electronics-blogs/eye-on-iot-/4437056/Why-HTTP-Won-t-Work-for-IoT
Are you trying to fit devices into the Internet? If so, HTTP isn’t going to work. There are much better options. In this post I will introduce how protocols are used in IoT and analyze the current options.
HTTP is for the Old World Internet. The New World Internet (the IoT) is made up of unseen devices that require very little interaction. They consume very little power and frequently have poor network connectivity. HTTP is too heavy to be a good fit for these devices. An HTTP request requires a minimum of nine TCP packets, even more when you consider packet loss from poor connectivity, and plain text headers can get very verbose. And even with all this overhead HTTP doesn’t guarantee message delivery!
The HTTP overhead also adds to IoT operating expenses.
Fortunately there are suitable alternatives to HTTP for communicating with IoT devices.
IoT network traffic falls into two categories: telemetry and telecommand. Telemetry is the act of gathering telemetrics, or sending data over long distances. Usually telemetry involves sending data from many dumb sensors to a smart hub of some sort. The dual of telemetry is telecommand, or the act of sending commands across a network.
Most telemetry protocols are modeled as publish/subscribe architecture. Sensors connect to a broker and periodically publish their readings to a topic. A central cluster of servers (the cloud) will then subscribe to the topic and process sensor readings in real-time.
MQTT (Message Queue Telemetry Transport) is the leading telemetry protocol. It typically runs on top of TCP, adding only a 2-byte header.
MQTT has a couple variants. First, you can run MQTT over SSL/TLS to create a secure connection that’s safe against man-in-the-middle attacks. Second, MQTT-SN (MQTT for Sensor Networks) is made to run over a non-TCP/IP stack.
MQTT provides a lot of functionality for such a low overhead. It’s oriented toward devices with low bandwidth requirements. However, I think that the debugging experience is sacrificed.
There are alternatives to MQTT: STOMP, XMPP, and ActiveMQ all are sometimes used for telemetry. They all meet M2M requirements to varying degrees, but I think MQTT and variants are superior for low-power devices and are most likely to become ubiquitous.
Tomi Engdahl says:
Understanding How IoT Systems Scale And Evolve
http://electronicdesign.com/communications/understanding-how-iot-systems-scale-and-evolve
The next wave of the Internet won’t be about people. The Internet of Things (IoT) will connect machines and devices together into functioning, intelligent systems. It promises to transform many industries. Much of the buzz is about consumer devices: how your thermostat can adapt to your lifestyle, or how your sprinklers will save water by knowing when it’s going to rain.
But the more exciting applications are the new, complex, distributed systems that simply aren’t possible today: intelligent cars and highways, smart energy grids, and brilliant hospitals built of connected devices. These complex systems must be assembled from distributed components that connect through an information distribution and sharing technology.
Data-Centric Infrastructure
Several protocol standards address IoT challenges.1 The Data Distribution Service (DDS) most directly addresses the development of intelligent distributed machines. DDS can deliver data at physics speeds to thousands of recipients with strict control of timing, reliability, failover, and language and operating system (OS) translation.
Air traffic control systems such as Nav Canada, large wind farms from Siemens, and complex medical devices all are complex DDS IoT applications. These systems clearly need performance, reliability, and scale. But some of the larger challenges are not so obvious. One of the most critical yet rarely understood problems is system complexity management and evolution.
Large distributed systems may include thousands of applications with millions of connections. Through DDS, these applications share information by publishing or subscribing to the data they need. DDS discovers the sources and sinks of information, matches the requirements on both sides, and then delivers the data as ordered.
DDS is a data-centric technology. It locates, filters, controls, and exchanges information flow with a known data model. Data centricity is not a new concept. Databases are data-centric technologies for storage. DDS is a data-centric technology for moving data. Like a database, DDS manages the system data types and interfaces for distributed systems.
Tomi Engdahl says:
Lecture 11
Internet of Things (IoT)
Web of Things (WoT)
http://cis.k.hosei.ac.jp/~jianhua/course/ubi/Lecture11.pdf
Tomi Engdahl says:
Understanding The Protocols Behind The Internet Of Things
http://electronicdesign.com/embedded/understanding-protocols-behind-internet-things
the next wave of the Internet is not about people. It’s about intelligent, connected devices.
To interact successfully with the real world, these devices must work together with speeds, scales, and capabilities far beyond what people need or use. The Internet of Things (IoT) will change the world, perhaps more profoundly than today’s human-centric Internet.
Protocol Overview
MQTT
XMPP
DDS
AMQP
Tomi Engdahl says:
5 rules for playing nice with IoT gateways
http://www.edn.com/electronics-blogs/eye-on-iot-/4437896/5-rules-for-playing-nice-with-IoT-gateways-?_mc=NL_EDN_EDT_EDN_today_20141210&cid=NL_EDN_EDT_EDN_today_20141210&elq=74338f0c2fb74ad88516d8ddfd90e6bb&elqCampaignId=20600
If the IoT is to prosper, it will need to scale massively. Devices old and new, complex and simple, intelligent and, well, not so intelligent will all need to work together without getting in one another’s way. One of the IoT’s main challenges will be the design of devices and their gateways to support interoperability.
As I mentioned in my last blog, the essential function of any IoT gateway is to establish and maintain a secure, robust, fault-tolerant connection between a cloud service and edge devices. Essentially, the gateway is the traffic cop of the IoT. It manages all the on-ramps and makes sure the traffic flows into and out of the cloud smoothly.
Here are some thoughts to consider when designing a modern IoT device.
Please talk to me
Respond quickly
Don’t be chatty
Never just go away
Tolerate multiple masters
Tomi Engdahl says:
The Internet of things in summary
The Internet of things is the new cloud — meaning a term with a tenuous meaning due to marketing misuse and abuse. The term itself is confusing because you don’t need the Internet for the Internet of things — local networks count, too.
But you’ll need a local sensor, a means to connect data to an item that can act on the information — often back to the device with the sensor, but not necessarily so. Objects that can sense and systems that can act on that sensing ultimately comprise the Internet of things.
As a result, you can get directions as you drive, have your home heating adjust itself based on whether you are home, track and present your physical activity, signal a warehouse operator to replenish a parts bucket, silence incoming calls when you are in a dark room (such as when sleeping), or alert a nurse when a patient’s vital signs go out of prescribed bounds.
Essentially, the Internet of things is about sensing, analyzing, and acting or responding based on local context.
Source: http://www.infoworld.com/article/2855211/internet-of-things/the-power-of-2-liquid-computing-plus-the-internet-of-things.html
Tomi Engdahl says:
Why HTTP won’t work for IoT
http://www.edn.com/electronics-blogs/eye-on-iot-/4437056/Why-HTTP-Won-t-Work-for-IoT
Are you trying to fit devices into the Internet? If so, HTTP isn’t going to work. There are much better options. In this post I will introduce how protocols are used in IoT and analyze the current options.
HTTP is for the Old World Internet. The New World Internet (the IoT) is made up of unseen devices that require very little interaction. They consume very little power and frequently have poor network connectivity. HTTP is too heavy to be a good fit for these devices. An HTTP request requires a minimum of nine TCP packets, even more when you consider packet loss from poor connectivity, and plain text headers can get very verbose. And even with all this overhead HTTP doesn’t guarantee message delivery!
Fortunately there are suitable alternatives to HTTP for communicating with IoT devices.
IoT network traffic falls into two categories: telemetry and telecommand. Telemetry is the act of gathering telemetrics, or sending data over long distances. Usually telemetry involves sending data from many dumb sensors to a smart hub of some sort. The dual of telemetry is telecommand, or the act of sending commands across a network.
Most telemetry protocols are modeled as publish/subscribe architecture. Sensors connect to a broker and periodically publish their readings to a topic. A central cluster of servers (the cloud) will then subscribe to the topic and process sensor readings in real-time.
MQTT (Message Queue Telemetry Transport) is the leading telemetry protocol.
MQTT has a couple variants. First, you can run MQTT over SSL/TLS to create a secure connection that’s safe against man-in-the-middle attacks. Second, MQTT-SN (MQTT for Sensor Networks) is made to run over a non-TCP/IP stack. This could mean using UDP, SMS, or a variety of packet-based wireless protocols. I believe MQTT-SN is promising, as recent results may indicate problems in certain TCP-based protocols over cellular networks.
There are alternatives to MQTT: STOMP, XMPP, and ActiveMQ all are sometimes used for telemetry. They all meet M2M requirements to varying degrees, but I think MQTT and variants are superior for low-power devices and are most likely to become ubiquitous.
So, don’t use HTTP for the IoT. HTTP was created for the “command ->” response required by web pages and applications. IoT has different requirements. Wireless bandwidth is placed at a premium.
Tomi Engdahl says:
8 attributes IoT gateways need
http://www.edn.com/electronics-blogs/eye-on-iot-/4437841/8-attributes-IoT-gateways-need
Tolerate intermittent power conditions
Revert its software to a known good version
Be remotely updateable
Tolerate intermittent and dynamic connectivity situations
Be very efficient with network traffic
Consider supporting SMS over cellular
Support some form of local communication
Be absolutely, positively secure
If you can cram all these features into your gateway, you will have gone a long way toward fulfilling the gateway’s primary function. As you can see, it’s not quite so simple. Admittedly, many of these topics could fill blogs of their own.
5 rules for playing nice with IoT gateways
http://www.edn.com/electronics-blogs/eye-on-iot-/4437896/5-rules-for-playing-nice-with-IoT-gateways-
Please talk to me
Respond quickly
Don’t be chatty
Never just go away
Tolerate multiple masters
I know, I know — tons of rules. But with the Internet of Things, the world is about to embark on one of the most amazing and ambitious endeavors of all time, more so than the original Internet (of people). This time, the machines will be doing the talking — to one another. But if we don’t get things right, the IoT will make the Tower of Babel seem like a family picnic.
Tomi Engdahl says:
3 architectures dominate the Internet of Things
http://www.edn.com/electronics-blogs/eye-on-iot-/4436960/3-Architectures-Dominate-the-Internet-of-Things
In many discussions, especially around standards, the Internet of Things (IoT) is treated as though it were a single technology.
My thinking on this topic crystallized recently upon reading a whitepaper from Gigaom Research, sponsored by Wind River Systems, entitled “Enabling IoT.” In it, author Jon Collins nicely articulates the three main architectures that I now see many IoT designs as belonging to: hub-and-spoke, front-loaded, and smart client.
The hub-and-spoke model is used when the IoT device is a reduced-resource (thin client) design that links to a hub or gateway device for ultimately connecting to the Internet. The hub/gateway handles the relatively compute-intensive tasks of network security and pre-processing of data as well as all the protocols associated with communicating to the wide area network and application services. The hub/gateway also handles the configuration and management of the individual devices in its local network, based both on instructions from the network and responses to local data.
Front-loaded IoT designs use devices more capable than the thin-client designs of the hub-and-spoke architecture. These devices are capable of handling their own wide area network interfaces and preprocessing of data using more powerful processors and radios. They often communicate to the Internet for reporting and control as individuals, either directly or through a local area network router that is acting simply as a relay point, not a control center.
Smart client designs take things one step further. These are relatively autonomous devices that devices process their own data locally and act upon that data autonomously. They are also able to exchange information and exercise control peer-to-peer within their local network. They use their wide area network connectivity primarily as a means for sending in data for deeper analysis.
Tomi Engdahl says:
Sensor-Based IoT Architecture
http://www.edn.com/design/analog/4439913/Sensor-Based-IoT-Architecture-?_mc=NL_EDN_EDT_EDN_weekly_20150716&cid=NL_EDN_EDT_EDN_weekly_20150716&&elq=3c3e003c887849af93a1728d93fd111f&elqCampaignId=23970&elqaid=27068&elqat=1&elqTrackId=23f5425430c547bcaabb7673d76575cb
Home> Analog Design Center > How To Article
Sensor-Based IoT Architecture
Gwyneth Saldanha, Engineering Operations Manager,Nuvation Engineering -July 13, 2015
inShare73
Save Follow
PRINT
PDF
EMAIL
1 The Birth of the Internet of Things
Before its recent rebranding as “IoT,” the Internet of Things concept began emerging with devices like the now famous Coke machine at Carnegie Mellon University (CMU), which since the 1980s has been self-monitoring its internal stock of soft drinks. It monitors how long each bottle has been cooling in the machine and stores this information on a server for access via faculty and students’ computer terminals before they make the long trek to their beloved fueling station.1
Despite its decades-long heritage, the Carnegie Mellon University Coke machine still stands as an ideal example of the value that IoT technologies can bring to today’s businesses and consumers.
Those responsible for refilling the machine could if they wished, leverage this information to serve a “just in time” supply management process. The business owners could also collect aggregated usage data to better understand customer consumption patterns, forecast sales and predict stocking requirements in any given week, month, or fiscal quarter.
Home> Analog Design Center > How To Article
Sensor-Based IoT Architecture
Gwyneth Saldanha, Engineering Operations Manager,Nuvation Engineering -July 13, 2015
inShare73
Save Follow
PRINT
PDF
EMAIL
1 The Birth of the Internet of Things
Before its recent rebranding as “IoT,” the Internet of Things concept began emerging with devices like the now famous Coke machine at Carnegie Mellon University (CMU), which since the 1980s has been self-monitoring its internal stock of soft drinks. It monitors how long each bottle has been cooling in the machine and stores this information on a server for access via faculty and students’ computer terminals before they make the long trek to their beloved fueling station.1
Despite its decades-long heritage, the Carnegie Mellon University Coke machine still stands as an ideal example of the value that IoT technologies can bring to today’s businesses and consumers. For CMU students and faculty, the decision to take a break from the books to embark on a quest for caffeine and sugar has been informed for nearly three decades by IoT-driven data regarding the current coldness and available supply of soft drinks in the vending machine.
Those responsible for refilling the machine could if they wished, leverage this information to serve a “just in time” supply management process. The business owners could also collect aggregated usage data to better understand customer consumption patterns, forecast sales and predict stocking requirements in any given week, month, or fiscal quarter.
Fast forward to today (that Coke machine at CMU has had a makeover or two since the eighties, but is still transmitting data, and now also reports on M&M’s), and we find modern society operating within an information technology infrastructure that is so ideally architected to support IoT that conspiracy theorists could argue an intelligent design has been driving us towards it. Such theorists would not be far off; for over a decade technology providers have been striving to create devices that operate on shared platforms and can “talk to each other.”
2 A Sensor-Based IoT Communication Architecture
IoT solutions can come in many flavors and any concrete explanation of how a particular business can leverage a collection of Internet-connected devices would require insight into that specific business context.
IoT architectures are usually comprised of a set of sensors that collect different types of data and transmit them to a “base station” that uploads the data to the cloud. From there it can be accessed by consumers and/or businesses as actionable intelligence.
A. BUSINESS IMPACTS
Sensor-based networked communications architectures enable businesses to deploy IoT platforms and monitor the status of their devices or other equipment in order to:
Reduce workforce costs associated with manual monitoring methods.
Improve customer satisfaction and retention by providing highly proactive customer service without increasing costs.
Reduce equipment maintenance costs through early detection of equipment failures and device maintenance issues.
Cost-efficiently extend product life cycles by remotely pushing out software/firmware updates to multiple devices across a wide geographic area.
B. SENSORS AS IOT ENABLERS
Sensor-based IoT platforms can automate the collection and reporting of business-critical information such as inventory and supply shortages, equipment malfunctions, or specific behaviors and actions.
C. THE IOT SYSTEM ARCHITECTURE
A typical sensor-based IoT architecture consists of the following:
LOW-POWER SMART SENSORS (a.k.a. “EDGE DEVICES”) – The smart sensor, or “edge device” (so named because these data collectors sit on the outer edge of the network) collects the granular data required by businesses, individuals, and intelligent systems. Many of today’s sensors can operate on battery power to support wireless installation and communications, with battery life that can last months or even years. They generally achieve this through “smart” power management, i.e. going into ultra-low power states until they sense that a certain condition has occurred.
LOCAL SENSOR NETWORK – There are many options available to connect locally networked sensors to a base station, and low power consumption is usually a key requirement. RF (Radio Frequency) and BluetoothTM Smart are popular alternatives to the more power-hungry Bluetooth® 2.1 and Wi-Fi®. For example, Nuvation developed a low-power wireless connection for previously “dumb” but now made “smart” building infrastructure equipment using TI’s SimpliciTITM network protocol for Sub-1 GHz, 2.4 GHz and IEEE 802.15.4 RF ICs.
THE BASE STATION – The base station is the bridge between the sensor network and the cloud. This device is generally powered via an AC connection and supports more advanced data processing and transmission functions. The base station collects all the data transmitted by the sensors and can also push periodic firmware updates to them. It collects data from the local sensor network, “decides” what information is actionable business intelligence, and uploads that information to the cloud server via an Internet or cellular network connection. The base station can be populated with both Wi-Fi and cellular options as fallback methods of communication.
CLOUD SERVER – Cloud computing allows consumers and businesses to access massive amounts of computing power at extremely low costs by leveraging economies of scale. This eliminates the need to invest in and support expensive server hardware in-house.
The base station can send periodic “heartbeats” to the cloud server to let it know that the sensor network is alive and healthy. The server can also push down commands, configuration and software updates to the base station, and also support application-level system management and analytics software. As the business needs grow or shrink, a business can simply add or reduce their cloud computing resources without concern for equipment costs or hardware obsolescence.
One example of such a scalable data center solution is Amazon Web Services (AWS®).
REMOTE DASHBOARD & CONTROL STATION – This component has been called different things by various IoT proponents, and is essentially the computing platform where data is converted into actionable business intelligence.
CONCLUSION
It is clear that sensor-driven IoT architectures have been here long before the term “the Internet of Things” was a “thing.”
Ctm says:
In the diagram posted the complexity needs to be concentrated on the left or the right as far as possible. See my post on mqtt group.
Tomi Engdahl says:
An IoT platforms match : Microsoft Azure IoT vs Amazon AWS IoT
https://paolopatierno.wordpress.com/2015/10/13/an-iot-platforms-match-microsoft-azure-iot-vs-amazon-aws-iot/
Overview : IoT reference architecture
A complete IoT solution is made of different parts. First of all, we need to ingest all the events and data sent from devices and it’s a such big problem because in the Internet of Things era we have to think at “scale” with hundreds, thousands, million and … billion of devices. In this scenario, we have to use an ingestion system that is able to scale and handle incoming data very quickly without slowing down the entire process : we talk about “telemetry” pattern.
After acquiring data, the ingestion system must provide them to the business engine (aka back end) of our solution that could have a “hot” path for analyzing data as a stream in real time and a “cold” path for storing data and analyzing them for future analysis : we can consider it a “big data” problem. Both paths could expose these information to the end user that can monitor the devices and what they are “saying” from the real world. The same information are very useful as input for a machine learning system that can help us for predictive analysis to understand how data could evolve in the future based on current incoming values and take preventive actions.
In this scenario, we can’t forget the opposite path from our cloud based system to the devices. In most cases we need to interact with them using the “command” and “notification” patterns; with commands we are able to “speak” to the devices so that they can execute some actions on our behalf and with notifications we can provide some information they need during their lifetime.
A brief introduction : IoT Hub vs AWS IoT
IoT Hub is the new entry in the Microsoft Azure offer; it’s a service that enables bi-directional communication between devices and our business engine (aka back end) in the cloud. The communication channel is reliable and secure and the authentication is per-device using credentials and access control.
Thanks to its bi-directional nature, the messages between devices and cloud travel in both directions along the established channel. Each device has two endpoints to interact with IoT Hub :
D2C (device to cloud) : the device uses this endpoint to send messages to the cloud both as telemetry data, outcome for a received command or request for execution;
C2D (cloud to device) : the device receives commands on this endpoint for executing the requested action. The IoT Hub generates a feedback at application level to confirm that the command is acquired by the device and it’s going to be executed
IoT Hub has an identity registry where it stores all information about provisioned devices. This information aren’t related to devices metadata (they are up to you in your IoT solution that uses IoT Hub, for example manufacturer and firmware/software version info) but are related to identity and authentication. It provides monitoring information like connection status (connected/disconnected) and last activity time; you are also able to enable and disable the devices using this registry. Of course, IoT Hub exposes another endpoint (device identity management) to create, retrieve, update and delete devices.
AWS IoT has the same objectives as IoT Hub but reaches them in a different way.
SDKs : languages and platforms supported
Even if we can access to the IoT Hub using open standard protocols (like HTTP and AMQP as we’ll see in the next chapters), Microsoft provides different SDKs for different languages and platforms. Of course, we have .Net SDK for pure .Net Framework applications and UWP (Universal Windows Platform) applications running on Windows 10 devices (included the IoT version, Windows 10 IoT Core); other SDKs are for Java and NodeJS (JavsScript) developers. The great news is related to the availability of an SDK for C (ANSI C99) for portability and broad platform compatibility; it can be used on very low constrained devices with only C language support.
With .Net SDK we also have the service part used in the back end system to handle identity registry and send messages to the device; only for NodeJS applications there is a dedicated codebase.
All SDKs are open source and available on GitHub.
AWS IoT enables devices to access to the cloud using standard protocols (like HTTP and MQTT) but Amazon provides some SDKs to simplify developers life. First of all, an SDK for embedded C language (ANSI C99) that is cross platform and that can be used on different hardware and operating systems (for low constrained devices with RTOS too). The SDK adds an abstraction layer on top of all actions needed for accessing the message broker that are related to the security of the channel, the MQTT based communication for publishing and subscribing messages to topics and finally all the operations related to thing shadows for updating, retrieving and deleting them. A NodeJS SDK is also available for powerful platforms and finally another SDK just only for Arduino Yun board.
Security and Authentication
The connection established between devices and IoT Hub is TLS (Transport Layer Security) based so that the communication is encrypted to guarantee data confidentiality; the server is authenticated thanks to its own X.509 certificate sent to the device during the TLS handshaking.
The device and service authentication is handled with access control and credentials.
The authentication is provided by IoT Hub verifying a token (sent from the device) against the shared access policies and device identity registry security credentials.
AWS IoT relies on TLS protocol so that the communication with the message broker is encrypted and the client is authenticated using the mutual authentication (so with X.509 client certificate too). The certificates can be created, activated and revoked using the AWS CLI or the AWS online console; of course we can also use a certificate that is already in our possession. Once we have the certificate, we need to attach it to a policy and the thing itself.
AWS IoT doesn’t support an identity principals based on X.509 certificates only but it supports IAM service (users, groups and roles) and Amazon Cognito service. As guide lines, the X.509 should be used with MQTT based application, the IAM service with HTTP and Cognito with end user applications (for example on smartphones) thanks to the support for different identity providers (like Facebook, Google and so on).
Protocols : AMQP, MQTT, HTTP and the others
Today, AMQP 1.0 is already the official supported protocol for all Azure services under Service Bus umbrella like queues, topics/subscriptions and event hubs. Microsoft focused on this protocol (as part of the committee for the standard) and decided to adopt it for IoT Hub too. Of course, HTTP protocol is supported too. We could consider AMQP the better choice for majority of scenarios to avoid polling nature of HTTP (from device) due to the lack of server push feature (available with AMQP)
It’s possible to support additional protocols using the Azure IoT Protocol Gateway framework that provides protocol adaptation from a different protocol (MQTT or any other custom protocol) to AMQP with direct access to the IoT Hub.
MQTT (3.1.1), we spoken about, is the official supported protocol for AWS IoT that the message broker uses for publishing and subscribing messages on topics. Even if MQTT is a standard, the broker supports it with some variations : for example it doesn’t support retained messages, persistent sessions and QoS level 2. For more information on this support and main differences, we can find a deep description on official AWS IoT protocols page. The HTTP protocol is supported too even if it’s limited to publish messages using a REST API (POST method only).