Integrating Custom Hardware into Sensor Web

6 downloads 11718 Views 313KB Size Report
a system architecture in which IP enabled custom hardware nodes running Constrained Application Protocol (CoAP) can be plugged into the sensor web.
Integrating Custom Hardware into Sensor Web Maria Porcius1, Carolina Fortuna2, Gorazd Kandus2, Mihael Mohorcic2 1

Jozef Stefan International Postgraduate School 2 Jozef Stefan Institute Jamova 39, 1000 Ljubljana, Slovenia [email protected]

Abstract: In this work, we considered the challenge of integrating custom hardware into the Sensor Web. We propose a system architecture in which IP enabled custom hardware nodes running Constrained Application Protocol (CoAP) can be plugged into the sensor web. We analyze the main components of the system: our custom hardware nodes, the IP protocol stack implementations and CoAP, a lightweight HTTP - like protocol defined for embedded devices that leverages web integration. We show on an empty parking space detection case study how our custom hardware nodes called Versatile Sensor Node (VSN), runing Contiki and CoAP protocol integrate into the web allowing the provision of advanced navigation services.

1.

INTRODUCTION

Wireless Sensor Networks (WSNs) technology became sufficiently mature to make the first steps into our daily activities while at the same time remaining an important research area requiring further improvements and extensions that would significantly impact society. One of the areas receiving particular attention is the integration of sensors into the Sensor Web [1]. This calls for departing from traditionally application specific and isolated islands of WSNs to remotely accessible data on various sensor nodes ideally using the IP protocol stack. Furthermore, sensor web should enable connecting any type of sensor node, including custom made ones, which is hard to achieve with current WSNs. Web services and web applications are widely used and seem to be able to open some revolutionary application areas for sensor networks. We would like to benefit from these advantages and connect our custom sensor nodes called Versatile Sensor Nodes (VSN) to the sensor web. The protocols that are used in the current web to provide data transfer (such as HTTP, TCP, SOAP, etc) do not address the requirements of limited resources devices like sensor nodes. Therefore, a new solution is required to ensure web integration. In this sense, Constrained Application Protocol (CoAP) [2] has been recently defined and it is meant to enable communication over the web for constrained nodes and networks (such as 6LoWPANs). Several IP-based protocol stack implementations proved that IP can be adapted for the use on limited resource devices such as sensor nodes. Different standards have been defined to ensure connectivity for such constrained devices, and

6LoWPAN [3], which uses an IP-based approach, is one of them. Several implementations of protocol stacks are currently available, some of which were built to run with a specific embedded operating systems. For instance, Contiki [4] supports lwIP, Rime, µIP and µIPv6 [5],[6],[7]. Sensor nodes, including our custom VSN, have several constraints referring to the microcontroller, memory, wired and/or wireless modules, interfaces and power sources [12]. To integrate such nodes into the sensor web, developers need to provide drivers, protocol stack implementations and possibly operating systems (OSs) that can achieve the final goal given the specific constraints. There is limited work on integrating sensor nodes into sensor web, especially when it comes to discussing several aspects of such integration. Partial solutions have been proposed considering the (1) hardware aspects such as design of nodes with limited resources, (2) wireless networks of such constraint devices or, more recently the (3) upper layer12 solutions addressing the challenge of developing applications based on sensor web. Some proposals regarding the use of web services in the same format they are used today in Internet, for WSNs, are Open Sensor Web Architecture (OSWA) [8], Smews [9], or Device Profile for Web Services [10]. OSWA is an implementation of the Sensor Web Enablement (SWE), which specifies interfaces for discovering, accessing and obtaining sensor data and also sensor-processing services. Unlike majority of other middlewares, which are implemented on top of an OS, OSWA goes down to the OS level. It was tested with support from TinyDB, SunSPOTs running Java, TinyOS on Mica2, MicaZ and Imote2, and Linux on NICTOR sensors. In [11] authors proposed an architecture based on well-known standards such as data dissemination protocols and web services in the format specified by Service Oriented Architecture (SOA) (i.e. HTTP, SOAP, WSDL, XML, etc). Conversely, we are covering all the aspects involved in the vertical system: the VSN node as custom hardware, compatible protocols and stacks implementations to ensure connectivity and an application protocol to provide web integration. Therefore, our contribution in this paper consists of the analysis and illustration on a case study of how custom hardware, in this case our VSN nodes, can be integrated into 1 2

