Performance evaluation of lightweight and secure protocol for wireless sensor networks: A protocol to enable Web services in IPv6 over low-power wireless personal area networks

Abstract

The integration of wireless sensor networks within the Internet has been possible with the use of the IPv6 over low-power wireless personal area network standard at lower layers and Web services at higher layers. The operating constraints of wireless sensor networks and the implementation of traditional Internet protocols in these networks require an efficient adaptation of specialized low-power application protocols. Under this scope, this article presents the design, implementation, and evaluation of a secure, lightweight, and energy-efficient application protocol based on binary encoding and a RESTful approach to enable Web services in wireless sensor networks. The lightweight and secure protocol for wireless sensor network protocol has been designed to work over transmission control protocol, and it is recommended for applications where strong reliability constraints are imposed or in the configuration, reprogramming, or management of sensor nodes. Results show that lightweight and secure protocol for wireless sensor network is energy efficient regardless the use of legacy transmission control protocol as transport protocol, which brings the possibility of interoperability with existing systems, Internet protocols, and network infrastructure. We believe that lightweight and secure protocol for wireless sensor network will allow the expansion of the Internet of Things at a global scale.

Keywords

Wireless sensor networks Web services Internet of Things Web of Things IPv6 over low-power wireless personal area networks RESTful protocols constrained application protocol embedded Web services end to end energy consumption service response time

Introduction

Wireless sensor networks (WSN) have become an integral part of ubiquitous computing, which provides the possibility of access to any service from anywhere, at any time, and from any device. In the past, the integration of WSN within the Internet and into the Web had been possible through gateways. The role of a gateway is to convert Internet protocols (IPs) into the specific protocols that are inside the sensor network and vice versa.¹ To date, the IPv6 over low-power wireless personal area networks (6LoWPAN) standard proposed by the Internet Engineering Task Force (IETF) is recommended to fulfill the integration of WSNs within the Internet.²

The 6LoWPAN standard introduces an adaptation layer between the IP stack’s data link and network layers that enables efficient transmission over 802.15.4 links of IPv6 datagrams, eliminating the need of specialized gateways.³ 6LoWPAN led to a new paradigm known as Internet of Things (IoT), where smart objects connected to the Internet bring physical world data into the world of digital content and services.⁴ Although seamless integration with IP, system scalability, and interoperability are the key objectives for IoT setups, the integration at higher layers requires the adaptation of traditional IPs to embrace millions of heterogeneous-embedded devices designed and developed to satisfy particular needs. Both heterogeneity and lack of integration require the use of a universal “language” to enable a seamless and scalable interworking and integration of such diverse technologies. Because of their interoperability and multipurpose features, Web services known as the Web of Things (WoT) have been proposed to prove that Web-based systems can smoothly bridge information, objects, and services at higher layers.⁵

Despite its usability, Web services are only available for traditional platforms with standard computational power and are difficult to implement in devices with limited resources such as sensor nodes. The traditional Web service protocols such as hypertext transfer protocol (HTTP) and simple object access protocol (SOAP) neither address the requirements of limited resources and limited powered devices like sensor nodes nor meet the number of requirements to be used directly over 6LoWPAN. An important concern is the header and payload compression of these protocols since 802.15.4 networks using the 6LoWPAN standard have a small payload size available. Likewise, the use of fragmentation, host mobility, lossy asymmetrical links, and security issues are also present. Hence, these aspects should be considered when designing an application protocol for these networks.⁶

Web services can be classified into SOAP-based and RESTful-based services. RESTful Web services are simpler and more flexible than SOAP-based Web services. The perceived simplicity of representational state transfer (REST) eliminates the need for making a series of further architectural decisions that lead to consider REST the most suitable choice for WSNs.⁷ In addition, REST can use any format for data transactions between client and server (with a previous agreement). Although extensible markup language (XML)-based formats are frequently used, they represent only one of the great array of available options. The drawbacks of XML-based formats are their size and their verbose format that make it not suitable for WSNs; so that to solve this problem, the efficient XML interchange (EXI) format has emerged.⁸

Currently, there are two approaches for the use of Web services in 6LoWPAN: (1) the use of end-to-end compression of Web services and (2) the use of compression through a proxy. In both approaches, the Web services format and protocols are compressed to a suitable size for their use over 6LoWPAN.⁶ Under this scope, the design, implementation, and evaluation of a new lightweight and secure protocol for the use of Web services named lightweight and secure protocol for wireless sensor networks (LSPWSN) is presented. The three-stage project has been based on REST architecture and is the continuation and an extension of a published previous work.⁹ The project has been designed to work over the transmission control protocol (TCP) and the 6LoWPAN standard, as an alternative for applications and tasks where strong reliability constraints are imposed or in the configuration, reprogramming, or managements of sensor nodes. LSPWSN represents a viable alternative to applications that require reliability with existing application protocols and in applications where delivering data is more important than achieving a high throughput.

LSPWSN does not need a specialized gateway for compressing and translating IPs. Likewise, it provides interoperability, seamless integration with IP, end-to-end reliable service at transport level, and system scalability through the support of binary encoding of headers and payload as compression format on both application end points. Unlike other proposed solutions discussed in the “Related work” section, this protocol uses the SNOW lightweight stream cipher in its second version to provide information confidentiality, and it provides better performance in sensor devices in terms of memory and energy consumption.

To summarize, this study proposes and evaluates via a quantitative analysis, the LSPWSN protocol to enable Web services in WSNs, using the TCP protocol as transport layer. Evaluation performance was carried out based on four important quantitative metrics—memory footprint, transferred bytes per client-server transaction, service response time, and energy consumption—and also a qualitative metric which analyzes the level of importance and interoperability within IoT supported by these protocols. To obtain a quantitative analysis, we compare LSPWSN with constrained application protocol (CoAP) proposed by the IETF, which has been designed to work over the user datagram protocol (UDP) as transport protocol.

Thus, the presentation of this proposal has been organized as follows. First, the “Related work” section presents a brief overview of the related works in the integration of sensor networks within the Web. Second, the “LSPWSN protocol overview” section depicts a detailed description of the proposed LSPWSN protocol and its operation and communication architecture. Then, the testbed and evaluation performance are described in the “LSPWSN performance evaluation” section. Finally, summarized conclusions and future work directions are provided in the section “Conclusion and future work.”

Related work

This section presents prior work on the integration of sensor networks with the Internet and the Web, which has been widely researched in last few years. Previous works^10–13 focused on highly specialized protocols which require the use of specialized gateways on the boundary of the sensor network to translate messages from the Internet to the WSN and vice versa. Within this approach, the gateway breaks the encapsulation of IP when processing the remote client request and responding to it on behalf of the sensor node inside the WSN, breaking the end-to-end paradigm of Internet, and consequently ending with the Web service in the border of the sensor network. These protocols were useful and efficient as a temporal solution for this integration; nevertheless, the development of new applications based on these protocols was burdensome and an extremely time-consuming process that implies modifications to specialized protocols used inside the sensor network.

