Home > IoT > A Survey of Protocols and Standards for Internet of Things

A Survey of Protocols and Standards for Internet of Things

D. IPv6 over G.9959

This standard, defined in IETF RFC 7428, specifies the frame format for transmitting IPv6 packets on G.9959 data links, discussed in Subsection II-I above. In G.9959, a unique 32-bit home network identifier is assigned by the controller and 8-bit host identifier that is allocated for each node.

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 [30].

E. IPv6 over Bluetooth Low Energy

RFC 7668 [31] specifies the format of IPv6 over Bluetooth low energy, which was discussed in Subsection II-E. It reuses most of the 6LowPAN compression techniques. Fragmentation is done at the logical link control and adaptation protocol (L2CAP) sublayer in Bluetooth.

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.

F. Summary

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.

A. MQTT

Message queue telemetry transport (MQTT) is a 2013 standard from the Organization for the Advancement of Structured Information Standards (OASIS). It was introduced back in 1999 by IBM [32], [4]. It provides the connectivity between applications and users at one end, network and communications at the other end.

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

B. SMQTT

An extension of MQTT, secure MQTT (SMQTT), was proposed in [33] to provide a lightweight attribute based encryption. Such encryption uses a multicast feature, in which one message is encrypted and delivered to multiple other nodes, which is quite common in IoT applications.

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.

C. AMQP

Advanced message queuing protocol (AMQP) is another OASIS standard that was designed for the financial industry, runs over TCP, and uses publish/subscribe architecture, similar to MQTT.

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 [34].

Fig. 6: AMQP Architecture

D. CoAP

Another session layer protocol designed in the IETF constrained RESTful environment (Core) working group is constrained application protocol (CoAP), which is designed to provide low overhead RESTful (HTTP) interface.

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 [35], [4].

Fig. 7: CoAP Messages

E. XMPP

Extensible messaging and presence protocol (XMPP) is a protocol that was originally designed for chats and messages exchange applications. It is based on XML language and was standardized by IETF more than a decade ago.

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 [36], [4].

Pages ( 6 of 10 ): « Previous1 ... 45 6 78 ... 10Next »

Leave a Comment:

Your email address will not be published. Required fields are marked *