Sensorpedia, http://www.sensorpedia.com/ Pachube http://www.pachube.com/

the sensor web for creating innovative services such as autonomous navigation systems. The rest of the paper is structured as follows. In Section 2 we describe the VSN features. Then, in Section 3 we discuss IP approach for WSNs. Next, in Section 4 we present the sensor web and the integration of VSN into it. Section 5 illustrates the integration of VSN into sensor web using CoAP protocol in one case study. Conclusions are drawn in Section 6. 2. SENSOR NODES: VERSATILE SENSOR NODE VSN is a modular node with the core board hosting a powerful ARM Cortex-M3 32-bit microcontroller running up to 72 MHz, 512 kb of Flash, 64kb of RAM and several interfaces (such as RTC, I2C, UART, SPI, 1 Msmp AD, 2 DA, USB). VSN supports radio modules operating in 300 MHz, 868 MHz and 2.4 GHz ISM frequency bands, several communication modules (ZigBee, Bluetooth, 2G, 3G, Eternet, 6LoWPAN), a large set of sensors (temperature, humidity, color, pH, ORP, ultrasonic transmitter and receiver, speaker, microphone, camera, GPS, luminance, etc) and onboard 3 axis accelerometer. It has also an eXpansion connector ready to drive LCDs with touch panel, stepper and three phase BLDC, PMSM, etc. We identify two main constraints for integrating VSN into the Sensor Web: (1) support for IP and (2) integration with existing web service protocols. Our solution uses a 6LoWPAN protocol stack available in Contiki and CoAP running on top of this. Contiki [4] is an OS designed for limited resources devices using a non-preemptive event driven model with support for dynamic loading of applications and services. The latter feature has the advantage of reducing the power consumption and the time needed for loading. Contiki had to be adapted for the VSN board in order to be compatible with its hardware characteristics. Contiki implements communication as a service, thus permitting replacement at runtime. This was a desired feature for our node as it allows simultaneously loading of multiple communication stacks and runtime replacement of parts of the stack. It supports several protocol stack implementations, such as lwIP, μIP and μIPv6 [5],[6],[7], the last one allowing integration of VSN into 6LoWPAN networks. In addition, VSN can benefit from the services provided by Rime [7], a sensor network communication stack included in Contiki’s system core. 3. IP-BASED SENSOR NETWORKS 3.1 IP-based communication standards In the past few years, a lot of effort and resources have been invested in developing standards and technologies for

WSNs. With the increasing number of IP-enabled devices, the Internet Engineering Task Force (IETF) standardized a new technology, 6LoWPAN [3]. One additional feature of 6LoWPAN compared to other wireless embedded radio technologies is the support for multicast addressing. The 6LoWPAN protocol stack can be mapped onto TCP/IP model. For the Physical and MAC layers, it uses IEEE 802.15.4 standard. At the Network Layer, it supports only IPv6. For IPv6, the minimum transmission size is 1280 bytes, but 802.15.4 supports only 128-bytes frame size. Therefore, 6LoWPAN defines a new layer between Data Link and Network Layer called Adaptation Layer, which has the role to transport IPv6 packets over 802.15.4 links. For this it uses fragmentation and compression of data packets. Compression is performed for both IPv6 headers (from 40 bytes to 2 bytes) and User Datagram Protocol (UDP) headers (from 8 bytes to 4 bytes) [13]. In most cases this Adaptation Layer is implemented together with IPv6 on the Network layer. The topology defined for 6LoWPAN networks is mesh. For the Transport layer, UDP protocol is mostly used. Transmission Control Protocol (TCP) is not commonly used as it considered to be inefficient for these types of networks (e.g. it cannot identify the cause of a lost packet over a wireless link) [13]. On the Application Layer 6LoWPAN uses already existing protocols such as: Nano Web Service (NanoWS), ZigBee Compact Application Protocol (ZigBee-CAP), Simple Service Location Protocol (SSLP), Simple Network Management Protocol v3 (SNMPv3), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Initiation Protocol (SIP). 3.2 Protocol stack implementations Before being able to use one specific standard for a WSN, implementation of its protocol stack has to be provided. This implementation is usually driven by several constraints, the most important being: – Memory: The stack implementation and user applications have to be efficient in using the available memory. Software developers have to provide a small size protocol stack code. Along with the protocol stack code, nodes with OS have the OS’s additional code. – Operating systems: Nodes usually have an 8 or 16-bit microcontroller and lately also the 32-bit microcontrollers are used. The OS chosen to be installed on one node has to be supported by this underlying microcontroller. – Code portability: The implementation of the protocol stack needs to be portable. Portability across different platforms, along with flexibility, platform independence and programming support can be obtained through

