Surﬁng the Internet-of-Things: Lightweight Access and Control of Wireless Sensor Networks Using Industrial Low Power Protocols

Internet-of-Things (IoT) is emerging to play an important role in the continued advancement of information and communication technologies. To accelerate industrial application developments, the use of web services for networking applications is seen as important in IoT communications. In this paper, we present a RESTful web service architecture for energy-constrained wireless sensor networks (WSNs) to enable remote data collection from sensor devices in WSN nodes. Speciﬁcally, we consider both IPv6 protocol support in WSN nodes as well as an integrated gateway solution to allow any Internet clients to access these nodes. We describe the implementation of a prototype system, which demonstrates the proposed RESTful approach to collect sensing data from a WSN. A performance evaluation is presented to illustrate the simplicity and e ﬃ ciency of our proposed scheme


Introduction
In recent years, the Internet-of-things (IoT) has emerged as an important research focus of both industry and academia.The concept of IoT can be traced back to the pioneering work done by Kevin Ashton in 1999 [1] on using radio frequency identification (RFID) tags in supply chain management.Soon after, this term became popular and is well known as a new type of communication system in which the Internet is extended to the physical world via wireless sensor networks (WSNs) [2].
With the rapid development of IoT technologies in the past few years, a wide range of intelligent and tiny sensing devices have been massively deployed in a variety of vertical applications, and several major standardization alliances or forums have emerged based on the interests of technology developments and commercial markets.Generally, sensing devices are constrained by limitations in energy resources (battery power), processing and storage capability, radio communication range and reliability, etc., and yet their deployment must satisfy the real-time nature of applications under little or no direct human interactions.Over the past decades, the research community has invested substantial efforts to develop networking systems called WSNs that meet the challenges stated above.With large-scaled deployments of WSNs and their interconnection into the global IoT, a new ecosystem supporting ubiquitous deployment of smart applications has been formed.
Technically speaking, current IoT solutions can be categorized as non-IP based or IP based solutions.Most off-the-shelf solutions belong to the former, especially those from some well-known standard alliances, such as ZigBee [3], Z-Wave [4], INSTEON [5] and WAVE2M [6].However, most of these non-IP solutions are isolated within their own verticals, which hinder the global IoT development due to incompatibility across heterogeneous communication systems.
Motivated by the fact that the Transmission Control Protocol (TCP)/Internet Protocol (IP) suite is the de-facto standard for computer communications in today's networked world, IP based solutions could be the future for networks that form the IoT [7].In order to tackle the technical challenges, such as extensive protocol overheads against memory and computational limitations of sensor devices, the Internet Engineering Task Force (IETF) has taken the lead to develop and standardize communication protocols for resource constrained devices, including Routing Protocol for Low Power and Lossy Networks (RPL) [8], and Constrained Application Protocol (CoAP) [9].Besides, the IP Smart Object Alliance (IPSO) [10] also actively promotes the use of IP version 6 (IPv6) embedded devices for machine-to-machine (M2M) applications.Although it is still in its early stage to be commercialized, there are already a substantial number of IP-based WSN solutions supported by growing availability of products and systems.
To promote organic-growth of IoT systems, open technologies are preferred for integration into IoT, and IPv6-based solutions are promising.In order to well-maintain sensor devices as well as facilitate the efficient development of IoT applications, e.g., to monitor the performance of sensor devices and send commands to sensor nodes, trusted-entities in an IoT system should be provided with a reliable and efficient way to remotely monitor and control WSNs without consuming significant resources.We take an approach based on the Representational State Transfer (REST) paradigm [11] whereby a lightweight web server can be embedded in resource constrained sensor devices.In essence, not only can the proposed method integrate IoT devices into the network, but also connect them to the "web".
The following summarizes our contributions and key results: • We propose two alternative access methods to enable REST based applications with sensor devices.In the direct access method, the user can directly visit any sensor devices by sending CoAP request, whereas for the proxy access method, the user can use the normal HTTP requests to access sensor devices, but the gateway needs to help convert the HTTP requests to CoAP requests and vise versa.
The remainder of this paper is organized as follows.A survey of related works is provided in Section 2. The implementation of the RESTful protocol stack in WSNs is introduced and analyzed in Section 3. The prototype implementation of the remote access schemes is presented in Section 4 and performance evaluation results are shown in Section 5. Finally, concluding remarks are given in Section 6.