Web services can be classified into SOAP-based^11–13 and RESTful-based services.¹⁰ The flexibility and lightweight nature of RESTful approach makes it the best candidate for WoT. TinyREST¹⁰ is based on the REST architectural style and uses a specialized gateway to achieve the integration of sensor networks into the Internet. This is carried out through the translation of HTTP requests to TinyOS messages which are used inside the sensor network. This work does not provide any reliability mechanism to confirm the reception of messages because it uses UDP as transport protocol. Buckl et al.¹¹ proposed a service gateway which acts as an intermediary mechanism between the Web service and the embedded devices. This gateway performs translation of messages from the IP protocol to Zigbee’s messages in lower layers and in higher layers and SOAP protocol to a specific application protocol used inside the sensor network. Web services description language (WSDL) is used as the language for the specification of the available services. Gopinath et al.¹² proposed an architecture for Web services using SOAP and WSDL for the communication outside the sensor network. There is a constant monitoring of sensor measurements to the server. These measurements are stored in a database in the server and consulted when a remote client from the Internet requests a specific measurement. This is inefficient and energy consuming due to the constraint characteristics of these sensor networks. Sleman and Moeller¹³ depict an architecture based on a gateway that interconnects the Internet with the 6LoWPAN. This gateway implements a device profile for Web services (DPWS) server assuming that a Web service is presented at device level. The use of XML and WSDL in the sensor nodes requires fragmentation of the packages inside the sensor network. Since sensor nodes have limited resources due to their constrained computational power and limited energy source, these formats are too extensive and, therefore, hard to be analyzed.

However, with the development of the 6LoWPAN standard, current works focus on the possibility of integrating existing Web services developed for the well-known IP networks with WSNs. To fulfill the requirements of WSNs, the end-to-end and proxy approaches have been proposed. Within the end-to-end approach, the compressed format is supported by both application end points, and a proxy performs transparent compression so that the end point can use standard Web services.^14–16 These projects try to extend the Web service into the sensor network through the compression of IPs like HTTP, XML, and SOAP. Frank¹⁴ proposes a protocol named CHOPAN (compressed hypertext transfer protocol over personal area networks), where the compression of HTTP is carried out through an interception proxy cache that translates data from HTTP/TCP to CHOPAN/UDP. As in the first approach studied, this proposal breaks the encapsulation of the IP stack because the resource being requested is stored in the proxy cache, the proxy cache responds on behalf of the sensor node. Likewise, a new protocol called CoAP that is a HTTP-like protocol has been recently defined and standardized in the constrained RESTful environments (CoRE) group of the IETF.¹⁵ This protocol was designed to use UDP as transport protocol and uses a proxy for the translation of CoAP to HTTP and vice versa when necessary. This work implements reliability at application layer and proposes the use of datagram transport layer security (DTLS) for the security of the information transmitted with CoAP, which are complex and difficult to analyze by sensor nodes with limited resources. DTLS was not designed for resource-constrained devices; it uses six flight messages to perform the DTLS handshake, which increases the amount of transferred bytes, incrementing the energy consumption. The reduction of computation load to perform data encryption every time is necessary in these constrained environments. Moreover, when a request could otherwise not be made with CoAP, a proxy must perform the needed requests on their behalf, but this implies a protocol translation in both the transport and the application layers that adds complexity to the border router. In addition, applications must deal with reliability at application layer. Finally, embedded binary hypertext transfer protocol (EBHTTP) presented in Tolle¹⁶ includes a few more methods for subscriptions and notifications. They all share the same principles and disadvantages.

LSPWSN protocol overview

This section provides an overview of the LSPWSN protocol. This protocol has been designed to be secure, lightweight, and energy efficient. LSPWSN follows a RESTful approach and uses binary encoding of headers and payload. It can be classified into four protocol categories: point-to-point, end-to-end, stateless, and secure. First, a point-to-point protocol because it has a sender (remote client) and a receiver (embedded Web server) using REST as architectural style. Second, as an end-to-end protocol because connectivity is achieved by having the encoding and decoding of LSPWSN requests/responses at both application end points without an intermediate proxy or any extra processing infrastructure between clients and servers. Third, as stateless protocol in which all parameters for each message request are included into the message itself, without establishing a session for every request between the remote client in the Internet and the embedded Web server inside the 6LoWPAN network. Fourth, as secure protocol because it faces security issues using a lightweight stream cipher. In terms of performance and complexity, the use of a lightweight stream cipher is more efficient than DTLS or Internet protocol security (IPsec). To the best of our knowledge, IPSec cannot be applied directly in WSN because it does not provide data aggregation or allow in-network processing (technique employed in sensor database systems whereby the data recorded is processed by the sensor nodes themselves). Likewise, native IPSec support is only available in Linux 2.6.x kernels.¹⁷ Additionally, since the packet overhead for transmitting data is in the order of 50–80 bytes which is significant at the 6LoWPAN frame maximum transmission units, the bandwidth overhead can also be a problem in low bandwidth networks, especially when small packets are frequently sent. This makes the overhead a significant part of the total data sent. Because of this, the LSPWSN protocol proposes the use of a lightweight stream cipher called SNOW in its second version.

Unlike the works previously discussed in the “Related work” section, the use of TCP as transport layer is proposed because in many IoT applications reliability in data delivery is more important than achieving a high throughput. Moreover, the benefits of the use of TCP in WSNs are built-in reliability, reduction of the application complexity, control of the maximum size of its packets, and interoperability with existing systems. In addition, TCP allows current IP-based devices to communicate directly with sensor nodes and controls the packet size through the maximum segment size (MSS) option, which is useful for memory-constrained systems and systems that are constrained by small packet size. Furthermore, the dominant protocol on the Internet today is TCP with 85%–95% of the total Internet traffic.¹⁸ We believe that it is very plausible that TCP will improve its performance problems over wireless networks in the next years. Note that IP and IPv6 were considered too expensive for WSN; however, it is currently used in WSN, achieving a desirable performance. In fact, the CoAP was designed to use UDP instead of TCP; however, as some applications in some environments benefit from the use of the TCP as transport protocol, in Borman et al.,¹⁹ (work in progress), the authors are proposing the modification of the CoAP protocol to eliminate transport layer protocol features at application layer and support he use of TCP. Furthermore, in Eggert²⁰ an additional congestion control mechanism is proposed because the basic mechanism of CoAP is not sufficient to alleviate network overload in all conditions. Based on the facts mentioned above, we strongly believe that our LSPWSN protocol, which is already implemented and tested, is a viable solution for the Internet of Everything.

LSPWSN represents a viable alternative to applications with strong reliability requirements, where the delivery of data, confidentiality, and reliability are more important than achieving a high throughput. Among these scenarios, we find the following:

Medical applications: in these applications, an intelligent system and several sensors wore by patients can trigger some actions on the body; for example, the sensor can trigger an insulin pump to apply insulin doses, or trigger a pacemaker to speed up, among others. For example, a diabetic patient who needs to apply several insulin doses over the day may have a sensor-based measurement mechanism that automatically applies the needed doses. Likewise, a patient with a heart condition may need an expert system to evaluate whether a pacemaker should go faster or slower. In these cases, confidentiality and reliability are required.

Structural health: to monitor vibrations and material conditions in buildings, bridges, and historical monuments.

Waste management: to detect rubbish levels in containers or to optimize trash collections routes.

Portable water monitoring: to monitor the quality of tap water in cities.

We foresee that in the next 5 years, lots of devices will be connected in the Internet of Everything, and the LSPWSN is ready to cope with the requirements of such new applications which have been currently envisioned for the future Internet.

LSPWSN defines a compact overhead using a short fixed-length header of 2 bytes and typical request to 20 bytes, avoiding packet fragmentation and its associated performance degradation. It uses three types of messages. First, it provides request messages used by a remote client in the Internet to request a resource from the embedded Web server using a POST method to create a resource, a GET method to retrieve a resource, the PUT method to update a resource, and the DELETE method to delete a resource. Second, response messages are used by the embedded Web server to respond request messages from the remote client through a status code that indicates whether a LSPWSN request was successful or unsuccessful; and finally, publication messages are used by the embedded Web server with three meanings, as a publication message, an alarm message, or as a beacon message. The first message is used by the embedded Web server for publishing its services to a service registry entity through a Web application description language (WADL) document, which will be requested by a remote client before sending a request message during the service discovery process. The second is used by the embedded Web server to inform about an unexpected event triggered for some unusual change in the environment. To do this, some entity which could be an observer in the Internet must receive and process the messages to perform some action if necessary. Finally, the third message is used by the service registry entity to become known with the embedded Web servers and is used at boot time only to advertise the IP address of the service registry entity.