virtual machines (VMs). WSN developers have to deal with concurrency, modular and distributed software on resource-limited devices. This is strongly related to the OS the sensor node is running. VMs aim to solve the issues described above by abstracting the device hardware from an application and allowing the implementation in software of different features without the support of an operating system. IP is the protocol used today within the Internet and also proposed and used to provide communication for several WSN systems. Most of the advantages related to using IP are related to the extensive use and improvement of this technology. Disatvantages come from the fact that it has been built based on a different set of constraints, and also different goals, than those posed by WSNs. These disadvantages were eliminated to some extent by the development of IP stacks for constrained devices. For instance, μIP [5] stack has been released in 2001 and it featured the smallest TCP/IP stack. μIP uses a buttom-up approach, is IPv4 compliant and needs only 6kb ROM for code and 1kb RAM for data, as shown in Table 1. Several other IP based protocol stack implementations that intend to address WSN related challenges have been developed, and some of them are synthesized in Table 1. Similar to μIP, lightweight IP (lwIP) [5] stack is implemented in C programming language, and is IPv4 compliant. But unlike μIP, which offers only the minimal set of features needed for a TCP/IP stack and implements IP, ICMP and TCP protocols (no UDP support), lwIP is more flexible having a modular design that allows extension with additional protocols to those implemented as default, i.e. UDP, TCP, ICMP and IP. Furthermore, these implementations mostly target devices with 8- or 16-bit architectures and usually run Contiki or TinyOS, as these are the most used OSs for WSNs. Table 1 - Protocol stacks implementations Name lwIP μIP μIPv6 NanoStack Matus BLIP

Memory 40kb ROM 20kb RAM 6 kb ROM 1 kb RAM 11.5kb ROM 1.8kb RAM 4-8kB RAM 32-64kB ROM 4kb RAM 4kb RAM

OS With/without OS

Microcontroller 8- and 16-bit

Contiki

8- and 16-bit

Contiki

8-bit

FreeRTOS

16-bit

TinyOS TinyOS

8- bit 8-bit

Internet of Things (IoT) aims to connect billions of devices/”things”, and in doing so it is expected to rely on IP, IPv6 being the best choice for IoT. This allows the connectivity of a very high number of IPv6 devices, providing interoperability within heterogenous sensor

networks and between sensor nodes and Internet hosts. Table 1 shows few IPv6 based stack implementations. The smallest one is μIPv6 [6], released in 2008 as an IPv6 extension of μIP for constrained devices like sensor nodes and actuators. It requires only 11.5 kb ROM and 1.8 kb RAM. It is included in Contiki, although it can work even without an OS, supports both TCP and UDP transport protocol implementations and provides methods for reducing power consumption. There are also small implementations for TinyOS (i.e. Matus and BLIP) and for FreeRTOS (i.e. NanoStack) [6]. 4. SENSOR WEB 4.1 Web services and sensor web architecture Web services allow communication between disparate systems that can have different implementations and providers. They are becoming more and more popular in developing applications [14]. However, the way the web and web services are developed at the moment (i.e. based on TCP, HTTP, SOAP etc) makes it hard to be used with sensor nodes or other constrained devices. For instance, HTTP is synchronous, meaning that when a client makes a request, it will block subsequent transfers until it gets a response. In the context of WSNs, this approach is not the most appropriate. For example, some nodes might just want to send a message without waiting for a response (for instance a sensor node wants to sends its measurements and then to continue its task without waiting for any response or validation from the destination node). Also, HTTP keep-alive option can be hard to handle in limited memory devices as it is a stateful property which requires ability of simultaneous connections management. Therefore, a new solution more appropriate for WSNs is needed and this is the reason why IETF Constrained RESTful Environments (CoRE) working group was initiated. Their goal is to provide a RESTful based design for constrained networks and nodes [2]. Their target applications are those that deal with manipulation of simple resources on constrained networks and include smart energy, building automation and machine-to-machine applications. Representational Transfer State (REST) is the architecture used today within the Web and is based on three concepts: – Representation – each response message sent to a request is the representation (for instance xml, html, etc) of the requested resource. – State – each application is at one moment in one state. – Transfer – movement of an application from one state to another. Thus, REST defines the way an application should be build and how it should work, i.e. how the resources are represented and what are the states and states transitions for an application.