Related Works
Recent technology trends in the Web Services (WS) are primarily focused on two different architectures, namely Big WS (or WS-*) and RESTful WS.Cesare et al. in [12] compare these two architectures and argue that the RESTful WS can create a loosely coupled system that is better suited for simple and flexible integration scenarios, whereas WS-* can provide more advanced quality-of-service support for enterprise-class applications.
Many recent works are dedicated to the development of REST-style IoT systems to enable easy access from application servers to wireless sensor devices, since the REST-style device would not require any additional application programming interface (API) or descriptions of resources/functions.REST is a general architectural design style for developing lightweight WS to access resources over the Internet using standard protocols.It provides a design concept that all the objects in the Internet are abstracted as resources.Each resource corresponds to a unique identity.Through a general interface, all the operations on a resource do not change its identity as they are stateless.RESTstyle can make applications as sharable, reusable and loose coupling services.The uniform operation and interaction mechanisms on resources can help developers or decision makers to quickly react to market changes.
Weijun et al. in [13] propose an adaptation layer to integrate RESTful WS infrastructures, which can enable connectivity of embedded devices with mobile Internet applications.Vlad in [14] proposes a resource discovery mechanism based on RESTful principles, which enables a plug and play experience in web of things.Dominique et al. in [15] and [16] also propose a RESTful mechanism to integrate wireless energy monitors with application servers to build mashup applications.However, most of the embedded devices considered in the above works are not IP based, which means that a multiprotocol translation gateway is needed.As discussed in [2], network protocol translation can bring more complexity than just a packet format conversion, which usually involves semantics translations between different mechanisms and logics for routing, quality of service, security, etc.
There are some recent papers focusing on the implementation of IPv6 protocol stacks on various hardware platforms.Thomas et al. in [17] demonstrate an intelligent container testbed in which CoAP is implemented on the embedded operating system TinyOS [18].Moreover, a couple of other implementations of CoAP are also available on the Contiki platform [19]- [21].However, most of these implementations are only for the purpose of connectivity evaluations on different operation platforms and usually assume that a virtual gateway, which is usually a IEEE 802.15.4 USB dongle connected to a personal computer (PC), is mounted as a root node to collect upstream packets from leaf nodes.
Different to the above works, our contribution in this paper is that we consider both IPv6 protocol implementation on sensor devices as well as an integrated gateway solution to allow any normal Internet device (e.g., PC and smart phone) to access an IPv6 sensor device.Specifically, we integrate real-world things into the existing web by turning real objects into RESTful resources that can be retrieved directly using HTTP.

A RESTful Protocol Stack for WSN
We employ the IPv6 based protocol stack for WSNs.Some protocols within this stack, which have been developed for resource constrained networks, are introduced as follows.

6LoWPAN
From the very beginning, IPv6 has been selected by IETF as the only choice to support wireless communications in IoT.Its key features such as universality, extensibility and stability, etc., have been designed to overcome many known problems in the existing version of IP, i.e., IP version 4, and therefore IPv6 is expected to be widely adopted for the future Internet.To develop a standard that enables IP connectivity in resource constrained WSNs, the 6LoWPAN working group [22]  ) is smaller than this value, the data link layer must fragment and reassemble data packets.In order to address these issues, 6LoWPAN incorporates an adaptation layer right above the data link layer to fragment large IPv6 packets into small pieces required by the under layer and reassemble them at the receiving end.Moreover, 6LoWPAN specifies stateless compression methods for IP header in order to reduce the overhead of IPv6.The position of 6LoWPAN in the IPv6 protocol stack is shown in Figure 1.
Note that the fundamental purpose of header compression methods is to remove the redundant information from the header by using compression encoding schemes.Although the IPv6 header takes 40 Bytes, most of information bits can be compressed in the link layer.The compression methods for each field of IPv6 header are as follows: 1. Version (4 bits): The value is 6.It can be omitted in the IPv6 network.In order to implement the stateless compression on IPv6 header, the 6LoWPAN working group has specified two compression algorithms: LOWPAN_HC1 (RFC4944) [24] and LOWPAN_IPHC (RFC6282) [25].HC1 algorithm is applicable to networks using link-local addresses.The prefix of a node's IPv6 address is fixed as FE80::/10 and IDD can be obtained via the MAC address.Since this algorithm cannot efficiently compress global/routable addresses or broadcast addresses, it cannot be used to connect a 6LoWPAN with the Internet.LOWPAN_IPHC, however, is proposed to improve the efficiency of compressing routable addresses.
Both LOWPAN_HC1 and LOWPAN_IPHC define an 8-bit dispatch field after the MAC header.Its possible values as shown in Table I determine the specific format of the type-specific header and algorithm.For example, if the first 8 bits is 01000010, the following filed is the header corresponding to the LOWPAN_HC1 algorithm; if the first 3 bits is 011, the following field is the header corresponding to the LOWPAN_IPHC algorithm.The dispatch field is immediately followed by the type-specific header, which consists of some indicating bits.The indicating bits indicate specific compression schemes for IPv6.Readers can refer to RFC4944 for more details.
In addition to stateless IPv6 header compression, 6LoWPAN also includes other relevant standards including schemes supporting mesh routing, simplified IPv6 neighbour discovery protocol, use cases and routing requirements.In summary, the 6LoWPAN working group provides the fundamental of IETF on IoT communications.

