| Xi Chen, chen857 (at) wustl.edu (A paper written under the guidance of Prof. Raj Jain) |
Download |
In section 1, some wireless protocols in different layers of IoT are introduced. One latest protocol for application layer CoAP is given and its features and functions are summarized. By comparing it with Hypertext Transfer Protocol (HTTP), its advantages are presented. In section 2, some important CoAP models are explained in details, such as the message layer model, request/response layer model and message format. In sections 3, a security protocol Datagram Transport Layer Security (DTLS) for transmission protection is described. It achieves necessary elements for securing CoAP, like integrity, authentication and confidentiality. Then, an application of CoAP Smart Homes is described, it helps users to manage energy control systems, which reduce power consumption and prevent accidents.
CoAP is one of the latest application layer protocol developed by IETF for smart devices to connect to Internet. As many devices exist as components in vehicles and buildings with constrained resources, it leads a lot of variation in power computing, communication bandwidth etc. Thus lightweight protocol CoAP is intended to be used and considered as a replacement of HTTP for being an IoT application layer protocol.
As TCP/IP lay the foundation for the Internet, thus IoT communication network mainly employ TCP and UDP protocols. Compared with UDP protocol, TCP protocol is more complex which makes it not easy to employ on resource-constrained devices. Now, most of IoT use UDP protocol. But UDP is not stable, which needs to combine with application layer to improve the stability.
Application layer usually employ HTTP to provide web service, but HTTP has high computation complexity, low data rate and high energy consumption. Therefore, IETF has developed several lightweight protocols, e.g., CoAP, Embedded Binary HTTP (EBHTTP), Lean Transport Protocol (LTP). The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks [Z.Shelby13]. EBHTTP is a binary-formatted, space-efficient, stateless encoding of the standard HTTP/1.1 protocol [G.Tolle13]. EBHTTP is primarily designed for transportation of small data between resource-constrained nodes, which is similar to CoAP. LTP is a lightweight Web Service transport protocol that allows the transparent exchange of Web Service messages between all kinds of resource constrained devices and server or PC class systems [Glombitza10].Table 1 summarizes protocols in different layers.
CoAP needs to consider optimizing length of datagram and satisfying REST protocol to support URI (Uniform Resource Identifier). It also needs to provide dependable communication based on UDP protocol. Table 2 shows the CoAP features [ Petersburg12]
Unlike HTTP based protocols, CoAP operates over UDP instead of using complex congestion control as in TCP [Koojana11]. CoAP is based on REST architecture, which is a general design for accessing Internet resources. In order to overcome disadvantage in constrained resource, CoAP need to optimize the length of datagram and provide reliable communication. On one side, CoAP provides URI, REST method such as GET, POST, PUT, and DELETE. On the other side, based on lightweight UDP protocol, CoAP allows IP multicast, which satisfies group communication for IoT. To compensate for the unreliability of UDP protocol, CoAP defines a retransmission mechanism and provides resource discovery mechanism with resource description [Shelby11]. Fig 1 shows the HTTP and CoAP protocol stacks.
Fig 1: HTTP and CoAP protocol stacks
CoAP is not just a simply compression of HTTP protocol. Considering low processing capability and low power consuming demand of restrained resource, CoAP redesigned some features of HTTP to accommodate these limitations. HTTP used under unconstrained network and CoAP used under constrained network. Recently, HTTP-CoAP cross protocol proxy arouses scientific interest, it has and important role in solving congestion problem in the constrained environment [Castellani12].
Fig. 2: Abstract Layer of CoAP [Z.Shelby13]
a) Reliable message transport: Keep retransmission until get ACK with the same message ID (like 0x8c56 in fig. 3). Using default time out and decreasing counting time exponentially when transmitting CON. If recipient fail to process message, it responses by replacing ACK with RST. Fig. 3 shows a reliable message transport.
Fig. 3: Reliable Message Transport
b) Unreliable message transport: transporting with NON type message. It doesn't need to be ACKed, but has to contain message ID for supervising in case of retransmission. If recipient fail to process message, server replies RST. Fig. 4 shows unreliable message transport.
Fig. 4: Unreliable Message Transport
a) Piggy-backed: Client sends request using CON type or NON type message and receives response ACK with confirmable message immediately. In fig. 5, for successful response, ACK contain response message (identify by using token), for failure response, ACK contain failure response code.
Fig. 5: The successful and failure response results of GET method
b) Separate response: If server receive a CON type message but not able to response this request immediately, it will send an empty ACK in case of client resend this message. When server ready to response this request, it will send a new CON to client and client reply a confirmable message with acknowledgment. ACK is just to confirm CON message, no matter CON message carry request or response (fig. 6).
Fig. 6: A Get request with a separate response
c) Non confirmable request and response: unlike Piggy-backed response carry confirmable message, in Non confirmable request client send NON type message indicate that Server don't need to confirm. Server will resend a NON type message with response (fig. 7).
Fig. 7: Non confirmable request and response
Option number=option delta+ ex option number. The format is shown in Fig. 8
Fig. 8: CoAP option format
There are three main elements when considering security, namely integrity, authentication and confidentiality. DTLS can achieve all of them [Kothmayr 12]. IETF modifies DTLS to develop another protocol DTLS. DTLS employ TCP, which is too complex. DTLS solves two problems: reordering and packet lost. It adds three implements: 1 packet retransmission. 2 assigning sequence number within the handshake. 3 replay detection.
Unlike network layer security protocols, DTLS in application layer (fig.9) protect end-to-end communication. No end-to-end communication protection will make it easy for attacker to access to all text data that passes through a compromised node. DTLS also avoids cryptographic overhead problems that occur in lower layer security protocols.
Unlike network layer security protocols, DTLS in application layer (fig. 9) protect end-to-end communication. No end-to-end communication protection will make it easy for attacker to access to all text data that passes through a compromised node. DTLS also avoids cryptographic overhead problems that occur in lower layer security protocols.
Fig. 9: DTLS in protocol stack
Record protocol [E.Rescorla12]protects application data by using keys generated during Handshake. For outgoing message, protocol divide, compress, encrypt and apply Message Authentication Code (MAC) to them. For incoming message, protocol reassemble, decompress, decrypt and verify them. Record header consists of two parts, one is content type and another is fragment field. Content type decides what is contained in fragment field. It could be alert protocol, Handshake protocol or application data. Compare with DTLS Record, Handshake protocol is rather a complex one, which involves in a lot of exchange steps. Individual messages are grouped into message flights. Fig. 10 shows the process of Handshake.
Fig. 10: Process of Handshake
The Architecture show below (Fig. 11) is for uni-cast communication (client interacts with one or more servers). The client also needs to know which certificate or raw public key it has to use with a specific server [Hartke13].
Fig. 11: Uni-cast communication model
Smart home network provide controlling and monitoring energy of home devices. Energy control systems employ smart socket management and monitor power consuming equipment to provide voltage, current and other energy information. It could realize accident warning, remote control and dynamic energy saving. The system structure is shown in Fig. 12. Every data collection node with CoAP client could exchange information with other nodes. CoAP could both be installed in LAN or Internet. Unlike Many wireless protocols for home automotive devices, CoAP is designed not constrained in a local network but provide the fundamental basis of the web [Bergmann12]. In this system, CoAP-HTTP proxies are employed to provide HTTP client connection to CoAP resources and vice versa.
Fig. 12: energy control system
In system networking, date collection nodes consist of one proxy, smart socket and wireless data collection module. Energy information and environment information of equipment is collected by the smart socket and transported to data collection module through wireless channel, then send serial data to proxy to process and pack data. Control server analyzes all the data and stores them in database. The system integrate home network and Internet, users can access system webpage to remotely control switch, manage configuration, query energy consumption, etc. At the same timei1/4OEthis system will monitor environment situation. If any abnormal things happens, (like high temperature or voltage beyond the safety range) the system will analyze it and close relevant equipment.
This report summarizes some wireless protocols for IoT and introduces CoAP protocol in details with describing main features and modules. CoAP is based on HTTP protocol and is designed for constrained resource devices. Through comparing CoAP and HTTP together, the advantages of CoAP for IoT are analyzed. This report also provides a corresponding security protocol DTLS and one possible application of CoAP for IoT. As a number of protocols are being perfected, more and more smart homes will employ these wireless protocols for intelligent control.
| IoT | Internet of Things |
| IEFT | Internet Engineering Task Force |
| CoAP | Constrained Application Protocol |
| HTTP | Hypertext Transfer Protocol |
| HART | Highway Addressable Remote Transducer |
| LR-WPAN | Low-Rate Wireless Personal Area Network |
| EBHTTP | Embedded Binary HTTP |
| LTP | Lean Transport Protocol |
| CoRE | Constrained RESTful Environments |
| REST | Representation State Transfer |
| URI | Uniform Resource Identifier |
| P2P | Point to Point |
| DTLS | Datagram Transport Layer Security |