The LSPWSN message formats are illustrated in Figure 1(a)–(c). As it depicts, the 2 bytes short fixed-length header could change its field depending on the message type. However, most of the fields have the same meaning. In the following paragraphs, these fields will be described.

Figure 1.

LSPWSN message formats: (a) LSPWSN request message, (b) LSPWSN response message, and (c) LSPWSN publication message.

The message format reads as follows: MT represents the message type. It uses 00_b value for request messages, 01_b for response messages, 10_b for publication messages, and 11_b is reserved for future use. MP indicates the priority of the request message. It uses 0_b to retrieve a resource stored in the embedded Web server local cache or 1_b to retrieve a fresh resource by sensing the environment. OH indicates the presence or absence of optional headers in the request message, setting it to 1_b or 0_b, respectively. RT represents the request type using 00_b to create a resource, 01_b to retrieve a resource, 10_b to update a resource, and 11_b to delete a resource. MB indicates the presence or absence of message body, setting it to 1_b or 0_b, respectively. R is reserved for future use. The URI Path Length field used with a request message represents the length of the resource uniform resource identifier (URI). Through the use of 8 bits, this field enables URIs with a maximum length of 255 bytes. However, the use of compact URIs is suggested. The URI Path used with a request message indicates the path of the resource. The Optional Headers field is used to set the headers, which are optional in the request (although the use of a subset of optional headers used in HTTP would be preferable). Finally, Message Body represents the body of the message to be encoded with EXI, which is a technique to encode and compress XML documents into a binary format. The SC field represents the status code for every request processed by the embedded Web server.

We propose the use of the followings status code, some of them have the same meaning as in HTTP, and others were added for special purposes of this protocol (see Table 1).

Table 1.

Status codes proposed to use with the LSPWSN protocol.

Status code		Binary coding
101	Unexpected event	0000
200	OK	0001
201	Created	0010
400	Bad request	0011
401	Unauthorized	0100
403	Forbidden	0101
404	Not found	0110
405	Method not allowed	0111
409	Conflict	1000
410	Gone	1001
414	Request URI too long	1010
500	Internal server error	1011
503	Service unavailable	1100

LSPWSN: lightweight and secure protocol for wireless sensor networks; URI: uniform resource identifier.

The field T represents one of the three different types of publication messages described previously and is used in conjunction with the RT field. When the T field is set to 00_b, the RT field must be set to 10_b to publish a new service with the registry entity; if it is set to 01_b, the SC field must be used with the 0000_b code (unexpected event) to be used as an alarm message, and the Message Body must describe what type of unexpected event triggered the alarm, including the resource in which the event took place and the measurement value which triggered the alarm. Finally, if the T field is set to 10_b, this message is a beacon message and the remaining fields are ignored.

As a point-to-point protocol, LSPWSN is based on a client–server model, wherein the server is an embedded Web server that plays the provider entity role and router in a multihop 6LoWPAN network. This entity acts as provider entity when it receives a request from the Internet; otherwise, it plays the router role forwarding the packet through the multihop network. This provider entity is implemented on a Full Function Device (FFD) embedded with sensors such as temperature, humidity, luminosity, and among others. These sensors represent active resources which could be accessed by a remote client in the Internet. The remote client located somewhere on the Internet plays the role of a request entity. Besides these two entities, there is an edge router which interconnects the 6LoWPAN network with the Internet and acts as the service registry entity, storing the service descriptions published by all the service providers inside the 6LoWPAN network. Unlike other solutions, we proposed a service registry entity because in many applications direct discovery of resources is not viable due to sleeping nodes and disperse networks. Other solutions, as the CoAP, use this router as a proxy when a request could otherwise not be made with CoAP, this proxy must perform requests on their behalf, but this implies a protocol translation in both the transport and application layers that adds complexity to the border router. In addition, applications must deal with reliability at application layer. In our proposal, this edge router is not used as a proxy because translation at transport layer is not needed thanks to the use of TCP. It also applies with the application layer because it performs an end-to-end connectivity using end-to-end compression of the Web services through the support of binary encoding of headers and payload as proposed compress format on both application end points. Interoperability of LSPWSN with other protocols like HTTP is possible through a mapped mechanism at both end points if necessary.

As displayed in Figure 2, the LSPWSN protocol establishes an end-to-end communication in seven stages:

The provider entity publishes its services to the registry entity through a publication message which carries a WADL document with the service description in its body.

A service discovery process is established by the requester entity through a normal HTTP request to retrieve a full list of the services provided by all provider entities.

The list of the services provided by all provider entities is included in a HTTP response which carries a WADL document that includes the services list and the syntax and semantics needed to establish an end-to-end communication with the embedded Web server using the LSPWSN protocol.

The syntax and semantics are embodied in the requester agent to establish a direct communication with the embedded Web server using the LSPWSN request message proposed in this article.

The requester entity performs a request using the LSPWSN request message. If the remote client wants to retrieve an out-of-date resource, it makes a request from the local cache of the embedded Web server.

If the remote client wants to retrieve a current representation of the resource, the embedded Web server, which acts also as router in a multihop network, must activate its embedded sensors (e.g. temperature, humidity, and luminosity) and sense the environment

The embedded Web server must respond to the request sent by the requester entity through a LSPWSN response message with the current representation of the resource.

Figure 2.

Communication architecture used by LSPWSN protocol.

This process is repeated as necessary and starts in the fifth stage if the requester agent already has the syntax, semantics, and list of services. If not, it is necessary to start with the service discovery process. Before these stages, the registry entity is known within the embedded Web servers as a publication message in its beacon message format, and then the embedded Web servers can start the process of publishing its services to the registry entity. All request and response messages to and from the embedded Web services carry in their body a XML document compressed using EXI, or a text/plain body. Finally, if an expected event is triggered, the embedded Web server becomes a client and some entity in the Internet plays the role of observer (the specification of this observer is out of the scope of this article). This stage must be performed using a LSPWSN publication message in its variant of alarm message.

When security considerations are needed, all messages exchanged between the requester entity and the provider entity must be encrypted to provide information confidentiality. However, due to the constraints of WSNs and because the sensor networks and nodes must be autonomous, a lightweight stream cipher named SNOW in its version 2 is recommended. Fournel et al.²¹ have demonstrated that this stream cipher is lightweight on traditional platforms as well as on highly constrained platforms. Stream ciphers do not provide all the features as block ciphers do; however, they perform better and are less complex than block ciphers for these constrained environments.

LSPWSN performance evaluation

This section comprises a performance evaluation of the LSPWSN protocol in terms of memory footprint, transferred bytes per client–server transaction, service response time, and energy consumption. Performance evaluation was carried out by a comparison of the LSPWSN protocol and CoAP.