CoRE intends to extend this concept forr more constrained environments by defining a Constrained Appplication Protocol (CoAP) [2] that takes into account thee requirements of integrating small and limited devices with the t embedded web. CoAP is an application protocol, but unllike HTTP, which relies on TCP (is not limited to this protocol, but this it is how is used within the Internet today), CoAP supposes UDP for the transport layer. We will illustraate CoAP in next section, considering its features in the conteext of VSN.

sent for the desired informationn and the response contains the IDs and GPS coordinates of thhe empty parking places. We consider that the parking placess are represented as a matrix or have identification numbers, so the users can identify them fast and choose one for parkinng. The device that the user is using does not have to use CoA AP or the same protocols as the VSN nodes. It can use any otheer communication standard and protocols stack, which is ablee to ensure connection to the Internet and supports HTTP.

4.2 VSN integration into sensor web In order to provide communication oveer the Internet and integration into sensor web, we considerr CoAP [2] as the application protocol for the VSN nodes. A possible network design is shown in Figure 1. Each node runns a CoAP client in order to exchange messages with other nodes running a CoAP client, with CoAP servers inside thee network or in the Internet, or with a Proxy. This proxy is sim milar to a gateway and provides (besides routing and other specific s functions) one of the most important features of CoA AP, i.e. translation of CoAP to HTTP. Figure 1- CoRE Architectuure –Parking area use case 5. CASE STUDY ANALYS SIS As instance of the vertical system architeecture, we consider a case study based on an empty parkinng place detection system. We analyze and discuss requirrements for using CoAP for integration of VSN into sensor web. w The network is composed of VSN noddes equipped with presence detection sensors, running Contikki, an IPv6 protocol stack and CoAP at the application layer. CoAP C provides web integration and communication over the Internet I through a proxy that maps to HTTP – see Figure 1. 1 In order for the proxy to provide an easier translation too HTTP, CoAP is based on GET, POST, PUT and DELETE RESTful methods, which support request/reply interaction moodel, accomplished with request and response message types. Thus, a node can use GET for obtaining desired resource; POST to add a new resource; PUT to update an existing resoource (or possible adding for a nonexistent one); and DEL LETE to remove a resource. The nodes are performing periodic measurements m and whenever a node detects a car parked on the corresponding place, it sends a PUT message to a server on o the Internet that stores this information. The message is seent to the proxy in the CoAP format and the proxy converts it i to the HTTP and sends it forward. We assume that the daata is stored on a server outside the VSN network, but the server can be also TTP translation is local and in this case, no proxy or HT needed. An agent (i.e. human driver or car navigation n system) can thus check on the web (in real time, e.g. e through a web service) if there are empty parking spacces and on which position. For this, a web service is used - a GET message is

Due to the fact that CoAP is based on UDP [2], only the stacks that offer UDP support can c be used, for instance μIPv6 (or μIP when using IPv4). UD DP provides an asynchronous communication for a VSN CooAP client, meaning that the sensor node will not block until u getting a response when making a request. CoAP adddresses the “session” concept defined for TCP with a Transaaction ID value. Each message sent by the VSN node containss a unique integer value set by the source that has to match witth the one in the corresponding response. Therefore, it has too be changed for each new request and not be changed foor retransmission. The default port is considered to be 616116 [2], which is included in compressed UDP port space annd supports high compression of the message. In addition to the request/rreply model described above, CoAP defines a new asynchronnous interaction model between end-points, called subscribe/nootify model. A new message type is introduced, i.e. notify, which w is sent by a server to a client when a resource has beeen changed [2]. In order to receive notifications from otherr end-points, a CoAP client has to previously subscribe, using SUBSCRIBE S method. An agent can subscribe to receive notificaations when a particular or any parking place becomes free. The T notification is sent in the form of a NOTIFY-type message m about the requested resource. To provide reliabiliity, retransmission has to be performed only in case of unicaast communication and not for multicast, as this could cause overhead (consider the case when a notify message is sent to t a group of nodes more than once just because one of the noddes has not received it). As we mentioned by now, three types of messages are defined within CoAP: request, notify and response. Although

