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 last few years. By 2025, economic impact of the IoT is estimated to range from $2.7 trillion to $6.2 trillion. Wikibon predicts that the value created from the Internet will be about $1279 billion in 2020, growing annually at a rate of 14 per cent.
The International Telecommunication Union (ITU) defines the IoT 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 IoT 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.
Fig. 1: IoT layered architecture
The term ‘Internet of Things’ consists of two words: Internet and things. The latter refers to various IoT devices with unique identities, which are capable of remote sensing, actuating and live monitoring of certain kind of data. IoT devices are also enabled for 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 information sharing.
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. Fig. 1 represents a standard IoT layered architecture.
Objects layer
The first layer (perception layer) represents physical sensors of the IoT, which sense, collect and process information.
Object abstraction layer
This layer transfers the data acquired by the object layer to the service management layer via secure channels. Data can be transferred using different technologies like 3G, 4G, GSM, UMTS, Wi-Fi, Bluetooth and ZigBee.
Service management layer
This layer enables IoT application programmers to work with heterogeneous objects, irrespective of the hardware platform.
Application layer
This layer enables high-quality smart services to fetch what the customers need. It covers smart homes, smart production units, transportation, smart healthcare-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
Institute of Electrical and Electronics Engineers (IEEE) and European Telecommunications Standards Institute (ETSI) have defined some of the most important protocols for the IoT. These are listed below.
Constrained Application Protocol (CoAP)
Created by the IETF Constrained RESTful Environments (CoRE) working group, CoAP is an Internet application protocol for constrained devices. It is designed for use 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 allows secure exchange of messages by using datagram transport layer security (DTLS) protocol.
Fig. 2: How CoAP works
MQTT protocol
Message queue telemetry transport (MQTT), 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 the 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 data streams.
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 networks.
Fig. 3: MQTT protocol architecture
Extensible Messaging and Presence Protocol (XMPP).
It is a communication IoT protocol for message-oriented middleware based on XML language. It enables real-time 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 real-time messaging, presence information and maintenance of contact lists. XMPP enables messaging applications to attain authentication, access control, and hop-by-hop and end-to-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.
Fig. 4: XMPP architecture
Advanced Message Queuing Protocol (AMQP).
Developed by John O’Hara at JPMorgan Chase in London, AMQP is an application-layer protocol for message-oriented 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. It enables client applications to talk to the broker and interact with the AMQP model. This model has the following three components:
1. Exchange. Receives messages from publisher-based applications and routes them to‘message queues’
2. Message queue. Stores messages until these can be safely processed by the consuming client application
3. Binding. States the relationship between the message queue and the exchange
These components are connected into processing chains in the server to create the desired functionality.
Fig. 5: AMQP architecture
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 publish-subscribe methodology. Compared to MQTT and CoAP IoT protocols, DDS makes use of brokerless architecture and 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 agile orchestration of system components.
DDS protocol has two main layers: data-centric publish-subscribe (DCPS) and data-local reconstruction layer (DLRL). DCPS delivers the information to subscribers, and DLRL provides an interface to DCPS functionalities, enabling sharing of distributed data among IoT-enabled objects.
Fig. 6: DDS protocol architecture
Simple Text Oriented Messaging Protocol (STOMP)
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 message header with properties and a frame body.
However, STOMP does not 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 RabbitMQ Web STOMP, which allows you to expose messaging in a browser through Websockets.
Fig. 7: STOMP architecture
Very Simple Control Protocol (VSCP)
VSCP is more a framework than a protocol. It 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, secure firmware updates and connection of devices from sensor to smart user interface. 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.
Fig. 8: VSCP operations
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.
This is a reprint of the article published in June issue of Open Source For You magazine.