The main goal of the experiment is to demonstrate via a quantitative and qualitative analysis that the LSPWSN protocol is energy efficient even when using TCP as transport layer and as an alternative to applications with strong reliability requirements, where the reliability data delivery is more important than the achievement of a high throughput. The benefits of the use of TCP with the LSPWSN protocol are built-in reliability, reduction of the application complexity, control of the maximum size of packets and direct communication with sensor nodes, and interoperability with existing systems. Although it is commonly discussed, the performance problems of TCP due to its end-to-end retransmission scheme, header length, and energy inefficiency; TCP can be used and implemented in an energy-efficient way. To the best of our knowledge, although TCP header compression methods have not yet been standardized for WSNs, we believe that it is likely to happen as IoT grows. Notwithstanding, many TCP implementations are designed for severe resource constraints. Regarding these implementations, we found transmission control protocol header compression (TCPHC),²² which is used to compress TCP headers as it is done with UDP which benefits CoAP. In addition, distributed transmission control protocol caching (DTC) and transmission control protocol support for sensor networks (TSS)²³ could drastically reduce the number of TCP segment retransmissions that are needed to transfer a certain amount of data across a WSN, without losing reliability and reducing the number of packets transferred. With TCPHC algorithm, the TCP header could reduce its overhead in 6LoWPAN networks to 6 bytes in more than 95% of the cases and decreasing the energy consumption by up to 15%. This suggests that the LSPWSN protocol could significantly improve its current performance using a header compression method. However, results show that LSPWSN is energy efficient regardless the use of legacy TCP as transport protocol, which brings the possibility of interoperability with existing systems, IPs, and network infrastructure.

As shown in the next sections, LSPWSN protocol performance is comparable with CoAP performance because its request/response messages are easy to decode using binary encoding and are compact and fit into a single IEEE 802.15.4 with a size of 127 bytes that reduces packet segmentation and TCP’s retransmission. With this performance evaluation, it was found that the LSPWSN protocol has an almost comparable performance to the CoAP in terms of energy consumption, regardless the use of legacy TCP as transport protocol.

Experimental setup

To evaluate the performance of LSPWSN protocol and CoAP, the same scenarios and experiments have been executed on LSPWSN client–server pair and on CoAP client–server pair. In the testbed used in our experiments, the LSPWSN server is written in standard C for Contiki, and our LSPWSN Client is written in Python. In addition, CoAP server is tested using the CoAP C implementation through Erbium (Er) REST Engine for Contiki, and the CoAP client is based on a Java implementation called Californium. Both protocols were tested on Zolertia Z1 platform emulated through Contiki Cooja Network Simulator. The platform is based on MSP430 16-bit CPU running at 8 MHz. It provides a CC2420 radio chip, 92 kB of program flash, and 8 kB of RAM with ContikiMAC enabled, using a wake-up frequency of 8 Hz. The results obtained are an average of 1000 requests per each request type allowed for five active resources in each server (see Table 2).

Table 2.

Resources used to test LSPWSN protocol and CoAP.

URI path	Functionality
test/hello	Well-known message “Hello World” as text
sensors/radio	RSSI or LQI level in the CC2420 transceiver as text
sensors/battery	Voltage level as text
actuators/toggle	Actuator that toggles an LED
actuators/leds	Control an LED per key-value pairs in query and payload

LSPWSN: lightweight and secure protocol for wireless sensor networks; CoAP: constrained application protocol; URI: uniform resource identifier; RSSI: received signal strength indicator; LQI: link quality indicator; LED: light-emitting diode.

Memory footprint

Due to the memory-constrained nature of the hardware used for WSNs, it is important to measure the memory footprint of protocols under the analysis of two important metrics that are the consumed memory usage and the code size. The performance and the code size of both LSPWSN and CoAP servers were improved turning on the flags -ffunction-sections and –gc-sections. The flag -ffunction-sections force the compiler to not mix functions that could be referenced externally, along with the flag –gc-sections which discard unreferenced routines. RAM and ROM usage are analyzed with msp430-size 2.22 and msp430-objdump tools in the MSP430 toolchain from msp430-gcc (GCC) 4.7.0 compiler, respectively. Table 3 depicts the section sizes obtained from msp430-size tool which are used to measure ROM and RAM usage. The RAM usage is measured by summing up the .data (initialized data) and .bss (uninitialized data) sections, whereas the ROM usage is measured by summing up .text (executable code) and .data sections.

Table 3.

Section sizes obtained from msp430-size tool for LSPWSN and CoAP servers.

Protocol	.text (B)	.data (B)	.bss (B)	RAM (kB)	ROM (kB)	Firmware filename
LSPWSN	45121	314	5338	5.52	44.37	lspwsn-server.z1
CoAP	48942	516	6070	6.43	48.30	er-example.z1

LSPWSN: lightweight and secure protocol for wireless sensor networks; CoAP: constrained application protocol.

As displayed in Figure 3, RAM consumption within Zolertia Z1 platform, it is noticed that LSPWSN protocol consumes 5.52 kB of RAM in contrast with CoAP which consumes 6.43 kB from 8 kB of the available Z1 platform. The LSPWSN protocol uses 69% of RAM, while CoAP uses 80.37%. Therefore, LSPWSN achieves 11.37% better RAM footprint than CoAP.

Figure 3.

RAM consumption of LSPWSN versus CoAP in the Zolertia Z1 platform.

Through the analysis of the .map file and the sections and symbols listed with msp430-size and mps430-objdump -t utility, we found that the CoAP modules—er-coap-observe, er-coap-res-well-known-core, and er-coap-transactions—consume 10.87% of the 11.37% RAM footprint that LSPWSN achieves. The CoAP module that mainly contributes to this consumption is er-coap-transactions with 0.625 kB equivalent to 7.18% of the RAM footprint. This module is used to implement the reliability mechanism at application layer used by CoAP. Moreover, keeping RAM as low as possible decreases the risk of stack overflow and maintaining the balance of the stack allows dealing with the worst possible scenarios.

Regarding the 92 kB availability for ROM that Zolertia Z1 platform has, it was found that LSPWSN protocol consumes 44.37 kB of ROM unlike CoAP which consumes 48.30 kB. LSPWSN uses 48.23%, whereas CoAP uses 52.5% of ROM (see Figure 4).

Figure 4.

ROM consumption of LSPWSN versus CoAP in the Zolertia Z1 platform.

As illustrated in Figure 4, the LSPWSN protocol achieves 4.27% better ROM footprint than the CoAP, and this is because the CoAP implements at application layer more functionalities to achieve reliability, observation, and discovery of resources. The implementation only of these modules uses 2.26 kB more ROM footprint. Moreover, the style in which the server resources are programmed affects the ROM footprint.

Given these facts, the LSPWSN protocol achieves a better use of Zolertia Z1 RAM and ROM and provides reliability with a lower memory footprint than CoAP does on Zolertia Z1 platform.

Transferred bytes per client–server transaction

To evaluate the performance of the LSPWSN protocol and CoAP in terms of bandwidth usage, the same scenarios and experiments have been executed on LSPWSN client–server pair and on CoAP client–server pair. As mentioned in the “Experimental setup” section, CoAP requests are performed using confirmable (CON) messages, where a CoAP transaction consists of CON and acknowledgement (ACK) messages. Results have been achieved by computing the transferred bytes per transaction between client and server pair. The number of transferred bytes per client-server transaction has a direct impact over energy consumption since the transceiver and the CPU have an intensive activity. This process shows that the transactions start when the client initiates a resource request and ends when the client gets the response. Responses can be either with the representation of the resource included in its payload body or with a response of success with no payload body.