RPL
IETF Routing over Lossy and Low-power Networks working group (RoLL) was established in February 2008.It focuses on routing protocol design and is committed to standardize the IPv6 routing protocol for lossy and low power networks (LLN).Its tasks start with the routing requirements of various application scenarios.So far, the routing requirements of four application scenarios have been standardized, i.e., Home Automation (RFC5826), Industrial Control (RFC5673), Urban Environment (RFC5548) and Building Automation (RFC 5867).
In order to develop suitable standards for LLN, RoLL first provides an overview of existing routing protocols for wireless sensor networks.The literature [26] analyzes the characteristics and shortcomings of the relevant standards and then discusses the quantitative metrics for constructing routing in the routing protocol.RFC6551 [27] introduces two kinds of quantitative metric: node metrics including node state, node energy and hop count, and link metrics including throughput, latency, link reliability, expected transmission count (ETC) and link colour object.In order to assist dynamic routing, nodes can incorporate objective functions to determine the rule for path selection based on the quantitative metrics.
Based on the results of routing requirements and quantitative static link metrics, RoLL has developed a routing protocol for LLN (RPL) as specified in RFC6550 [28].RPL supports three kinds of traffic flows including point-to-point (between devices inside the LLN), pointto-multipoint (from a central control point to a subset of devices inside the LLN) and multipoint-to-point (from devices inside the LLN towards a central control point).RPL is a distance-vector routing protocol, in which nodes construct a Directed Acyclic Graph (DAG) by exchanging distance vectors.Through broadcasting routing constraints, the DAG root node (i.e., central control point) filters out the nodes that do not meet the constraints and select the optimum paths according to the metrics.

CoAP
CoAP, as specified by the IETF Constrained RESTful Environments working group (CoRE) [9], is a specialized web transfer protocol for resource constrained nodes and networks.CoAP conforms to the REST Strictly speaking, CoAP is not a HTTP compression protocol.On the one hand, CoAP realizes a subset of HTTP functions and is optimized for constrained environments.On the other hand, it offers features such as built-in resource discovery, multicast support and asynchronous message exchanges.
Unlike HTTP, CoAP utilizes a datagram-oriented transport protocol underneath, such as UDP.In order to ensure reliable transmissions over UDP, CoAP introduces a two-layer structure as shown in Figure 2. The messaging sublayer is used to deal with asynchronous interactions using UDP.Specifically, there are 4 kinds of CoAP messages: 1. Confirmable (CON): ACK is needed.

Acknowledgment (ACK): To represent that a
Confirmable message is received.

Reset (RST):
To represent that a Confirmable message is received but can't be processed.
The Request/Response interaction sublayer is used to transmit resource operation requests and the request/response data.As a summary, CoAP has the following features: • Constrained web protocol fulfilling M2M requirements.
• Low header overhead and parsing complexity.
• URI and Content-type support.
• Simple proxy and caching capabilities.
• Built-in resource discovery.• UDP binding with optional reliability supporting unicast and multicast requests.
• A stateless HTTP-CoAP mapping, allowing a proxy to provide access to CoAP resources via HTTP in a uniform way and vice versa.

HTTP-CoAP protocol implementation
Applying REST-style network structure in WSN can largely facilitate connection between WSN and the Internet.By applying CoAP protocol on wireless sensors devices, Internet services can access WSNs as resources directly or via gateway as a proxy.Basically, there are two methods to enable remote access from an Internet client to a sensor device.
Direct access.Direct access means that the an Internet user accesses a WSN through a gateway that only implements protocol conversions between the IPv6 network layer and 6LoWPAN, but does not process the upper layers protocols (e.g., CoAP).As an example shown in Figure 3 (a), a sensor node in WSN can be accessed through an IPv6 address and the gateway only needs to implement conversion between IPv6 and 6LoWPAN, which significantly reduces the processing overhead.
Proxy access.Proxy access means that an Internet user accesses a WSN through a proxy that can convert an incompatible data format from outside networks into a WSN compatible data format.For example, in our case, the proxy can have functions of protocol conversion from a HTTP request to a CoAP request, and vice versa, payload conversion and blockwise segmentation of large data packets (e.g., those representing an image), etc.