each of them has some specific format, they all have the same CoAP header, as specified in [2]. There are many applications in which revealing the resources that a sensor node manipulates is very important, especially considering the fact that WSNs are expected to work for a long time without or with minimal human interaction. CoAP refers to this as Resource Discovery [2][2] and each node has to support it either for requesting resources available at another CoAP end-point or for sending notifications about its own resources. Another important feature of CoAP is the support for caching, which has the role of optimizing bandwidth and consumed power on such constrained devices like sensor nodes. It can be performed at both client and proxy level [2]. On the one hand, a CoAP client has to be able to cache a resource representation for a lifetime value specified in the header, and it can use this representation until the lifetime expires. When this happens, cache refresh can be performed through a GET request. On the other hand, the proxy should be able to perform caching not only of resources, but also of subscriptions. In this way, the proxy could deal also with the sleeping nodes and avoid traffic overload. For example, consider two VSN CoAP clients that subscribed to receive notifications when an event occurred. Meanwhile, they are programmed to periodically go to sleep. If notifications are sent to them while they are in the sleep mode, the proxy should cache these messages and forward them when the nodes wake up. 6. CONCLUSIONS We considered in this paper the challenge of integrating custom hardware into sensor web and we analyzed the components of the proposed vertical system architecture. We used in this sense wireless sensor networks built with versatile sensor node, a custom made platform that runs Contiki and supports different communication stacks. We showed how it can be integrated into the sensor web using CoAP at the application layer. CoAP is built on top of IP based protocol stacks and is much simpler than the existing application protocols while addressing the requirements of limited resource devices such as sensor nodes. We showed on one case study that CoAP is a reliable solution for web integration of constrained nodes and networks.

REFERENCES [1] Kevin A. Delin, Shannon P. Jackson: “The Sensor Web: A new Instrument Concept”, SPIE‘s Symposium on Integrated Optics, 20-26 January 2001, San Jose, CA [2] Zach Shelby, Brian Frank, Don Sturek: “Constrained Application Protocol (CoAP) draft-shelby-core-coap-01”, Online at http://tools.ietf.org/html/draft-shelby-core-coap-01

[3] Zach Shelby and Carsten Bormann, “6LoWPAN: The Wireless Embedded Internet”, John Wiley and Sons Publishing Company, 1st ed., 2009. [4] Adam Dunkels, Bjorn Gronvall, Thiemo Voigt: “Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors”, IEEE Emnets-I, 2004 [5] Adam Dunkels: “Full TCP/IP for 8-bit architectures”, MobiSys‘03, 2003. [6] Yannis Mazzer, Bernard Tourancheau: "Comparisons of 6LoWPAN Implementations on Wireless Sensor Networks," Third International Conference on Sensor Technologies and Applications, 2009, pp. 4-7. [7] Adam Dunkels: “Rime – A Lightweight Layered Communication Stack for Sensor Networks”, EWSN, 2007, The Netherlands [8] Xingchen Chu, Tom Kobialka, Bohdan Durnota, Rajkumar Buyya: “Open Sensor Web Architecture: Core Services”, Proceedings of the 4th ICISIP, 2006, Bangalore, India. [9] Simon Duquennoy, Gilles Grimaud, Jean-Jacques Vandewalle: “Smews: Smart and Mobile Embedded Web Server”, CISIS 2009 [10] Elmar Zeeb, Andreas Bobek, Hendrik Bohn and Frank Golatowski: “Service-Oriented Architectures for Embedded Systems Using Devices Profile for Web Services”, AINAW 2007 [11] Flavia Coimbra Delicato, Paulo F. Pires, Luci Pirmez, Luiz Fernando Rust da Costa Carmo: “A Flexible Web Service based Architecture for Wireless Sensor Networks”, ICDCSW, 2003 [12] Jennifer Yick, Biswanath Mukherjee, Dipak Ghosal: "Wireless sensor network survey", Computer Networks, vol. 52, 2008, pp. 2292-2330. [13] Matus Harvan and Jurgen Schönwälder, “A 6lowpan Implementation for TinyOS 2.0”. [14] Jean-Philippe Vasseur, Adam Dunkels: “Interconnecting Smart Objects with IP: The Next Internet”, Morgan Kaufmann Publishing Company, 1st ed., 2010