D. IPv6 over G.9959
Hence, an IPv6 link local address must be constructed by the link layer derived 8-bit host identifier so that it can be compressed in G.9959 frame. Furthermore, the same header compression as in 6lowPAN is used here to fit an IPv6 packet into G.9959 frames. It should be noted that RFC 7428 has a security feature by allowing a shared network key that is used for encryption. However, this is not enough for security critical applications which need to have end-to-end encryption and authentication and that is mostly handled by other protocols and higher layer security mechanisms .
E. IPv6 over Bluetooth Low Energy
Thus, the fragmentation feature of 6LowPAN is not used here. Further, Bluetooth low energy does not currently support formation of multi-hop networks at the link layer. Instead, a central node acts as a router between lower-powered peripheral nodes. Thus, multi-hop feature in 6LowPAN is not used as well.
This section discussed encapsulating long IPv6 datagrams into small MAC frames for IoT. First, 6LowPAN and 6TiSCH for IPv6 over 802.15.4 and 802.15.4e were discussed. Such protocols are important as 802.15.4e is the most widely used encapsulation framework designed for IoT. Following that, 6Lo specifications are briefly and broadly discussed just to present their existence in IETF standards. These drafts handle transmitting IPv6 datagrams over different channel access mechanisms using 6LoWPAN standards. Then, two of 6Lo specifications, which have become IETF RFCs, are discussed in more detail. The importance of presenting these standards is to highlight the challenge of interoperability between different networking stack layers which is still challenging due to the diversity of data link protocols.
V. Session Layer Protocols
In this section, we review several IoT session layer protocols that are used for message passing and that have been standardized by different standardization organizations. At the transport layer, TCP and UDP are the dominant protocols for most of the applications, including IoT. However, several message distribution functions are required depending on IoT application requirements. It is desirable that these functions be implemented in interoperable standard ways. These are the so called ”Session Layer” protocols which are described in this section.
It is a publish/subscribe architecture, as shown in Fig. 5, where the system consists of three main components: publishers, subscribers, and a broker. In IoT, publishers are the lightweight sensors that connect to the broker to send their data and go back to sleep whenever possible. Subscribers are applications that are interested in a certain topic, or sensory data, so they connect to brokers to be informed whenever new data are received. The brokers classify sensory data in topics and send them to subscribers interested in those topics only.
Fig. 5: MQTT Architecture
Generally, the algorithm consists of four main stages: setup, encryption, publish and decryption. In the setup phase, the subscribers and publishers register themselves to the broker and get a master secret key according to their developer’s choice of key generation algorithm. Then, when the data is published, it is encrypted and published by the broker which sends it to the subscribers. Finally, it is decrypted at the subscribers which have the same master secret key. The key generation and encryption algorithms are not standardized.
The main difference in these standards is that the broker is divided into two main components: exchange and queues, as shown in Fig. 6. The exchange component is responsible for receiving publisher messages and distributing them to queues following pre-determined roles. Subscribers connect to those queues, which basically represent the topics, and get the sensory data whenever they are available .
Fig. 6: AMQP Architecture
Representational state transfer (REST) is the standard interface which is extensively used in today’s web applications. However, REST has a significant overhead and power consumption which made it unsuitable for IoT platforms. CoAP is designed to solve the REST problems and enable IoT applications to use RESTful services while meeting their requirements. It is built over UDP, instead of TCP, and has a lightweight mechanism to provide reliability. CoAP architecture is divided into two main sublayers: messaging and request/response. The messaging sublayer is responsible for the reliability and duplication of messages while the request/ response sublayer is responsible for communication.
As shown in Fig. 7, CoAP can have four messaging types: confirmable, non-confirmable, piggyback, and separate. Confirmable and non-confirmable represent the reliable and unreliable transmissions, respectively while the other modes are used for request/response. Piggyback is used for client/server direct communication, where the server sends its response directly after receiving the message, i.e., within the acknowledgment message. On the other hand, the separate mode is used when the server response comes with a message separate from the acknowledgment, and may take some time to be sent by the server. As in HTTP, CoAP utilizes get, put, push, delete message requests to retrieve, create, update, and delete, respectively , .
Fig. 7: CoAP Messages
It is quite popular and is highly efficient when used over the internet. Recently, its usage was extended for IoT and SDN applications due to the standardized use of XML which makes it easily extensible. XMPP supports both publish/subscribe and request/ response architecture and it is up to the application developer to choose which architecture to use. It is designed for near real-time applications and, thus, efficiently supports low-latency small messages. It does not provide any quality of service guarantees and, hence, is not practical for M2M communications. Moreover, XML messages create additional overhead due to lots of headers and tag formats which increase the power consumption that is critical for IoT application. Hence, XMPP is rarely used in IoT but there is some interest in enhancing its architecture to support IoT applications , .