To quantify the number of transferred bytes per transaction, a series of Web service requests are performed, first between a LSPWSN client and server and later between a CoAP client and server system. The packet sniffer Wireshark has been used to measure the bytes transferred by every request with both protocols. In addition, as measured by Colitti et al.,²⁴ to demonstrate the viability of binary encoding application protocols over the TCP transport protocol, the comparison integrates the number of transferred bytes and packets per client/server transaction of HTTP protocol. Caro et al.²⁵ provided a quantitative comparison between CoAP and message queue telemetry transport (MQTT) protocol. MQTT is a lightweight machine-to-machine (M2M) protocol based on a publish–subscribe pattern and designed to work over TCP transport protocol. Even when MQTT is designed to follow a publish–subscribe pattern and used more in M2M scenarios, it is also used in IoT scenarios. However, in the quantitative comparison provided by Caro et al., the total bandwidth usage (transferred bytes) per transaction is not clear. In our view, the measurement of the transferred bytes per transactions must start from the synchronize (SYN) to the final ACK segment for closing the TCP connection. Nevertheless, they state that a transaction with MQTT using quality of service (QoS) 1 uses 162 bytes, in which only the three-way handshake of TCP uses 204 bytes. For this reason, it seems that their measurements only involve the bytes used by the PUBLISH and PUBACK messages and not the whole transaction from the SYN segment to the final ACK. As a consequence, we could not integrate the MQTT protocol in our comparison.

Figures 5 and 6 illustrate the results obtained from the comparison between LSPWSN, CoAP, and HTTP protocols in terms of transferred bytes and the number of packets required per transaction.

Figure 5.

Transferred bytes required per client–server transaction between LSPWSN, CoAP, and HTTP protocols.

Figure 6.

Transferred packets required per client–server transaction between LSPWSN, CoAP, and HTTP protocols.

An LSPWSN transaction has a number of bytes, nearly five times larger than a CoAP transaction, and nearly four times more packets are required. This increment in bytes and packets transferred per client–server transaction is necessary to occur to provide security and reliability. Furthermore, LSPWSN uses twice fewer bytes and packets transferred per transaction than HTTP. HTTP uses 1288 bytes and 17 packets per transaction.²⁴ This comparison shows clearly that LSPWSN has an advantage over HTTP in terms of transferred bytes per client–server transaction as consequence of its short fixed-length compact binary header of 2 bytes and typical requests about 20 bytes. It is worthwhile noting that the LSPWSN packets for a request and a response are transferred within a single IEEE 802.15.4 frame after being encapsulated in TCP, 6LowPAN, and media access control (MAC) layer headers, avoiding fragmentation of packets.

The number of transferred bytes per transaction will improve significantly if a TCP header compression method is used. As previously mentioned, although TCP header compression mechanisms have not yet been standardized for WSNs, we believe its standardization is likely to happen in the near future. Within these implementations, we found that TCPHC is used to compress TCP headers as it is done with UDP which benefits CoAP. In addition, DTC and TSS could drastically reduce the number of needed TCP segment retransmissions in order to transfer a certain amount of data across a WSN. This is done without losing reliability and reducing the number of transferred packets.

Given these facts, LSPWSN protocol stands as an energy-efficient and lightweight RESTful protocol, supporting strong reliability constraints and a direct compatibility with existing IPs.

Service response time

Performance of applications with strict requirements in terms of latency is affected when the service response time values are higher because the user is expecting to access sensor data from the Web in quasi-real time. Therefore, service response times play an important role in the evaluation of application protocols for the WoT paradigm. Service response time is considered as the time elapsed between a request and its corresponding response.

This experiment depicts the comparison between the LSPWSN protocol and the CoAP in terms of service response time. Both protocols were executed in the same scenarios and tested through the same experiments on LSPWSN client–server pair and on CoAP client–server pair. As stated in the “Experimental setup” section, LSPWSN server and client were tested through our implementation in standard C for Contiki and Python, respectively; whereas, testing of the CoAP server was developed through the Erbium (Er) REST Engine for Contiki, and CoAP client tests were conducted through the Java implementation called Californium. In the case of CoAP, its requests were performed through CON messages that helped testing both protocols in a reliable scenario. A CoAP message labeled as CON implies that it is retransmitted up to a maximum number of times using a default response timeout and exponential back-off algorithm which schedules retransmissions until the recipient sends an ACK message.

In this experiment, the test has been executed through 1000 requests per resource type in a 1-hop scenario, where the edge router is the only intermediate between client and server, and the results presented were analyzed using the Wireshark packet sniffer.

As illustrated in Figure 7, we use the box plot statistical technique to spread out the service response time values obtained from 1000 requests per resource type with the LSPWSN protocol and CoAP. As depicted, the service response time of the LSPWSN protocol is skewed due to the use of TCP as transport protocol because the LSPWSN server deals with seven more packets than the CoAP Web server does. These packets are for synchronization and acknowledgments owing the nature of TCP, which increase the elapsed time between a request and its corresponding response. On the contrary, the service response time of the CoAP is symmetric because the CoAP server only copes with two packets, and as consequence, the elapsed time between a request and its corresponding response is approximately the same.

Figure 7.

Service response time for LSPWSN and CoAP over 1000 requests per resource.

Both protocols present atypical values (outliers), and these atypical values are the result of retransmissions. These retransmissions are originated due to its coincidence with the change to active/sleep mode of the Web servers and packets loss. However, as depicted in Figure 7, in all cases, the CoAP shows a larger number of requests with atypical service response time values (outliers) than the LSPWSN protocol. These results showed that the LSPWSN protocol using TCP presents a more stable behavior than the CoAP using UDP, because with UDP there is not guarantee in the delivery of the message. In a larger network with more traffic, this scenario could be worst with CoAP using UDP. In scenarios where strong requirements of reliability have been established, the LSPWSN protocol using TCP is beneficial.

As shown in Figure 7, the half (median) of the requests presents a service response time of 0.76 and 0.46 s with the LSPWSN protocol and CoAP to access test/hello resource; 0.69 and 0.53 s to access sensors/battery; 1.17 and 0.39 s for sensors/radio resource; 1.39 and 0.53 s for actuators/leds resource, respectively; and finally, 1.5 and 0.50 s, respectively, for actuators/toggle resource.

The average (mean) service response time calculated for the 1000 client requests per resource shows the following: 0.95 s with LSPWSN and 0.47 s with CoAP. Regarding sensors/battery, it displays 0.93 and 0.81 s. Likewise, sensors/radio indicate 1.2 and 0.44 s, respectively. For actuators/leds, it reads 1.36 and 0.54 s; and finally, the displayed figures 1.4 and 0.8 s correspond to actuators/toggle, respectively.

The highest service response times reached with both LSPWSN protocol and CoAP are the following: 2.64 and 1.07 s for test/hello resource; 2.5 and 1.29 s for sensors/battery resource; 2.73 and 1.10 s for sensors/radio resource; 3.06 and 1.07 s for actuators/leds resource and finally, 2.8 and 1.4 s for actuators/toggle resource, respectively.

Moreover, with both LSPWSN protocol and CoAP, 75% of the requests present a service response time below or equal to 1.52 and 0.64 s for the test/hello resource; 1.33 and 0.75 s for the sensors/battery resource; 1.65 and 0.60 s for the sensors/radio resource; 1.77 and 0.66 s for the actuators/leds resource; and finally, 1.82 and 0.78 s for the actuators/toggle resource, respectively.

With the LSPWSN protocol, the 50% of all requests present a service response time in the range of 0.40–1.52 s for the test/hello resource; 0.49–1.33 s for the sensors/battery resource; 0.70–1.65 s for the sensors/radio resource; 0.87–1.77 s for the actuators/LEDs resource; and finally, 0.85–1.82 s for the actuators/toggle resource. However, with the CoAP, the 50% of the service response time of all requests is in the range of 0.31–0.64 s for the test/hello resource; 0.37–0.75 s for the sensors/battery resource; 0.27–0.60 s for the sensors/radio resource; 0.38–0.66 s for the actuators/LEDs resource; and finally, 0.35–0.78 s for the actuators/toggle resource.