Figure 4. System Architecture
The advantage of this method is that current Internet services can easily access WSN resources without any changes, because of the existence of the proxy gateway.Moreover, since low power sensor nodes cannot support TCP efficiently, the proxy mechanism can buffer and process the requests to avoid TCP time out.However, the protocol conversion increases the complexity of the gateway and thereafter affects communication efficiency.Figure 3 (b) illustrates the protocol conversion between HTTP and CoAP via a gateway.

Prototype Implementation
In this section, we present our prototype to illustrate the implementation of the RESTful access methods to IPv6 wireless sensor devices, considered as the representative of future embedded devices in IoT.A RESTful gateway supports both IEEE 802.11Wi-Fi and IEEE 802.15.4 interfaces for communications.The web resources in sensor devices are accessible through the RESTful APIs.The system architecture is shown in Figure 4, where a PC acts as a client to retrieve sensor resources via the RESTful gateway.

Sensor node
We deploy wireless sensor devices to monitor air temperature and humidity, detect movements and take photos.All these sensors are equipped with the same ATmega1284P MCU and AT86RF231 radio transceiver to support 250kbps data transmissions at 2.4GHz using the IEEE 802.15.4 protocol.To support IPv6 connectivity, all the sensor devices run the Contiki v2.6 operating system and incorporate 6LowPAN, IPv6 and RPL protocols on top of IEEE 802.15.4.The web  II.

RESTfull Gateway
To ease access from Internet applications to sensor resources, especially for those Internet users without CoAP support, we integrate IEEE 802.15.4 connectivity into an open-platform gateway and port the HTTP-CoAP proxy implementation to the OpenWrt, the operation system of the gateway, to realize remote access from an ordinary IP terminal to an IPv6 sensor device.Figure 6 gives the hardware architecture of the RESTful gateway, which technical specifications are provided in Table III.
The HTTP-CoAP (HC) proxy provides translation and mapping between HTTP and CoAP protocol.CoAP can be directly mapped to HTTP, because CoAP actually implements a subset of HTTP functions.The mapping is performed only at the Request/Response interaction sublayer of the CoAP protocol and is invisible to the   Note that compared to CoAP-to-HTTP mapping, HTTPto-CoAP mapping is more complex since it is necessary to determine whether to ignore the content or report an error by checking unsupported HTTP request methods, response codes, content-types and options.In our prototype gateway, the HC proxy is implemented based on libcoap [29] which is an open-source C-Implementation of CoAP and conforms to GPL v2 or higher licenses.
The interaction process of the HC proxy is shown in Figure 7. Specifically, for each of the HC proxy layers, we have the following implementations:

Performance Evaluations
In this section, we provide evaluation results of the prototype system.Especially, we experimentally evaluate the performance over the prototype system at two layers: the routing layer where the round trip times (RTTs) and packet loss rates of multi-hop transmissions in the WSN are measured and the application layer where web resources of sensor devices are retrieved using RESTful methods.

System configuration
Our prototype system is composed of three different sensor devices, one HC proxy gateway and one PC for the tests.In order to ease the setup of WSN in a multihop fashion, we manually assign IPv6 addresses for the sensor devices as follows: sensor and humidity&temperature sensor are directly connected to the gateway over single hops, and the approach detecting sensor is the leaf node of the humidity&temperature sensor and it is two hops away from the gateway.Figure 8 provides the network topology of the prototype system.

RTTs and Packet loss evaluations of RPL routing
Wireless sensor networks should be capable of forming multi-hop transmissions among peer sensor devices.In this evaluation, the RTTs and packet loss rate in a single-hop and multi-hop scenarios using RPL routing are measured.After setting up of the system, we use the simple ping commands to evaluate the RTTs from the PC client to the humidity&temperature sensor and approach detecting sensor, respectively.The payload size for each transmission packet is 32 bytes and the RTTs results are averaged over 100 measurements.Figure 9 (a) shows the routing table via secure shell client.As can be seen from Figure 9 (b), for onehop transmissions, the average RTTs is 24ms.When the routing extends to two hops, the results as shown in Figure 9 (c) are degraded to 43ms average RTTs.
To further evaluate the performance of a large scale network, we set up another test to evaluate the packet loss rate in a multi-hop environment.The test is carried out in an open office area with strong Wi-Fi background noise and lowest possible WSN radio frequency output power to ensure a multi-hop fashion, which makes a sensor device can only communicate to each other within around 30 cm.
A maximum number of 6 hops can be obtained by optimizing communication system.To retrieve the onboard resources via GET request (i.e., < /.well-known/core >) over the same number of measurements, Table 4 shows the packet loss rate in a multihop scenario.We can observe that the packet loss rate increases dramatically with an increasing number of hops, because of severe environmental interference and channel congestions, etc.Moreover, additional configurations to ensure a multi-hop transmission, such as one way communication, low output power and RPL settings, also contribute to the high loss.

