Internet of Things: The Protocols Landscape
The Internet of Things (IoT) extends from a single constrained device to a whole range of cloud systems, all connected by a set of protocols that allow devices and servers to talk to one another. Let’s take a look at a few IoT protocols.
The next era of computing is the Internet of Things (IoT), also known as the Internet of Objects. IoT refers to the networked interconnection of everyday objects, which are equipped with ubiquitous intelligence. A recent report by McKinsey Global Institute reported that the number of connected machines has increased by 300 per cent over the past few years. By 2025, the economic impact of IoT is estimated to range from US$ 2.7 trillion to US$ 6.2 trillion. Wikibon predicts that the value created from the Internet will be about US$ 1279 billion in 2020, growing annually at a rate of 14 per cent.
The International Telecommunication Union (ITU) has defined the Internet of Things as, “A global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies.”
The scope of the Internet of Things is increasing in diverse ways, as IoT based solutions are extending to virtually all areas of everyday life, from smart homes to smart industrial production. And the evolution of Industry 4.0 has begun.
The term ‘Internet of Things’ consists of two words - Internet and things. The term ‘Things’ refers to various IoT devices with unique identities, which have the capabilities to perform remote sensing, actuating and live monitoring of certain sorts of data. IoT devices are also enabled for the live exchange of data with other connected devices and applications, either directly or indirectly, or collecting data from other devices, processing it and sending it to various servers. The other term,‘Internet’, is defined as a global communication network connecting trillions of computers across the planet, enabling the sharing of information.
IoT architecture
As the IoT is capable of connecting billions of heterogeneous objects via the Internet, there is an emerging requirement for a dynamic layered architecture. Figure 1 represents a standard IoT layered architecture.
Objects layer: The first layer (perception layer) represents physical sensors of IoT to sense, collect and process the information.
Object abstraction layer: This transfers the data acquired by the object layer to the service management layer via secure channels. Data can be transferred via different technologies like
3G, 4G, GSM, UMTS, Wi-Fi, Bluetooth, ZigBee, etc.
Service management layer: This layer enables IoT application programmers to work with heterogeneous objects, irrespective of the hardware platform.
Application layer: This enables high-quality smart services to fetch what the customers need, as per their requirements. It covers smart homes, smart production units, transportation, smart health care based biosensor equipment, etc.
Business layer: This layer manages the overall IoT system’s activities and services. It is responsible for building the business model, graphs and flowcharts on the basis of data acquired at the application layer.
IoT protocols
IEEE (Institute of Electrical and Electronics Engineers) and ETSI (European Telecommunications Standards Institute) have defined some of the most important protocols for IoT. These are listed below.
CoAP (Constrained Application Protocol): This was created by the IETF Constrained RESTful Environments (CoRE) working group. CoAP is an Internet application protocol for constrained devices. It is designed to be used between devices on the same constrained network, between devices and general nodes on the Internet, and between devices on different constrained networks—both joined on the Internet. This protocol is especially designed for IoT systems based on HTTP protocols. CoAP makes use of the UDP protocol for lightweight implementation. It also makes use of RESTful architecture, which is very similar to the HTTP protocol. It is used within mobiles and social network based applications and eliminates ambiguity by using the HTTP get, post, put and delete methods. Apart from communicating IoT data, CoAP has been developed along with DTLS for the secure exchange of messages. It uses DTLS for the secure transfer of data in the transport layer.
MQTT Protocol: MQTT (Message Queue Telemetry Transport), a messaging protocol, was developed by Andy Stanford-Clark of IBM and Arlen Nipper of Arcom in 1999. It is mostly used for remote monitoring in IoT. Its primary task is to acquire data from many devices and transport it to the IT infrastructure. MQTT connects devices and networks with applications and middleware. A hub-and-spoke architecture is natural for MQTT. All the devices connect to data concentrator servers like IBM’s new MessageSight appliance. MQTT protocols work on top of TCP to provide simple and reliable streams of data.
MQTT Protocol consists of three main components: subscriber, publisher and broker. The publisher generates the data and transmits the information to subscribers through the broker. The broker ensures security by cross-checking the authorisation of publishers and subscribers.
MQTT Protocol is the preferred option for IoT based devices, and is able to provide efficient information-routing functions to small, cheap, low-memory and power-consuming devices in vulnerable and low bandwidth based networks.
XMPP (Extensible Messaging and Presence Protocol): This is a communication IoT protocol for message-oriented middleware based on the XML language. It enables the realtime exchange of structured yet extensible data between any two or more network entities. The protocol was developed by the Jabber open source community in 1999, basically for realtime messaging, presence information, and the maintenance of contact lists. XMPP enables messaging applications to attain authentication, access control, hop-by-hop and endto-end encryption. Being a secure protocol, it sits on top of core IoT protocols and connects the client to the server via a stream of XML stanzas. The XML stanza has three main components: message, presence and IQ.
AMQP (Advanced Message Queuing Protocol):
This was developed by John O’Hara at JPMorgan Chase in London. AMQP is an application layer protocol for messageoriented middleware environments. It supports reliable communication via message delivery assurance primitives
like at-most once, atleast once and exactly once delivery. The AMQP protocol consists of a set of components that route and store messages within a broker service, with a set of rules for wiring the components together. The AMQP protocol enables client applications to talk to the broker and interact with the AMQP model. This model has the following three components, which are connected into processing chains in the server to create the desired functionality.
Exchange: Receives messages from publisher based applications and routes them to ‘message queues’. Message queue: Stores messages until they can be safely processed by the consuming client application.
Binding: States the relationship between the message queue and the exchange.
Data Distribution Service (DDS): This IoT protocol for real-time machine-to-machine communication was developed by the Object Management Group (OMG). It enables scalable, real-time, dependable, high-performance and interoperable data exchange via the publish-subscribe methodology. As compared to MQTT and CoAP IoT protocols, DDS makes use of brokerless architecture and of multicasting to bring high quality QoS to applications. DDS can be deployed in platforms ranging from low-footprint devices to the cloud, and supports efficient bandwidth usage as well as the agile orchestration of system components.
The DDS protocol has two main layers: Data Centric Publish-Subscribe (DCPS) and Data-Local Reconstruction Layer (DLRL). DCPS performs the task of delivering the information to subscribers, and the DLRL layer provides an interface to DCPS functionalities, enabling the sharing of distributed data among IoT enabled objects.
STOMP (Simple Text Oriented Messaging Protocol): This text based protocol was developed to work with message-oriented middleware. It provides an interoperable wire format that enables STOMP clients to communicate with any STOMP message broker to enable easy and widespread messaging interoperability among many languages, platforms and brokers. Like AMQP, STOMP provides the message header with properties and a frame body.
STOMP does not, however, deal in queues and topics—it uses a SEND semantic with a ‘destination’ string. The broker must map it onto something that it understands internally, such as a topic, queue, or exchange. Consumers then SUBSCRIBE to those destinations. Since those destinations are not mandated in the specifications, different brokers may support different flavours of the destination. So, it’s not always straightforward to port code between brokers.
However, STOMP is simple and lightweight (although somewhat verbose on the wire), with a wide range of language bindings. It also provides some transactional semantics. One of the most interesting examples is with RabbitMQ Web Stomp, which allows you to expose messaging in a browser through Websockets.
VSCP (Very Simple Control Protocol): This is more a framework than a protocol. VSCP is highly scalable, has a low footprint and is a free-cum-open source solution for device discovery and identification, device configuration, autonomous device functionality and secure firmware updates. VSCP makes things interact at the application layer. It makes use of CAN, RS-232, Ethernet, TCP/IP, MQTT and 6LowPan.
VSCP uses an event format and supports global unique identifiers for nodes, thus making a node identifiable no matter where it is installed in the world. Besides, it includes a register model in order to provide a flexible common interface for node configuration and a model for controlling the functionality of each node. VSCP does not make any assumptions regarding the lower level system used to realise the physical interconnection with the node; therefore, it works with different transport mechanisms such as Ethernet, TCP/IP, wireless, Zigbee, Bluetooth, CAN, GPRS, RS-232 and USB.
VSCP is event-based. Every time an event occurs, it is broadcast to all other nodes on the network. From there on, each node decides on its own if the event received needs to be processed or not. The final decision depends on the node’s decision matrix, which is made up of a number of
‘if condition> then action> lines’, where the condition> is evaluated based on the fields present in the VSCP datagram broadcast to the network.
References
[1] http://coap.technology/ [2] http://mqtt.org/ [3] https://xmpp.org/ [4] https://www.amqp.org/ [5] http://portals.omg.org/dds/ [6] https://stomp.github.io/ [7] http://www.vscp.org/