Additionally, with the LSPWSN protocol and CoAP, 25% of all requests present a service response time below 0.40 and 0.31 s for the test/hello resource; 0.49 and 0.37 s for the sensors/battery resource; 0.70 and 0.27 s for the sensors/radio resource; 0.87 and 0.38 s for the actuators/LEDs resource; and finally, 0.85 and 0.35 s for the actuators/toggle resource, respectively.

As expected our experiments show that the LSPWSN protocol presents a higher service response time, because it manages seven more packets than does CoAP with UDP. This scenario increases the elapsed time between a request and its corresponding response, taking a higher service response time. However, the LSPWSN protocol has been designed for applications were data reliability is more important than achieving a high throughput. We believe that the service response time of the LSPWSN protocol is satisfactory considering that the 50% of the requests present a service response time in the range of 0.40–1.52 s.

Energy consumption

One of the primary requirements of any application protocol for WSNs is the reduction of energy consumption due to their constrained environment characteristics. Energy consumption is affected for several factors, including the number of bytes and packets transferred per transaction because the transceiver and CPU have an intensive activity.

To measure the energy consumption of LSPWSN protocol and CoAP, 1000 requests per active resource were performed to the LSPWSN and the CoAP Web servers with a time of 10 s between each request. For this evaluation, the Powertrace tool built in Contiki OS was used. Powertrace is an energy estimation module which enables the estimation of energy consumption in terms of usage time, using a software-based on-line energy estimation mechanism which runs directly on the sensor nodes and provides real-time estimations of the current energy consumption.²⁶ Powertrace uses a power state tracking to estimate the power consumption of the system, using a time stamp when a component enters and leaves a new power state. These power states were periodically printed and were stored in a log file, which was later used with a Python script to process the results and plot the energy estimation through the on-line energy estimation mechanism, which uses a linear model where the total energy consumption E is defined as

