The highest beneficial features of this protocol are the outstanding quality of service levels and the reliability with the use of a broker-less architecture, which suits IoT and M2M communication. It offers 23 quality-of-service levels which allow it to offer a variety of quality criteria, including: security, urgency, priority, durability, reliability, etc. It defines two sublayers: data-centric publish-subscribe and data-local reconstruction sublayers. The first takes the responsibility of message delivery to the subscribers while the second is optional and allows a simple integration of DDS in the application layer. Publisher layer is responsible for sensory data distribution. Data writer interacts with the publishers to agree about the data and changes to be sent to the subscribers. Subscribers are the receivers of sensory data to be delivered to the IoT application. Data readers basically read the published data and deliver it to the subscribers and the topics are basically the types of data that are being published. In other words, data writers and data reader take the responsibilities of the broker in the broker-based architectures.
Several IoT session layer standards and protocols have been proposed in the literature and were briefly discussed in this section. These standards are totally application dependent and the choice among them depends on the desired application. MQTT is the most widely used in IoT due to its low overhead and power consumption. The choice among these standards is organizational and application specific. For example, if an application has already been built with XML and can, therefore, accept a bit of overhead in its headers, XMPP might be the best option to choose among session layer protocols. On the other hand, if the application is overhead and power sensitive, then choosing MQTT would be the best option. However, that comes with the additional broker implementation. If the application requires REST functionality as it will be HTTP based, then CoAP would be the best option if not the only one. Table I summarizes comparison points between these different session layer protocols.
Table I: A Comparison of IoT Session Layer Standards
VI. IoT Management Protocols
In this section, we provide an overview of several management protocols used in IoT to provide heterogeneous device management and communication. We start by discussing two protocols to handle data link heterogeneity. Then, we discuss a few remote device management protocols that are used mostly in M2M and IoT applications.
Existing standards mainly facilitate communication between protocols at the same layer and it is still a challenge to facilitate communication at different layers in IoT.
A. IEEE 1905.1 – Interconnection of Heterogeneous Data links
As was shown in Section II, IoT has many different and diverse MAC layer protocols and, hence, interoperability among these standards is critical. This standard, designed in IEEE, would handle such interoperability by providing an abstraction layer that is built on top of all these heterogeneous MAC protocols . This abstraction allows different protocols to communicate by hiding their diversity without requiring any change to their design. The abstraction layer allows the exchange of messages, called control message data units (CMDUs), among all standards compatible devices. As shown in Fig. 8, all IEEE 1905.1 compliant devices understand a common “abstraction layer management entity (ALME)” protocol, which offers different services including: neighbor discovery, topology exchange, topology change notification, measured traffic statistics exchange, flow forwarding rules, and security associations.
Fig. 8: IEEE 1905.1 Protocol Structure
B. Smart Transducer Interface
Each transducer contains a TEDS which includes all the information needed by the measurement system, including device ID, characteristics, and interface. Data sheets are stored in embedded memory within the transducer or the sensor and have a defined encoding mechanism to understand a broad number of sensor types and applications. The memory usage is minimized by utilizing small XML based messages which are understood by different manufactures and different applications .
In this specification, the management is done by HTTP messages sent from server to clients or desired devices. The specification is critical for M2M devices, but since it relies on HTTP message, it is currently not widely used in IoT applications .
It uses XML messages for communication, build over HTTP, and it can be applied to any XML based transport protocol, such as XMPP. However, messages in such protocol are still complex for resource-constrained IoT devices to use .
It is mostly built on CoAP but can be applied to other session protocols. This protocol is used to manage device functions over the network, transfer data from the server to devices and can be extended to many IoT server-client messages .
In this section, we discussed several management protocols for interoperability and heterogeneity of different IoT protocols. IEEE-1905.1 is used for heterogeneity of IoT MAC layer protocols, while IEEE 1451 is used for transducers and sensor management. TR-069, OMA-DM, and LWM2M are used for remote management protocols where LWM2M is more suitable and widely used for IoT. Management between protocols at different layers of IoT communication is still a challenge to be solved.