RESTful method to retrieve sensor resources
To illustrate IoT applications, we initiate a trial to 'GET' an image from the camera sensor device.Specifically, we use both proxy access and direct access methods to retrieve the sensor data via the gateway.Figure 10

Conclusion
We have implemented the 6LowPAN/IPv6/RPL/CoAP protocol stack on an IEEE 802.15.4 radio platform to enable wireless sensor communications.Furthermore, by integrating IEEE 802.15.4 connectivity and HTTP-CoAP proxy into an open-platform gateway, we have realized remote access from any IP node to IPv6 sensor devices.We have presented performance evaluations, which have shown that the IP based solution is promising to drive IoT development.In the future work, we plan to design a more robust and reliable IP solution for IoT.Especially, how to deploy large scale networks with decent performance is a critical issue and we need to continue to optimize both hardware and software implementations.Moreover, other issues, such as device management and control of sensor devices, can also be explored via RESTful methods.

Figure 5 .
Figure 5.A snapshot of sensor platform

Figure 7 .
Figure 7. Interaction process of HC proxy libcoap layer.libcoap implements the CoAP messaging sublayer based on UDP.It defines CoAP message structure and methods to operate CoAP messages.

3 4BOOL
coap_proxy_handler (SOCKET loca lwebuser , char * s z L i n e B u f f e r , i n t n L i n e B u f f e r ) (a) shows the proxy access result by sending a HTTP GET request along with the URI http://[2001:2::19]/camera.The HC proxy then converts the HTTP request to CoAP request and forwards the request to the camera sensor.As a comparison, Figure 10 (b) shows the direct access result by sending a CoAP request coap://[2001:2::19]:5683/camera directly from the CoAP browser [30] on the PC.Since the picture takes about 27 kBytes, which exceeds the payload size defined by the CoAP client, the CoAP protocol adopts the blockwise transfer by dividing the response into 64-Byte blocks in such a way that the web server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers.In summary, both methods show an acceptable performance.

Figure 10 .
Figure 10.HTTP vs. CoAP methods was established to work on protocol optimization of IPv6 over networks built on top of IEEE 802.15.4 [23].Specifically, the 6LoWPAN protocol considers how to integrate IPv6 with the medium access control (MAC) and physical (PHY) layers of IEEE 802.15.4.In fact, there are two key challenges to run IPv6 over the IEEE 802.15.4 network.On the one hand, The position of 6LoWPAN in the IPv6 protocol stack the maximum frame size supported by IEEE 802.15.4 is only 127 Bytes.Considering that significant header overheads are occupied by layered protocols (e.g.
, MAC layer header, IPv6 header, security header and transmission layer), the payload size available for the application layer is very limited.On the other hand, since the minimum value of maximum transmission unit (MTU) specified by IPv6 is 1280 Bytes (RFC 2460), if MTU supported by the under layer (i.e., IEEE 802.15.4

Table 2 .
Technical specifications of sensor device Figure 6.Hardware architecture of gateway

Table 3 .
Technical specifications of gateway Response layer implements the function of the Request/Response interaction sublayer in Figure 2 by encapsulating the data structure and methods relevant to CoAP Requests and Responses.It is responsible to transmit CoAP requests in the form of CoAP messages through the messaging sublayer and generate CoAP response based on received CoAP messages.Because CoAP messaging sublayer adopts unreliable UDP, certain issues need to be solved in order to implement a reliable transmission, including CoAP message acknowledgement, message retransmission for timeout, message process, asynchronous message process and segmented message process, etc.The following code header is provided to illustrate the implementation of CoAP Request/Response.
We deploy the prototype system in an open office area.The HC proxy gateway and sensor devices are connected wirelessly via IEEE 802.15.4 over channel 26.The PC client is connected to the gateway through the Wi-Fi link.The network topology is built with a maximum number of 2 hops, where the camera Surfing the Internet-of-Things: Lightweight Access and Control of Wireless Sensor Networks Using Industrial Low Power Protocols Figure 8. Network topology of prototype system Figure 9. Routing table and RTTs evaluations

Table 4 .
Packet loss rate in a multiple-hop network Hop 2 Hop 3 Hop 4 Hop 5 Hop 6