\frac{E}{V} = I_{m} t_{m} + I_{l} t_{l} + I_{t} t_{t} + I_{r} t_{r} + \sum_{i} I_{c_{i}} t_{c_{i'}}

(1)

where V is the supply voltage, I_m refers to the current draw of the microprocessor when running, t_m represents the time in which the microprocessor has been running, I_l and t_l show the current draw and the time of the microprocessor in low power mode (LPM), I_t and t_t display the current draw and the time of the communication device in transmit mode, I_r and t_r refer to the current draw and time of the communication device in receive mode, and $I_{c_{i}}$ and $t_{c_{i}}$ represent the current draw and time of other components as sensors and light-emitting diodes (LEDs), respectively.

To estimate the energy consumption with the estimation mechanism, it is necessary to know the current draw for the microprocessor, communication device, and all the components to be used in equation (1). According to Zolertia Z1 platform configuration in Contiki OS, the approximate current draw used to measure the energy consumption have been taken from MSP340F2617 and CC2420 datasheets, see Table 4. Only the microprocessor and the communication device were considered, because they are the main consumers of energy.

Table 4.

Approximate current consumption for Zolertia Z1 platform.

Device	Operation mode	Approximate current draw	Explanation
MSP430F2617	Active mode (AM)	4.3 mA	Using a DCO of 8 MHz and a nominal voltage of 3 V
	Low power mode (LPM3)	1.1 µA	Only the external xtal ACLK of 3,28,768 Hz remains active
CC2420	RX mode	18.8 mA
	TX mode	17.4 mA

The energy consumption of the CoAP and LSPWSN server in each power state are illustrated in Figure 8. The obtained results provide interesting insights on the performance of the proposed LSPWSN protocol. In particular, it can be observed that the averaged energy consumption to process (decoding and encoding) request/responses of the CPU in AM using the LSPWSN protocol is 0.095 mW. In the same way, the energy consumption in this power state using CoAP is 0.093 mW.

Figure 8.

Energy consumption of LSPWSN and CoAP servers over 1000 requests per resource.

As illustrated in Figure 8, the average energy consumption for the CPU in LPM for both LSPWSN protocol and CoAP is 0.0033 mW. This means that the time spent in this mode of both servers is the same as consequence of the use of the ContikiMAC radio duty cycling mechanism which uses a simple but elaborate time mechanism for the wake-up cycle.

As noted in Figure 8, the most significant energy consumption using both protocols take place when the radio transceiver is in RX mode, because the ContikiMAC radio duty cycling mechanism switches the radio on and off to conserve power while preserving the ability to communicate. Thus, the listening energy increases even if the server was not involved in any communication. Under these circumstances, the average energy consumption for RX mode using LSPWSN is 0.3673 mW and using CoAP is 0.3410 mW, and for the TX mode using LSPWSN, the energy consumption is 0.0123 mW and for CoAP is 0.0085. The energy consumption using LSPWSN increments as consequence of the uncompressed header of TCP and by the processing of seven more packets than it does with CoAP using UDP.

To summarize, the total energy consumption for 1000 requests/responses per active resource is illustrated in Figure 9. This total energy consumption has been calculated using equation (1), which follows the Energy Linear Model.

Figure 9.

Total energy consumption of LSPWSN and CoAP servers over 1000 requests per resource.

As a result, the average total energy consumption for LSPWSN protocol and CoAP through 1000 transactions is 0.478 and 0.446 mW, respectively. As noticed, LSPWSN consumes 0.032 mW more than CoAP, due to the use of TCP as transport layer, which increments the number of bytes and packets received and transmitted per transaction.

In summary, LSPWSN has an energy-efficient performance although it has been transported using TCP. The increment of energy consumption with the LSPWSN protocol is the price to pay off to achieve reliability. However, as mentioned in the “LSPWSN protocol overview” section, for some applications, the delivery of the packets is more important than achieving a high throughput. Furthermore, this aggregated energy consumption introduced by TCP could be improved significantly with the use of a TCP header compression mechanism. However, until now, TCP header compression mechanisms have not yet been standardized for WSNs, but there is a strong probability that TCP will be implemented in an energy-efficient way, because the core functionality of TCP is not so complex. Non-standardized implementations to make an energy efficient TCP are TCPHC²² for compressing TCP headers and DTC or TSS²³ for reducing the total number of packet transmissions. This suggests that even with the use of legacy TCP, the LSPWSN protocol and CoAP are evenly comparable in performance, considering that the LSPWSN protocol processes seven more packets than the CoAP does with UDP.

Level of interoperability

Interoperability is core value of the IoT and traditional Internet. Since future networks will continue to be heterogeneous, systems need to share the same language of protocols and encodings. Explicitly, IoT requires the use of standard-based solutions to enable a horizontal seamless interoperability that avoids different and incompatible communication protocols until all objects are interconnected. The 6LowPAN standard and the use of Web services are an effort to ensure interoperability between systems. Nevertheless, interoperability among IoT devices and systems occurs in varying degrees at different layers within the communication protocol stack.²⁰

With this in consideration, in this section, we provide a qualitative analysis of LSPWSN protocol and CoAP (see Table 5). Such analysis indicates the level of importance and interoperability that these protocols support for the IoT.

Table 5.

Qualitative comparison of LSPWSN protocol versus CoAP.

Functionality	LSPWSN	CoAP
Transparency and end-to-end connectivity	End-to-end connectivity is accomplished by having the codification and decoding of LSPWSN request/responses from source to destination without any intermediary proxy or any extra processing infrastructure. Transparency is done using HTTP URLs, as consequence the user believes that he is using HTTP.	End-to-end connectivity is done only with UDP and the use of CoAP: prefix. No end-to-end connectivity if the client sends an HTTP request, because it is necessary the use of an intermediary proxy for performing a HTTP/TCP to CoAP/UDP translation. The user is aware of the use of a new protocol, which brings the feeling of fragmentation of the IoT.
Reliability end-to-end	Reliability is inherently achieved using TCP, which offers reliability to applications through the track of sent and received data.	It provides an optional reliability through the definition of “confirmable” messages, where a delivery confirmation is required. This mechanism uses an exponentially backed-off timer to schedule four retransmissions attempts.¹⁹ However, it does not confirm that the content of the message was decoded correctly, and it only confirms that the message was received. A non-confirmable message is sent and forgotten.
Flow and congestion control	There is flow and congestion control implemented in TCP. This eliminates the redundant mechanism of congestion, flow control, and detection of duplicate messages at application layer.	Basic flow control and congestion control are provided by the message layer of CoAP, through the exponential back-off mechanism. Clients and proxies must limit the number of simultaneous outstanding interactions that they maintain to a given server. This mechanism is not sufficient to mitigate network overload, because it is not possible to ensure that any network will be congestion-free at any time.¹⁹
Performance	Performance of LSPWSN is lower because it is using TCP without any compression mechanism and in its nature flow. However, this issue could be faced using techniques as TCPHC²² for compression of headers and TSS²³ or DTC²³ to reduce the number of segment transmissions.	Performance is higher due to less overhead. However, it does not guarantee that the data will arrive.
Layers translation	LSPWSN does not require translation at transport layer because TCP is the most used transport protocol in the Internet. It only requires a minimal correspondence at application layer due to its binary encoding nature. However, this correspondence is implemented in clients in a transparent manner for the users.	CoAP requires translation at both transport and application layers when a CoAP request otherwise cannot be made so that it is necessary to use a proxy in the edge router to perform this translation. Consequently, CoAP intensifies complexity and overload in applications.
Compatibility and integration with existing infrastructure and applications	TCP is the dominant protocol on the Internet with an 85%–95% of the Internet traffic.¹⁸ Consequently, LSPWSN could be integrated with existing applications and infrastructure in the same percentage.	The use of UDP brings interoperability issues with existing infrastructure and applications that uses traditional Internet protocols, where UDP-based protocols may not be well-received or may even be blocked by firewalls.²⁷ Moreover, translation at transport layer and application layer will be required.

LSPWSN: lightweight and secure protocol for wireless sensor networks; CoAP: constrained application protocol; UDP: user datagram protocol; URL: uniform resource locator; HTTP: hypertext transfer protocol; TCP: transmission control protocol; TCPHC: transmission control protocol header compression; TSS: transmission control protocol support for sensor networks; DTC: distributed transmission control protocol caching.

As mentioned by C Borman et al.,¹⁹ the CoAP needs to support different transport protocols, namely, TCP. Additionally, to the applications specified in the “LSPWSN protocol overview” section, the use of TCP is beneficial in environments where:

IoT protocols need to integrate well with existing enterprise infrastructures, where UDP-based protocols may not be well-received or may even be blocked by firewalls, because entities unaware of these protocols can make the use of UDP brittle, resulting in lost or malformed packets.

Large payloads must be exchanged, such as firmware images, without application layer segmentation and for utilizing the congestion control functionalities provided by TCP.

To achieve a seamless integration and interoperability with existing infrastructure and systems.

Under this scope, some work in progress tries to face these issues. First, in Borman et al.,¹⁹ the modification of the CoAP message format to eliminate transport layer protocol features at application levels is proposed. Second, in previous studies,^20,28,29 additional congestion control mechanisms are proposed because the basic mechanism of CoAP is not sufficient to alleviate network overload in all conditions.

Conclusion and future work

IPs such as HTTP and SOAP used with these Web services were not designed to meet the necessary number of requirements for the 6LoWPAN constrained environments. Hence, when an application protocol is designed for these networks, these issues should be considered. Consequently, a new protocol named LSPWSN is proposed to work over the TCP and the IPv6 protocols, using the 6LoWPAN standard.

Our results show that the LSPWSN protocol is energy efficient and has a performance comparable with CoAP, regardless to the use of the TCP protocol as transport layer in its normal configuration and without any header compression. LSPWSN has a short fixed-length compact binary header of 2 bytes and typical requests/responses about 20 bytes. Yet, these results could improve significantly if the LSPWSN protocol uses solutions proposed for the compression of TCP headers and the reduction of the number of transmitted packets, which could be achieved using techniques to cache TCP segments and to perform local retransmissions in case of error. Hitherto, to the best of our knowledge, TCP header compression methods have not yet been standardized for WSNs; as IoT grows, we strongly believe that standardization is very likely to happen. Some no standardized solutions under this scope are presented in Ayadi et al.²² and Braun et al.²³

Two primary contributions are highlighted within this article:

First, a lightweight and energy-efficient protocol to enable Web services in 6LoWPANS is proposed, implemented, and tested. It is based on binary encoding, following a RESTful approach. It uses TCP as transport protocol, making this protocol a feasible solution when the delivery of data, confidentiality and reliability are more important than achieving a high throughput (network management, remote programming, and sensor management).

Second, this work evaluates a quantitative and a qualitative performance analysis of two RESTful application protocols based on binary encoding and using different transport protocols. This evaluation highlights the benefits and drawbacks of a RESTful protocol over different transport layers, identifying the applications that could benefit from the use of a RESTful protocol using TCP as transport layer. To the extent of our knowledge, there is no published literature about works performing a quantitative and qualitative evaluation between only RESTful protocols based on binary encoding. Other works,^25,30,31 present an evaluation of binary encoded protocols using different layers; however, the protocols compared in these works follow other communication patterns.

Having a direct interaction, strong reliability, and compatibility with existing IPs, our protocol is a feasible option for applications in the areas such as military, health, and among others in which strong reliability constraints are imposed. Moreover, our LSPWSN protocol based on the REST architectural style is a good candidate for performing tasks such as configuration, reprogramming, or management of sensor nodes because REST, from our standpoint, is a flexible, modern, and cross-platform device solution for initiation actions on networks nodes.

Through experimental evaluation, it was found that the use of binary encoding application protocols when using the TCP protocol as transport layer is a feasible solution to enable Web services in 6LoWPAN networks when reliable communications are required. The evaluation of LSPWSN was performed in terms of memory footprint, transferred bytes per client-server transaction, service response time, and energy consumption.

In terms of memory consumption, LSPWSN performs better than CoAP. The former consumes 69% of RAM whereas CoAP consumes 80.37% of RAM so that there is a 11.37% RAM saving with LSPWSN. Likewise, LSPWSN uses 48.23% and CoAP uses 52.5% of ROM.

Regarding service response time, as expected our experiments show that the LSPWSN protocol presents a higher service response time, because it manages seven more packets than the CoAP does with UDP, which increases the elapsed time between a request and its corresponding response, taking a higher service response time. However, the LSPWSN protocol has been designed for applications were data delivery is more important than achieving a high throughput. We believe that the service response time of the LSPWSN protocol is satisfactory considering that the 50% of the requests present a service response time in the range of 0.40–1.8 s, considering that the request begins from the SYN to the final ACK segment for closing the TCP connection.

The results obtained provide interesting insights for the scientific community about how binary encoding application protocols using TCP as transport layer could be as efficient as other solutions offered using UDP, which brings important benefits for reducing complexity and overload to the edge router, because translation at both transport and application layers is not necessary when interoperability with existing systems is needed. Moreover, with these protocols, it is possible to achieve compatibility with existing systems and IPs without modifying the existing network infrastructure and consequently managing full integration with the IoT and WoT.

As future work, it is planned to evaluate the possibilities and limitations of both LSPWSN protocol and CoAP when security mechanisms are introduced and their impact in terms of memory consumption, energy consumption, transferred bytes per client/server transaction, and service response time. A comparison of the LSPWSN protocol with the HTTP protocol will also be performed, to contrast the cost efficiency of these three protocols. In addition, there is a strong interest in performing a quantitative and a qualitative comparison of the LSPWSN protocol with the simple network management protocol (SNMP) to demonstrate the viability of the presented protocol for performing task related to the management of sensor networks. Moreover, we are currently in the process of implementing the LSPWSN protocol over UDP transport protocol and comparing it yet again with the CoAP, to prove the efficiency of the LSPWSN within unreliable scenarios.

Footnotes

Academic Editor: Jose L Ayala

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) received no financial support for the research, authorship, and/or publication of this article.

References

Yazar

Dunkels

. Efficient application integration in IP-based sensor networks. In: Proceedings of the 1st ACM workshop on embedded sensing systems for energy-efficiency in buildings (BuildSys 09), Berkeley, CA, 3 November 2009, pp.43–48. New York: ACM.

Montenegro

Hui

Culler

. Transmission of IPv6 packets over IEEE 802.15.4 networks (RFC 4944), https://rfc-editor.org/rfc/rfc4944.txt

Hui

Culler

DE.

Extending IP to low-power, wireless personal area networks. IEEE Internet Comput 2008; 12(4): 37–45.

Atzori

Iera

Morabito

From “smart objects” to “social objects”: the next evolutionary step of the Internet of Things. IEEE Commun Mag 2014; 52(1): 97–105.

Castellani

Gheda

Bui

. Web services for the Internet of Things through CoAP and EXI. In: Proceedings of the IEEE international conference on communications workshops (ICC), Kyoto, Japan, 5–9 June 2011, p.16. New York: IEEE.

Shelby

Bormann

6LoWPAN: the wireless embedded Internet. New York: Wiley, 2010.

Pautasso

Zimmermann

Leymann

. Restful Web services vs. “big” Web services: making the right architectural decision. In: Proceedings of the 17th international conference on world wide web (WWW 08), Beijing, China, 21–25 April 2008, pp.805–814. New York: ACM.

Schneider

Kamiya

Peintner

. Efficient XML interchange (EXI) format 1.0 (working draft WD-exi-20080919). World Wide Web Consortium, 2008, https://www.w3.org/TR/exi/

Figueroa

Perez

Amezcua

. A lightweight and secure protocol to access Web services in 6LoWPAN. In: Proceedings of the 22nd international conference on electrical communications and computers, Cholula, Mexico, 27–29 February 2012, pp.80–85. New York: IEEE.

10.

Luckenbach

Gober

Arbanowski

. TinyREST—a protocol for integrating sensor networks into the Internet. In: Proceedings of the 1st REALWSN 2005 workshop on real-world wireless sensor networks, Stockholm, 20–21 June 2005, 5 pp. Stockholm: SICS (SICS Technical Report T2005:09).

11.

Buckl

Sommer

Scholz

. Services to the field: an approach for resource constrained sensor/actor networks. In: Proceedings of the international conference on advanced information networking and applications workshops, Bradford, 26–29 May 2009, pp.476–481. New York: IEEE.

12.

Gopinath

Khan

Suryady

. Optimized Web service architecture for 6LoWPAN. In: Proceedings of the international conference on information networking, Chiang Mai, Thailand, 21–24 January 2009, p.13. New York: IEEE.

13.

Sleman

Moeller

Integration of wireless sensor network services into other home and industrial networks; using device profile for Web services (DPWS). In: Proceedings of the international conference on information and communication technologies: from theory to applications, Damascus, Syria, 7–11 April 2008, p.15. New York: IEEE.

14.

Frank

Chopan—compressed HTTP over PANs: draft-frank-6lowpan-chopan-00. Internet Engineering Task Force, 2009, https://tools.ietf.org/html/draft-frank-6lowpan-chopan-00

15.

Shelby

Hartke

Bormann

The constrained application protocol (CoAP) (RFC 7252), 2015, https://rfc-editor.org/rfc/rfc7252.txt

16.

Tolle

Embedded binary HTTP (EBHTTP): draft-tolle-core-ebhttp-00. Internet Engineering Task Force, 2010, https://tools.ietf.org/html/draft-tolle-core-ebhttp-00

17.

Das

. IPv6 and IPSec—securing the next generation Internet. IPv6.com, http://ipv6.com/articles/security/IPsec.htm

18.

Janevski

Traffic analysis and design of wireless IP networks. Norwood, MA: Artech House, 2003.

19.

Borman

Lemay

Tschofenig

. TCP and TLS transport for the constrained application protocol (CoAP): draft-tschofenig-core-coap-tcp-tls-07. Internet Engineering Task Force, 2017, https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-tcp-tls-09

20.

Eggert

Congestion control for the constrained application protocol (CoAP): draft-eggert-core-congestion-control-01. Internet Engineering Task Force, 2011, https://tools.ietf.org/html/draft-eggert-core-congestion-control-01

21.

Fournel

Minier

Ubeda

Survey and benchmark of stream ciphers for wireless sensor networks. Berlin, Heidelberg: Springer, 2007, pp.202–214.

22.

Ayadi

Maille

Ros

. Implementation and evaluation of a TCP header compression for 6LoWPAN. In: Proceedings of the 2011 7th international wireless communications and mobile computing conference, Istanbul, 4–8 July 2011, pp.1359–1364. New York: IEEE.

23.

Braun

Voigt

Dunkels

Energy-efficient TCP operation in wireless sensor networks. PIK J 2005, http://rvs.unibe.ch/research/pub_files/BVD05.pdf

24.

Colitti

Steenhaut

Caro

. Evaluation of constrained application protocol for wireless sensor networks. In: Proceedings of the 2011 18th IEEE workshop on local metropolitan area networks (LANMAN), Chapel Hill, NC, 13–14 October 2011, p.16. New York: IEEE.

25.

Caro

Colitti

Steenhaut

. Comparison of two lightweight protocols for smartphone-based sensing. In: Proceedings of the 2013 IEEE 20th symposium on communications and vehicular technology in the Benelux (SCVT), Namur, 21 November 2013, pp.1–6. New York: IEEE.

26.

Dunkels

Osterlind

Tsiftes

. Software-based online energy estimation for sensor nodes. In: Proceedings of the 4th workshop on embedded networked sensors (EmNets 07), Cork, 25–26 June 2007, pp.28–32. New York: ACM.

27.

Rose

Eldridge

Chapin

The Internet of Things (IoT): an overview (understanding the issues and challenges of a more connected world). Internet Engineering Task Force, 2015, http://www.internetsociety.org/doc/iot-overview

28.

Bormann

Betzler

Gomez

. CoAP simple congestion control/advanced: draft-ietf-core-cocoa-01. Internet Engineering Task Force, 2017, https://tools.ietf.org/html/draft-ietf-core-cocoa-01

29.

Bormann

Hartke

Congestion control principles for CoAP: draft-bormann-core-congestion-control-02. Internet Engineering Task Force, 2012, https://tools.ietf.org/html/draft-bormann-core-congestion-control-02

30.

Slabicki

Grochla

. Performance evaluation of CoAP, SNMP and NETCONF protocols in fog computing architecture. In: Proceedings of the 2016 IEEE/IFIP network operations and management symposium (NOMS 2016), Istanbul, 25–29 April 2016, pp.1315–1319. New York: IEEE.

31.

Thangavel

Valera

. Performance evaluation of MQTT and CoAP via a common middleware. In: Proceedings of the 2014 IEEE 9th international conference on intelligent sensors, sensor networks and information processing (ISSNIP), Singapore, 21–24 April 2014, pp.1–6. New York: IEEE.