IT 12 053
Examensarbete 30 hp Oktober 2012
Service Discovery for IP-based Wireless Sensor Networks
Martin Russo
Teknisk- naturvetenskaplig fakultet UTH-enheten
Besöksadress:
Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0
Postadress:
Box 536 751 21 Uppsala
Telefon:
018 – 471 30 03
Telefax:
018 – 471 30 00
Hemsida:
http://www.teknat.uu.se/student
Abstract
Service Discovery for IP-based Wireless Sensor Networks
Martin Russo
In a Wireless Sensor Network (WSN), the services that each sensor node can provide must be described according to a standard and possible to discover by other devices.
Protocols such as the well established UPnP (Universal Plug and Play) aim at facilitating the advertisement and discovery of network services and already exist in many computer networks. We suggest to use UPnP for WSNs.
Designing protocols for WSNs, engineers often face battery, memory and
computation constraints, which impose proper evaluations to be conducted and when necessary, reasonable trade-offs to be adopted.
The goal of this thesis project is to allow the sensor nodes to announce, discover and use services with UPnP and study the efficiency of the solutions put in place in the context of low-power embedded networks.
Finally, optimizations to the protocol are proposed to render it more lightweight.
Among other results, the power consumption of the radio and the latency of Service Discovery are reduced by 20% and over 60% respectively.
Acknowledgements
I would like to thank my supervisor, Joakim Eriksson, for helping me define the thesis and providing constant support while the project was carried out.
I also want to thank my reviewer, Thiemo Voigt, whose worthy comments allowed me to improve the report.
I am also very grateful to everyone else at SICS (Swedish Institute of Computer Sci- ence) who has provided me with advices when dealing with the project’s challenges.
Finally, an acknowledgement goes to Yanzi Networks, who provided the first UPnP source code that was later developed in this project.
Contents
1 Introduction 1
1.1 Wireless sensor networks . . . 1
1.2 Service discovery . . . 2
1.3 Approach . . . 2
1.4 Results . . . 3
1.5 Document structure . . . 3
2 Background 4 2.1 Contiki and protocol stack . . . 4
2.2 Cooja: a wireless sensor network simulator . . . 6
2.3 Hardware platforms for Contiki . . . 7
2.3.1 Tmote Sky . . . 7
2.3.2 Wismote . . . 8
2.4 Service Discovery . . . 8
2.4.1 UPnP . . . 8
2.4.2 mDNS . . . 11
2.5 Related work . . . 11
2.5.1 Service Discovery in Wireless Sensor Networks . . . 11
2.5.2 CoAP . . . 12
3 Design and implementation 13 3.1 System architecture . . . 13
3.2 Implementation . . . 16
3.2.1 UPnP in Contiki . . . 16
3.2.2 Development toolchain and UPnP IPv6 client . . . 16
4 Evaluation 21 4.1 Experiments on hardware platforms . . . 21
4.2 Energy consumption and latency evaluation . . . 21
4.3 Optimizations to UPnP in Contiki . . . 23
4.4 Discussion . . . 25
List of Figures
2.1 Contiki protocol stack . . . 5
2.2 Cooja Simulator . . . 7
2.3 Tmote Sky . . . 8
2.4 Wismote . . . 8
3.1 UPnP in the protocol stack . . . 14
3.2 System architecture . . . 15
3.3 UPnP transaction diagram . . . 17
3.4 Simulation architecture . . . 19
3.5 UPnP IPv6 client . . . 20
4.1 Experiment setup . . . 22
4.2 Impact of radio duty-cycling on latency . . . 24
4.3 Duty-cycle comparison . . . 26
4.4 Average latency of one update message comparison . . . 27
4.5 Latency reduction with Service Caching . . . 28
1 Poster for SICS Open House on 26 April, 2012 . . . 34
Chapter 1
Introduction
In this chapter some general concepts regarding the technologies involved in the project and its motivations are introduced.
The problem of service discovery in wireless sensor network is formulated, followed by the approach to solve it.
1.1 Wireless sensor networks
A Wireless Sensor Network (WSN) is a set of autonomous nodes distributed across a area and configured to form a network. Each node of the network, commonly referred as sensor node, is normally a tiny embedded device which typically consists of several components: a microcontroller, a radio transceiver, sensors (and possibly actuators) and a battery supply.
Each node has the ability to sense the environment and send (either directly or through other nodes) the data to a sink node which will store the sensed information, which can easily be retrieved or even made accessible from the Internet. The software embedded in the nodes is a small operating system whose main tasks are implementing the net- work protocols stack, interfacing to the sensors and regulating the low power modes.
Nowadays WSNs are already a well-known solution in applications areas which in- clude environmental monitoring, military surveillance, medical care, smart grid, struc- tural monitoring, the Internet of things and so forth [1].
In environmental monitoring, the sensors can measures physical quantities like light, motion, temperature, humidity, sound etc., collect this information and send it to a sink, which might send a notification over the Internet in case some values go beyond a cer- tain threshold [2].
Sensor networks are used in medical care as well to monitor patients’ health [3]. Pa- tients wear sensors that measure e.g. blood pressure, blood oxygen, saturation heart rate, and this information can be displayed on medical machineries as well as on nurses
Internet. These devices will be able to communicate the information they sense from the physical world and retrieve useful data from the Internet as well. Human users of the Internet are predicted to be a small minority in a few years [4].
In general, sensor nodes might be equipped with any kind of sensor depending on the application: mechanical, thermal, biological, chemical, optical, and magnetic sensors are only some examples. Regardless of their hardware, the protocols through which they communicate are lightweight implementations of the ones used in general pur- pose computer networks, such as the protocols of the TCP/IP stack.
Since a WSN might consist in dozens (or even hundreds and upwards) of battery oper- ated sensor nodes, possibly deployed in remote or inconvenient environments, chang- ing run-down batteries is often impractical or economically infeasible. It is therefore crucial to find mechanisms to reduce power consumption and prolong the network’s battery life time. It is well known that the most energy consuming component is the radio, with its listening, transmitting and receiving operations. The radio must be there- fore turned off for most of the time, and only periodically turned on to transmit data or to detect transmission attempts by other nodes. This mechanism is called radio duty-cycling, and has been the focus of attentive research aimed at minimizing energy consumption while still keeping acceptable levels of communication capability in the network. In some cases, the nodes may also rely on solar cells to harvest energy from the environment [5].
1.2 Service discovery
Given a WSN, in order to find out what services are provided by the nodes, a protocol is needed to define how the communication for discovery and usage has to take place.
The two main categories of service we can identify in WSNs are reading sensors’ val- ues or controlling an actuator. The aim of service discovery protocols is to facilitate the detection and the announcement of network services within a local network.
SD discovery protocols can be firstly categorized as centralized and distributed [6].
Centralized protocols rely on the presence of one entity in the network (normally a server) where the nodes register their services and the clients search for them.
In distributed protocols, each node is assumed to be responsible for conveying its own capabilities upon every client’s query, thus the communication between service provider and user occurs in a peer-to-peer fashion. Examples of distributed service discovery protocols are UPnP, used by millions of local network devices as well as TV-sets and mDNS-SD, which is primarily used by Apple’s Bonjour.
1.3 Approach
Given the presence of little or no infrastructure in a typical WSN, we decided to opt for a distributed SD protocol like UPnP.
The UPnP standard defines functionalities such as service discovery, control, event no-
tification etc. that are typically utilized in Local Area Networks in order for network devices like personal computers, routers, to automatically discover other’s presence on the network and establish working communication configuration[7].
Each node in WSN must be able to answer to multicast requests and convey its capa- bilities, as well as storing locally the standard-defined descriptions for its services.
After retrieving the description for a given service, a client knows the interface to that service and can start to use it.
1.4 Results
In this project the facilities of the UPnP protocol for service discovery and control have been implemented and evaluated in Contiki, an operating system for wireless sen- sor networks. The technologies employed in the project are IPv6 over 802.15.4 (with 6LowPAN header compression) and RPL.
We show that it is possible to run UPnP on sensor node platform such as Wismote, and we evaluate the implementation with regard to energy consumption and latency of response.
Moreover, some simplifications are proposed in order to render the protocol more lightweight. Compared to the original version, the power consumption of the radio and the Service Discovery latency are reduced by 20% and over 60% respectively.
The use case is a sensor node that can announce and offer the services of reading tem- perature and switching on and off its LEDs.
Furthermore, a UPnP IPv6 client has been developed in Java. It runs on the PC side and its purpose is to test the features developed on the sensor node side, and to have a complete development toolchain.
1.5 Document structure
This document is structured as follows. Chapter 1 contains introduction to the problem and the solution approach. Chapter 2 describes the protocols and the technology used in the project. Chapter 3 presents the implementation procedure whose results are evaluated in Chapter 4. The report is finally concluded in Chapter 5.
Chapter 2
Background
In this chapter the technical specifics of the technologies chosen to allow Service Dis- covery in Wireless Sensor Networks are presented more in detail.
2.1 Contiki and protocol stack
As previously stated, the goal of this thesis is to implement and evaluate the UPnP pro- tocol in Contiki using 6LowPAN stack of protocols. Contiki is a lightweight, highly portable operating system for wireless sensor networks [9]. It is designed for running on resource constrained devices, which are typically equipped with 8-bit microcon- trollers, 20 kilobytes of RAM and code memory in the order of 100 kilobytes. The Contiki kernel uses a hybrid model in order to combine the advantages of event-driven systems and preemptible threads in order to be responsive to external events even in the case of lengthy computations. Contiki supports a full TCP/IP stack via the uIP library, as well as the programming abstraction Protothreads.
It has been ported to a large variety of microcontroller architectures, including Texas Instruments MSP430 and the Atmel AVR.
The protocols stack used in Contiki are shown in Figure 2.1.
What follows is a concise bottom-up description of each layer’s properties.
IEEE 802.15.4 defines the interface with the physical transceiver radio, the frequency used by Contiki is the range of 2400-2483.5 MHz. 16 channels are available [10].
Radio Duty Cycling is implemented in ContikiMAC. It allows sensor nodes to save power by having the radio turned off for most of the time and periodically wake up in order to be able to receive communication from neighbours[11].
CSMA The Carrier Sense Multiple Access (CSMA) is the MAC layer mechanism that is responsible for avoiding collisions at the radio medium. In case of collision, CSMA does a linear back-off before retransmitting the packet. Alternatively to CSMA, Con- tiki provides a NullMAC mechanism, that does not do any MAC-level processing [12].
uIPv6 is a tiny IPv6 protocol stack implementation integrated in Contiki. It only re- quires 0.5 KB of RAM for data structures, a minimum of 1.3 KB of RAM for buffering, and 11 KB of Flash for the code [13].
Figure 2.1: Contiki protocol stack
Scope Address link-local FF02::C site-local FF05::C organization-local FF08::C
global FF0E::C
Table 2.1: IPv6 multicast addresses by scope
With IPv6 it is possible to assign an address to virtually any human-made object, thanks to its immense address space made of 128-bit long addresses.
IPv6 addresses are normally represented as octets made of four hexadecimal digits, each one separated by column, for example:
2001:0db8:85a3:0042:0000:8a2e:0370:7334
If an address presents continuous octets made by only zeros, these may be omitted.
For example:
FF05:0000:0000:0000:0000:0000:0000:C can be shortened to:
FF05::C
In this project IPv6 was used for both unicast and multicast communication, the latter being used by UPnP in the service discovery phase.
Multicast communication in IPv6 can have different scopes, each of which has a cor- responding address as shown in the Table 2.1.
The scope of the IPv6 multicast address used in this project is site-local, hence the multicast address FF05::C, as we want to discover services present in a local network [14]. The link-local address could not be used because it is not routable.
RPL is an IPv6 routing protocol designed for Low power and Lossy Networks (LLNs).
In LLNs, the packet loss rate is very high compared to traditional networks. Therefore the routing protocol must be flexible and robust enough to tackle with the nature of the network.
In a WSN scenario, nodes want to typically send data to a border router, and thus RPL is optimized for many-to-one communication, though any-to-any is supported as well.
ContikiRPL implements the RPL protocol, according to version 18 of RPL [15]. Con- tikiRPL does not make forwarding decisions per packet, but sets up forwarding tables for uIPv6 and leaves the actual packet forwarding to uIPv6 [10].
2.2 Cooja: a wireless sensor network simulator
Cooja is a sensor network simulator for the Contiki OS. A sensor node that runs a Contiki program can be simulated and multiple platforms are available (Tmotesky, Wismote, etc.) [16].
Cooja was used intensively in this project during developing and testing phases, as
Figure 2.2: Cooja Simulator
doing the same on the real hardware would be very time-consuming. Cooja allows to speed up, slow down or pause simulations.
The Log Listener prints out whatever comes from the nodes’ serial ports. The radio logger permits to analyze packets that are sent and received by nodes, which is a useful feature for debugging. The timeline is used to ensure that the nodes’ behaviour is coherent with the intended purpose.
Figure 2.2 is a screenshot that shows the Cooja simulation environment.
2.3 Hardware platforms for Contiki
Experiments were performed on two different sensor node platforms: Tmote Sky and Wismote. Wismotes have a much bigger flash memory, which came in handy for stor- ing the XML messages used by UPnP.
2.3.1 Tmote Sky
Tmote Sky has a 8MHz Texas Instruments MSP430 microcontroller, based on a 16-bit RISC architecture. It has 10k of RAM and 48k of Flash memory. For communication it uses a Chipcon Wireless Transceiver CC2420, bit-rate 250kbps, frequency of 2.4GHz and compatible with the IEEE 802.15.4 standard. It is equipped with three LEDs and temperature, humidity and light sensors [17].
Figure 2.3: Tmote Sky
Figure 2.4: Wismote
2.3.2 Wismote
The Wismote platform has a Texas Instruments MSP430 series 5 microcontroller which allows 20-bit memory addressing, 16kB internal RAM and 256kB Flash. The radio, TI CC2520, is compatible with the IEEE 802.15.4 standard, frequency 2.4GHz with support for 6LoWPAN/Zigbee/WirelessHart [18].
2.4 Service Discovery
2.4.1 UPnP
The UPnP Architecture defines a set of protocols designed for being easy-to-use, flex- ible, for providing standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet[7].
UPnP is mainly used for dynamically establish network connections and let devices learn about each other’s presence and capabilities. After the device has joined a net-
work and established connections with its peers, it can perform operations such as control, data transfer etc. [8].
UPnP leverages the Internet stack of protocols to attain high levels of compatibility, on top of which standard format XML messages are exchanged.
Further specifications about parts of UPnP used in this project are described in the fol- lowing paragraphs.
Service Discovery
Service Discovery in UPnP is done through the Simple Service Discovery Protocol (SSDP). When a device is added to a network, it can advertise its services to the con- trol points (i.e. the clients). It is also possible to communicate the withdrawal of the service. Control points can execute search operations to discover services present in the network.
Search Request
According to the standard, the format of each message is reported:
M-SEARCH * HTTP/1.1 HOST: FF05::C:1900 MAN: "ssdp:discover"
MX: seconds to delay response ST: search target
USER-AGENT: OS/version UPnP/1.1 product/version
Search requests are sent over UDP and the destination address of the is the IPv6 site- local multicast address FF05::C with port number 1900. A UPnP-enabled device that is listening on the socket with this address and port number will reply by sending to the client a UDP unicast packet containing the response.
Search Response HTTP/1.1 200 OK
CACHE-CONTROL: max-age = seconds until advertisement expires DATE: when response was generated
EXT:
LOCATION: URL for UPnP description for root device SERVER: OS/version UPnP/1.1 product/version ST: search target
USN: composite identifier for the advertisement
BOOTID.UPNP.ORG: number increased each time device sends an initial announce or an update message
CONFIGID.UPNP.ORG: number used for caching description information SEARCHPORT.UPNP.ORG: number identifies port on which device responds to unicast M-SEARCH
Search responses are sent over UDP and the destination address is the source address of the search request. In the search response it is important to notice the LOCATION
Once the control point has fetched the description file of a device, it knows the lo- cation of the description files of its services. These files must be fetched for each service the control points wants to send actions to. Actions to services can be sent through the Simple Object Access Protocol (SOAP). SOAP relies on XML messages over HTTP. When a device receives a SOAP control request from a control point, it parses the SOAP request and executes the required action, returning any specific re- sponse (a SOAP message as well) to the control point (i.e. the client) [7].
SOAP control request format POST path control URL HTTP/1.
HOST: hostname:portNumber CONTENT-LENGTH: bytes in body CONTENT-TYPE: text/xml; charset="utf-8"
USER-AGENT: OS/version UPnP/1.1 product/version
SOAPACTION: "urn:schemas-upnp-org:service:serviceType:v#actionName"
<?xml version="1.0"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:actionName xmlns:u="urn:schemas-upnp-org:service:serviceType:v">
<argumentName>in arg value</argumentName>
<!– other in args and their values go here, if any –>
</u:actionName>
</s:Body>
</s:Envelope>
Eventing
In the service description file, devices publish a list of evented variables. Control points can subscribe to the events of a service by using the subscription URL located in the device description file. Upon subscription they will receive updates when the value of evented variables change.
Event message format
NOTIFY delivery path HTTP/1.0 HOST: delivery host:delivery port
CONTENT-TYPE: text/xml; charset="utf-8"
NT: upnp:event NTS: upnp:propchange SID: uuid:subscription-UUID SEQ: event key
CONTENT-LENGTH: bytes in body
<?xml version="1.0"?>
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<variableName>new value</variableName>
</e:property>
Other variable names and values (if any) go here.
</e:propertyset>
2.4.2 mDNS
Another technology for discovery of network services is Multicast DNS (mDNS). It is part of Zeroconf [22], and it is used by Apple’s Bonjour and others. It leverages the DNS programming interfaces, packet formats and operating semantics, and it is primarily intended to operate in small networks where no DNS server is installed. As UPnP, mDNS also relies on UDP over IP multicast communication.
With mDNS, it is possible to do host and service discovery.
In host discovery, a client interested in knowing the IP address for a given host name sends a multicast query message in the local network. The host with the queried host name will reply (also with a multicast message), and all the machines of the subnet will update their mDNS cache accordingly.
Service discovery is done in a similar way to host discovery, but in the query message it is specified that the target of the search is a PTR (pointer record) instead of A (address record) [19].
2.5 Related work
2.5.1 Service Discovery in Wireless Sensor Networks
The problem of allowing sensor nodes to advertise the resources they hold is not new.
The authors of [20] implemented mDNS in a small wireless sensor network target node.
With this implementation sensor nodes can advertise and host services through mDNS.
The main benefit of allowing sensor nodes to communicate with UPnP is to achieve interoperability with millions of local network devices that already use the set of stan- dard protocols specified in the UPnP architecture.
By using standard widespread protocols we envision a service-oriented architecture, in
this thesis has investigated how it is possible to shrink UPnP in order to allow tinier de- vices to exploit its advantages.
2.5.2 CoAP
The Constrained Application Protocol (CoAP) is an application layer protocol designed for resource-constrained network devices (typically sensor nodes with small amounts of ROM and RAM and 8-bit microcontrollers). CoAP is designed to be easily inter- faced to HTTP in order to integrate with web applications while causing a low over- head.
The protocol is intended for usage in machine-to-machine (M2M) applications, such as smart energy and building automation [21].
CoAP messages can be of type request and response, which are typically encapsulated in UDP packets. Clients can use Multicast CoAP to find servers, in which a request is made to a IP multicast group instead of a CoAP end-point.
Service discovery takes place when a client queries a server for its list of hosted re- sources and learns one or more URI that reference resources in the namespace of the server.
The CoAP protocol is interesting because it may be used in future to replace certain parts of a UPnP transaction, for example, the service control part that is currently han- dled by SOAP.
Chapter 3
Design and implementation
In this chapter the system architecture is unveiled and the behaviour of the software components that were designed and implemented is described.
3.1 System architecture
Protocols like SSDP and COAP leverage the the transport layer (UDP and TCP re- spectively). Once a working configuration between two peers has been established, higher-level applications may be using it. Therefore, in the protocols stack, the UPnP set of protocols can be considered as a middleware between the UDP/TCP layer and the application layer, as represented in Figure 3.1.
In a typical UPnP usage scenario, a client will send search requests to discover neighbouring devices’ services. Once the client is informed of the services provided by a device, it may begin to use a service by sending commands, and the responder will reply by supplying the requested information or executing an action [7].
A full UPnP transaction can be therefore summarized in the following steps:
1. client sends SEARCH request
2. responder sends SEARCH response (containing device description file’s url) 3. client fetches device description file (containing services description file’s url) 4. client fetches description of services in which it is interested
5. client may send:
(a) subscription request to a service
Figure 3.1: UPnP in the protocol stack
Figure 3.2: System architecture
6. responder may send:
(a) subscription OK message / updates (notify) upon change of evented vari- able
(b) update (soap) (c) control OK response
Figure 3.3 shows a possible UPnP transaction represented as a sequence diagram.
As shown in the figure, the first phase is service discovery followed by the retrieval of the device and service description files from the web server. Consequently the client knows the service’s specifics and can start to use it by sending requests and actions.
3.2 Implementation
3.2.1 UPnP in Contiki
The UPnP-responder implementation in Contiki is divided in two main threads: Re- sponder and Webserver.
Responder waits for incoming search requests from control points to the IPv6 multi- cast address FF05::C and at UDP port 1900. When a search request is received, a UDP unicast packet containing the search response will be sent. The search response is the first acknowledgement of the device’s presence and contains the URL that locates the device’s description file, in addition to other information such as the device type and id. This behaviour is implemented as a process thread.
The two main functions of the Webserver thread are to deliver UML descriptions and handle control requests. The UML descriptions delivered are the device and services’
descriptions.
The other requests that the Webserver thread handles might be control, subscription or update requests. After retrieving the service description files, a control point is aware of the commands it needs to send in order to query a specific service provided by the responder. Requests to the web server are sent to TCP port number 5790.
The Web Server is divided in:
• a process thread that waits for incoming connections
• a protothread that handles serves the incoming requests by supplying the re- quested resource or executing the action by triggering an actuator (i.e. switch light on or off)
An additional protothread is used to periodically refresh the values read from the sen- sors, which the web server might supply to a client upon request.
3.2.2 Development toolchain and UPnP IPv6 client
UPnP responder: a device that runs Contiki and is able to respond to UPnP multicast search requests, as well as executing commands sent by a client in order to receive
Figure 3.3: UPnP transaction diagram
sensor information or perform actuator control.
Slip-radio: a contiki running device that converts the data it receives on the serial port in IP traffic over the radio and vice-versa.
Native border router: it is a process running in linux which forwards traffic directed to AAAA::/64 to the serial port. It is the bridge between UPnP clients and the WSN (by communicating directly with slip-radio).
UPnP client: The UPnP-client is a process that sends UPnP requests to the IPv6 site- local multicast address FF05::C and receives responses. A java program (the GUI being shown in Figure 3.5) was developed for this purpose.
The primary function of the UPnP client is to send multicast search requests, and dis- play search responses. It can also send HTTP GET requests to fetch device and service description files. Moreover, the GUI allows the user to subscribe and use the services of a UPnP-responder node, which in the present case of study is able to provide two services: temperature information and lamp switch (simulated by the node’s LEDs).
When the client receives updated data from a sensor node in the form of a SOAP mes- sage, this is parsed and the information of interest is shown on the GUI (for example the current temperature value or whether the lamp is on or off).
For debugging and testing purposes, the UPnP client also has a facility to receive on the multicast socket (thus being able to receive other device’s search requests as well as its own). The Web server contained in the responder was also tested with regular web browsers.
Furthermore, it is possible to communicate from an external process with every node within the sensor network simulated in Cooja by using the Native-Border-Router, a feature that was very useful in the project to send the requests from the UPnP client, as shown in Figure 3.4. Extensive simulations were conducted in Cooja during the imple- mentation phase.
Figure 3.4: Simulation architecture
Figure 3.5: UPnP IPv6 client
Chapter 4
Evaluation
The evaluation was conducted by testing and assessing various properties of the UPnP implementation both in the Cooja simulator and on real nodes, using both Tmote Sky and Wismotes.
Radio duty-cycling was also employed to study the relation of energy consumption and latency of response.
In Contiki, a duty-cycling mechanism is implemented under the name of ContikiMAC.
Energy consumption of a full UPnP transaction was experimentally quantified when using duty-cycling.
4.1 Experiments on hardware platforms
The target hardware platforms used in the project were Tmote Sky and Wismote. Ex- periments were conducted with real hardware in a similar fashion to Cooja simulations, with UPnP IPv6 client and native border router on the Linux side, and the nodes run- ning slip radio and UPnP responder on the WSN side. This schema is shown in Figure 4.1, where one Tmote Sky was used as slip-radio and a Wismote as UPnP responder.
One problem running UPnP responder on a Tmote sky as target platform, was the size of the UPnP messages (e.g. device and service description files) that need to be stored in a responder device. The Tmote Sky quickly ran out of flash memory, hence the need to use a platform with larger memory which made the choice lean towards the Wismote platform. The slip-radio node connects the WSN to the rest of the world through the native border router. For this purpose a Tmote sky is sufficient.
4.2 Energy consumption and latency evaluation
As previously stated, minimizing energy consumption is an important requirement in many WSNs. In order to attain this, a technique called "Radio Duty-cycling" is used to
Figure 4.1: Experiment setup
UPnP message Size (bytes)
Number of TCP packets
required
Device description XML file 776 17
Service description XML file 660 14
Temperature update 406 9
LED status update 370 8
Table 4.1: Size of UPnP messages and TCP packets required to transmit them
was conducted in order to assess how much the length of the UPnP messages affects the overall energy consumption. Duty-cycling increases latency and slows down the network responsiveness. If a sensor node periodically turns off its radio instead of listening, it will be slower in replying to the UPnP requests that are sent from the clients.
Table 4.1 reports the size and the number of packets needed to transmit each UPnP message, combined with information about latency with and without radio duty-cycling.
Figure 4.2 shows that the latency increases roughly of a factory of 3 when duty- cycle is used. The values of the latency are consistent with the messages’ size reported in 4.1. These measurement were conducted by an automated client program that re- quested each resource 30 times and then calculated the average value.
The average duty-cycle value, which means the percentage of time in which the radio was in ON state (either transmitting, listening or receiving ), was at 0.8% when these experiments were carried out.
4.3 Optimizations to UPnP in Contiki
In order to allow the UPnP protocol to run faster and consume less energy on resource constrained devices, a number of simplifications were tested on the responder side.
This included shrinking update message size to only one TCP packet, by only includ- ing essential information.
For example, the content of 4.2 was shortened as shown in 4.3.
Another optimization was having a unique URL for each action (subscribe, update, control) of each service. This allows the responder to immediately identify the type of request and the service involved, without the need to process a lengthy incoming SOAP message.
Figure 4.2: Impact of radio duty-cycling on latency
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<GetLedStatus>
<LedStatus>X</LedStatus>
</GetLedStatus>
</soap:Body>
</soap:Envelope>
Table 4.2: Full response message for LED update request HTTP/1.1 200 OK
<LedStatus>X</LedStatus>
Table 4.3: Compressed response message for LED update request
which in the long run increases the network’s life-time.
Figure 4.4 shows that in case of no duty-cycle the average latency for receiving one update message improves from 4.0 to 3.5 seconds on Tmote Sky. The reason why the improvement is relatively small even shrinking the response message, is that the request message has not been shrunk. The transmission of the request message still dominates the latency.
An improvement that could dramatically speed up the service discovery phase is creat- ing standard interfaces for services, and defining standard type of devices that provide certain kinds of services.
Figure 4.2 shows most of the time is spent by the client retrieving the device and ser- vice description files. If this phase could be skipped, the client could immediately jump to using the service after receiving the Search response from the UPnP Responder.
If we know by the type of the UPnP-enabled Contiki device that it will always provide a certain type of service (e.g. Temperature sensing service), and that the interface for accessing that service is always the same, we can program smarter clients that are able to skip the retrieval of the heavy-weight description files.
In order to fully take advantage of this mechanism, further work should be conducted to standardize the UPnP implementation in Contiki and create templates of devices whose services can be accessed with a standard and well-known interface. Defining a standard service interface primarily means defining standard URLs for sending com- mands to the service.
The gain of this optimization was quantified as shown in Figure 4.5, where we can see that the latency of the service discovery phase would decrease by 65% and 63% with and without radio duty-cycling respectively.
4.4 Discussion
The primary application scenarios for which the UPnP implementation for Contiki is intended are smart energy, smart plugs, temperature sensors etc.
The current implementation only handles uni-hop multicast, which entails that it is pos- sible to reach a responder at a distance of one hop from the border router. Multi-hop multicast is currently supported in Contiki with netflooding, which is used to spread a message across the network from one point. However in the case of UPnP, with re- sponses that must be sent from each UPnP-responder in the network, difficulties may arise if these all do so at the same time.
In order to make the protocol more efficient and fit it into tinier platform like Tmote Sky, the messages describing the device and its services may be shrunk and simplified for the context of WSN. Shrinking the size of the description files may also be benefi- cial from the energy point of view in combination with radio duty-cycling. If the nodes communicate less and for shorter periods of time they can save energy and prolong the sensor network’s life-time.
As we have observed in the evaluation duty-cycling introduces certain latencies. De-
Figure 4.3: Duty-cycle comparison
Figure 4.4: Average latency of one update message comparison
Figure 4.5: Latency reduction with Service Caching
A scenario in which multiple responders are present was studied. In this case, the re- sponders will try to reply to a multicast request at the same time, which might cause the slip-radio to drop some packets and lose one of the responses. A solution to this problem could be to respond with a random delay, which would help minimizing the probability of packet loss.
Another issue is that due to the unreliable nature of UDP and the high packet-loss-rate typical of WSNs, it is possible that a device fails to discover the presence of UPnP- enabled sensor nodes. The UPnP clients must be aware of this and implement mecha- nisms to re-send their requests when needed.
Chapter 5
Conclusions and Future work
In this thesis, a UPnP prototype over IPv6 was implemented for Contiki. The con- tribution of this thesis is showing that it is feasible to use the UPnP set of protocols in wireless sensor networks. The implementation was evaluated with regard to energy consumption and latency of response. Furthermore, simplifications were made to make the protocol more efficient.
Even without simplifications, the advent of larger platforms such as Wismote is allow- ing sensor nodes to run more and more complex software, therefore UPnP could soon be run smoothly in many sensor networks application scenarios.
This thesis shows that it is possible to do service discovery, as well as utilizing the services provided by sensor nodes.
Depending on the application scenario, the system designer should decide if deploying the protocol in combination with radio duty-cycling.
Tests were conducted both in software and hardware to ensure that the implementation works and produces expected results.
The main obstacles in this project were using Tmote Sky hardware that has very lim- ited flash memory resources. Fitting the program code into these nodes was sometimes impossible, especially in combination with debug, duty-cycling or power measurement features. Therefore, most of the evaluation was done with Wismote nodes simulated in Cooja.
Future work in this field may target optimizing, especially on the client side, the UPnP implementation for applications where low energy consumption or latency are strict requirements, or the employed platform does not provide enough memory to run full UPnP.
A lighter version of the protocol should be specified and standardized for severely con- strained environments, to make the interaction client-responder faster and simpler.
The support for multicast multihop is also an area of interest. The main problem would be avoiding all the responders to simultaneously reply to the same request as it spreads across the wireless network, thereby obstructing each other’s response. Further work should be conducted to find the best solutions.
Finally, more features could be added and supported, such as searching for a specific service by the client.
Bibliography
[1] F.L. Lewis. Wireless sensor networks. Smart Environments: Technologies, Pro- tocols, and Applications, pages 11–46, 2004.
[2] J. Polastre, R. Szewczyk, A. Mainwaring, D. Culler, and J. Anderson. Analysis of wireless sensor networks for habitat monitoring. Wireless sensor networks, pages 399–423, 2004.
[3] V. Shnayder, B. Chen, K. Lorincz, T.R.F.F. Jones, and M. Welsh. Sensor networks for medical care. In Conference On Embedded Networked Sensor Systems: Pro- ceedings of the 3 rd international conference on Embedded networked sensor systems, volume 2, pages 314–314, 2005.
[4] R. Van Kranenburg, E. Anzelmo, A. Bassi, D. Caprio, S. Dodson, and M. Ratto.
The internet of things. A critique of ambient technology and the all-seeing net- work of RFID, Network Notebooks, 2, 2008.
[5] S. Roundy, D. Steingart, L. Frechette, P. Wright, and J. Rabaey. Power sources for wireless sensor networks. Wireless Sensor Networks, pages 1–17, 2004.
[6] F. Zhu, M. Mutka, and L. Ni. Classification of service discovery in pervasive computing environments. Michigan State University, East Lansing, available at http://www. cse. msu. edu/˜ zhufeng/ServiceDiscoverySurvey. pdf MSU-CSE-02- 24, 2002.
[7] UPnP Forum. UPnP Device Architecture 1.1, http://upnp.org/specs/
arch/UPnP-arch-DeviceArchitecture-v1.1.pdf.
[8] Microsoft Corporation. Understanding Universal Plug and Play, http://
www.upnp.org/download/UPNP_understandingUPNP.doc2000.
[9] A. Dunkels, B. Gronvall, and T. Voigt. Contiki-a lightweight and flexible operat- ing system for tiny networked sensors. In Local Computer Networks, 2004. 29th Annual IEEE International Conference on, pages 455–462. IEEE, 2004.
[10] J.G. Ko, J. Eriksson, N. Tsiftes, S. Dawson-Haggerty, A. Terzis, A. Dunkels,
[11] A. Dunkels. The contikimac radio duty cycling protocol. 2011.
[12] Contiki Wiki. http://www.sics.se/contiki/wiki/index.php/
Change_MAC_or_Radio_Duty_Cycling_Protocols.
[13] FinanzNachrichten.de http://www.finanznachrichten.de/
nachrichten-2008-10/12014846-atmel-cisco-and- the-swedish-institute-of-computer-science-sics- collaborate-to-support-a-future-where-any-device- can-be-connected-to-the-internet-008.htm.
[14] Network Working Group . Internet Protocol, Version 6 (IPv6). Request for Com- ments: 2460.
[15] T. Winter. Rpl: Ipv6 routing protocol for low-power and lossy networks. 2012.
[16] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, and T. Voigt. Cross-level sensor network simulation with cooja. In Local Computer Networks, Proceedings 2006 31st IEEE Conference on, pages 641–648. IEEE, 2006.
[17] Tmote Sky datasheet. http://www.eecs.harvard.edu/~konrad/
projects/shimmer/references/tmote-sky-datasheet.pdf.
[18] Wismote specifications. http://wismote.org/doku.php?id=
specification.
[19] Multicast DNS. http://www.multicastdns.org/.
[20] Å. Östmark, J. Eliasson, P. Lindgren, A. Halteren, and L. Meppelink. An infras- tructure for service oriented sensor networks. Journal of Computers, 1(5):20–29, 2006.
[21] CoRE Working Group. Constrained Application Protocol (CoAP). Internet-Draft draft-ietf-core-coap-11, 2012.
[22] Zeroconf. http://www.zeroconf.org/.
