QLowpan: A Queries Processor Over RPL/6lowpan Based Sensors Networks Karim FATHALLAH*, Ali FRIHIDA, Leila BEN SAAD, Nejib BEN HADJ-ALOUANE, Tunis El Manar University – TUNISIA *
[email protected]
Abstract— Wireless Sensor Networks have been witnessed an increased interest in many applications includingsuch as precision agriculture, homeland security, military application, environment monitoring, etc. In such applications, densely deployed sensors answer queries injected by the sink in a specific area of interest. The processing of these queries is performed by a system that usually provides a simple user interface based on SQL like queries. However, the existing processing systems do not allow the querying of wireless sensor networks that support IPv6 protocol. In this paper, we present the design of a new query processing system called QLowpan, that supports the newly emerged protocols RPL and 6LowPAN, and, the latter have enabled wireless sensor networks to become reachable on the global IP network. KEYWORDS-wireless
sensor network, 6lowpan, sensor network queries processor, RPL.. Ι.
INTRODUCTION
Recently, wireless sensor networks have been used in wide range of applications such as health monitoring, smart home [1] and agriculture [2]. However, dealing with technologies related to wireless sensor networks is always limited to the expert community. In fact, in order to use a wireless sensor network, sensors must be programmed in advance. The aim of this programming is to retrieve the desired information and specify adequate sampling frequency. Limitations of energy, memory and bandwidth in wireless sensor network must also be considered in the programming phase. These constraints make programming such systems a complicated task. It is in this context sensor network queries processing (SNQP) [3] system has been created. Indeed, the latter offers the possibility to user to look at wireless sensor networks as a database. In order to collect certain information from the wireless sensor network, an SQL like query must be simply entered. Since September 2003 date of the development of TinyDB[4], the first sensors network queries processor (SNQP), the lists of this kind of system have not ceased to
Bernard TOURANCHEAU** Grenoble Joseph Fourier University, France**
expand. In fact, we can now count six [5] different systems described in the literature. However, none of these systems are compatible with IPV6 based sensor networks called 6lowpan [6]. 6lowpan is an IETF standard defined and described in the RFC 4944. 6lowpan implements an adaptation layer between the network layer and data link layer to allow the transmission of IPv6 packets on wireless sensors networks. Using this protocol in wireless sensor network is increasingly widespread. Currently, the 6lowpan protocol is integrated by default in both the most used operating systems of wireless sensors networks (TinyOS [7] and Contiki [8]). Recently in the RFC 6550 the IETF has set the RPL [9] protocol as the chosen routing protocol in 6lowpan networks. The purpose of this paper is to present a new system called QLowpan for querying RPL/6lowpan based networks. The paper is organized as follows. Section 2 presents the global concepts of the protocol stack RPL/6LOWPAN. Section 3 define and introduce sensors queries processor systems. Section 4 is devoted to the description of our proposed system Qlowpan. Finally, section 5 concludes the paper. ΙΙ.
RPL/6LOWPAN BACKGROUND
A. 6LOWPAN Overview 6lowpan is an IETF standard that describes how to transmit IPV6 packet over 6lowpan. The RFC 4944 defines the overview, assumption, statement problem and goals for 6lowpan. In fact, the main problem to resolve in 6lowpan is that the packet size of IPV6 is much larger than IEEE 802.15.4 MTU [10]. 6lowpan proposes an adaptation layer between network layer and data link layer. It reduces overhead of IP transmission by using techniques based on compression of IPV6 header. 6Lowpan uses also a mesh forwarding to deliver packet from source to destination over multihops scenario. To determine whether a frame is lowpan frame or no, one byte dispatch value of adaptation layer is employed. In the case of a lowpan frame, a specific type header will take place as part of dispatch value. As a value of this specific header, we found fragmentation header, compressed/uncompressed header, broadcast or mesh header. If the ip packet size is bigger than data linker MTU fragmentation is essential. The header of fragmentation will be inserted after the adaptation layer
dispatch value. The first fragment and subsequent fragment have for different dispatch value. The fragment offset can only be a multiple of eight bytes length. Except the final fragment, the others fragments are multiples of eights bytes. If there are many headers in the same packet, the mesh addressing, the broadcast header, and the fragmentation headers will be placed sequentially. In the route over schema all routing decision are taken in the network layer. In this context each node acts as an IP router and each link layer hops is an IP hop. Forwarding packet between these links is supported by IP routing. In other word, routing table and IPv6 hop by hop option are used. For forwarding and routing networks layer take decision using the additional encapsulated ip header. The 6lowpan [8] adaptation layers establish a direct mapping between the frame and the IPv6 headers. Fragments of ip packet are sent to the next hop based information in the routing table. In the next hop, the adaptation layer checks received fragment. If all of them are received successfully, an IPv6 packet will be created based on fragment by the adaptation layer and it will be sent to the network layer. If the packet reaches destination, the network layer send the IPv6 packet to the transport layer, otherwise it forwards the packet to the next hop. If there is missed fragment then a retransmission of all fragments will be executed. When all fragments are successively received the adaptation layer creates an ip packet from these fragments and transmits it to the network layer. Then, the network layer process or forward the ip packet based on the destination of the packet and routing table information B. RPL Overview
As shown in figure 1, RPL[9] creates a tree like topology with is rooted at the sink border rooter (LBR) on the top. RPL is a distance vector protocol. Operation of the last task can be divided into two main phases: routing upward and routing downward. The information of topology is maintained in a destination oriented directed acyclic graph (DODAG). The last one contains path from root to the leaves. The root of wireless sensor also called (LBR), can be connected to standard IPv6 network. In RPL, routing the traffic upward is only based on the information in the DODAG. This last one tells which one is the node preferred parents. When a node sends a packet to the root, it sends simply the packet to its preferred parent. Also this preferred parent sends the packet to its preferred parent and so on until the packet reaches the root. The DODAG building process can be described as following: •
Step1: the DODAG root starts sending the link local multicast DIO messages.
•
Step2: nearby nodes receive the DIO from the root and process it as it is from a lower rank node. The root is selected as preferred parents.
•
Step3: in his turn, this nodes will send link local multicast DIO and the others nodes receiving the DIO may select them as parents.
To support downward traffic, RPL uses DAO messages to maintain the rooting table. RPL is considered a hierarchical network in term of flow of control messages ΙΙΙ.
OVERVIEW OF SENSOR NETWORK QUERY PROCESSOR (SNQP)
A. General architecture of a SNQP A general architecture [4] for executing the queries in sensor networks is shown in Figure 2. The architecture consists of two main parts:
Figure 1. RPL network topology
•
Server-side: The software is running on the base station. In its most basic form, the software interprets queries, delivers them in the network, and collects the results posted on the network.
•
Node-side: The software behaves like a distributed query processing. This software consists of several modules built on top of the nodes operating system.
identifier (nodeid), brightness (light), temperature (temp) read once per second, for 10 seconds. The virtual table "sensors" combines a column for each attribute and one line for every possible instance in time. As in SQL, a query in SNQP is a select-from-where-group by blocks support for join operations, selection, aggregation and grouping (see Table 1). SNQP generally allow the modeling of sensor data as a single virtual table. The system continuously added to this table tuples with each sample transmitted by the network. For example, the query (select nodeid, light, temp from sensors sample period 1s for 10s) specifies that each node must return its own parameters: identifier (nodeid), brightness (light), temperature (temp) read once per second, for 10 seconds. The virtual table "sensors" combines a column for each attribute and one line for every possible instance in time.
Operator
Description
Figure 2. Structure of an SNQP
B. User’s queries in SNQP In this architecture, the user enters queries at the server in the form of a variant of SQL commands that refers to the data to be collected, how they will be combined and presented. This SQL variant is profoundly different from the standard SQL. In fact, execution of these queries is continuous in time. In practice, the user requests more information on some reports by writing predefined conditions (e.g. temperature in the greenhouse # 3 every 10 seconds for 1 hour) and the system returns the result in accordance with those conditions. Each time when the result is produced is called an epoch. The duration of an epoch, denotes the time between two successive samples (10 seconds). As in traditional database management systems, queries describe a logical set of data which the user is interested in, but do not describe the algorithm that will be executed to retrieve the data [11]. Typically, the system can choose between different execution plans for any query. For example, to find the average temperature in the fifth greenhouse, the system will collect data from all the sensors, then filtering the sensed data of the greenhouse number 5 in order to calculate the desired average. Alternatively, one can retrieve the temperatures of the nodes of the 5th greenhouse. It is therefore quite clear that the plan will be more optimized. The process of selecting the best plan is called query optimization. C. Query languages in SNQP As in SQL, the query in SNQP is a select-from-wheregroup by blocks support for join operations, selection, aggregation and grouping (see Table 1). SNQP generally allow the modeling of sensor data as a single virtual table. The system continuously added to this table tuples with each sample transmitted by the network. For example, the query (select nodeid, light, temp from sensors sample period 1s for 10s) specifies that each node must return its own parameters:
Data acquisition
Acquire a reading (field) from a sensor or an internal device attribute, such as a light sensor reading or free RAM in the dynamic heap.
Select
Reject readings that don’t satisfy a particular Boolean predicate. For example, the predicate temp > 80°F rejects readings under 80°F.
Aggregate
Combine readings according to an aggregation function. For example, AVG(light) computes the average light value over each mote.
Join
Concatenate two readings when some join predicate is satisfied.
TABLE I.
SENSOR NETWORK QUERY-PROCESSING OPERATORS.
IV. QLOWPAN QLowpan is a sensor network queries processor for resource-constrained sensor devices. In order to guarantee interoperability between the different platforms, QLowpan is based on RPL/6lowpan protocol. To the best of our knowledge, thisit is the first sensor network queries processor thatwhich is compatible with 6lowpan protocol. A. General architecture: Qlowpan consists of three tiers architecture applications (see Figure 3). The first one is the base station tier, which
allows writing the queries and displaying the results. The second one consists of the sink tier, which ensures forwarding the queries to all nodes of the wireless sensor networks, and the collection of results. The third one is the nodes’ level tier thatwhich executes queries and forwards back results to the sink. figure 4: packet structure message
Slip6 is a protocol that offers adaptation between ipv6 and serial interface. At the beginning of the application, the user must execute tunslip6 to permit enable connection between the sink node and the base station. C. The Sink Tier The main role of the sink is to transmit queries to all nodes in the WSN. With IPv6, broadcast cannot be used. So, the only way to transmit message to all nodes is to use the multicast [13] . Qlowpan multicast communication is based on Trickle Multicast [14] which is described in the following section [14]. In wired networks, multicast mechanism is based on preservingmaintaining the network topology information in order to forward packet to their destinations. Due to the restrictions in memory capacity, this preservationmaintaining will be a challenging task in wireless sensor network. Trickle multicast proposes a method that permits allows tohe supporting of IPv6 multicast without having to rely on topology preservationmaintenance. With trickle multicast [14], each multicast datagram must carry a multicast option header. This header has similar shape to the IPv6 hop by hop option header. Each node in the network maintains a cache of recently seen multicast pockets. In this cache, the packets are identified based on HBHO extension header. Upon reception of multicast datagram, a node inspects the multicast option. If the packet is new one, it will be added onto the cache. Figure 3: architecture of QLowpan
B. The Base Station Tier The base station tiers refers to the set of modules and components running on the user side of Qlowpan application. As shown in figure 3, the called base station is a simple desktop directly connected to the sink node. The main task of this tier is to allow writing, sending of the user queries, and displaying of the results in a simple terminal. In the base station tier, we have three main components: the user interface, the queries parser and slip6 [12] protocol based communication [12]. The user interface is based on udp/ipv6 client that permits enabbles communication with an udp server running on the sink node. For the first tests, we used « netcat » and udp client to write queries and display results on terminal like interface. The queries parser: it is based on lex and yacc parsing lexical and syntaxical analyseranalyzer. On reception of the queries as string message, the queries parser module extract the pertinent information like fields, (e.g. expression, epoch value, etc.) etc and create a new packet structure message (see figure 4). After this stepat, queries packet is thenwill forwarded to the border router. Interconnection between border router and base station is based on slip6 protocol.
In trickle multicast, ICMPv6 datagram are used to permit enable the exchange information of neighboring nodes cache content. This last exchange is controlled by trickle timers. When the receiving node cache content doesn’t much information in the ICMPv6 datagram, trickle timers of the last node will be reset to its minimum (Imin) in order to make easier quick propagation of new packets. D. The Nodes Tier The main task of this tier can be described as follows: •
Parsing the queries,
•
Collect data from sensor,
•
Create the packet of results,
•
Forward results to the sink.
The last three tasks are repeated periodically along the queries lifetime. This period is equal to the sampling value described in the receiving queries. When nodes receive new query they set a timer based on the sampling value. On the clock signal the main process on the node will be reactivated and it creates a new results packets.
The results packet transmission up to the sink will be performed based on the rpl routing protocol. In QLowpan node, it is possible to can only receive queries from the sink and to send results data to the sink.
F. Performance: In order to evaluate the scalability and the performance of QLowapn we performed a series of experiences on contiki cooja simulator with common parameters outlined in table 2.
E. Validation To implement our QLowpan system, we used in sensor nodes Contiki 2.5[8]. It is a modular operating system that provides Contiki’s IPv6 stack. Cooja [15] simulator was used to evaluate the performance of our proposed QLowpan system. Cooja is a multilayer simulator of contiki published in the official distribution of Contiki.
Parameters
values
Nodes
From 10 nodes to 60 nodes
Radio Medium
Unit Disk Graph Medium (UDGM)
Ranges
TX: 50m, Interference: 60m
As a validation scenario of Qlowpan, we execute a selected query in order to collect temperature and light power of every node in wireless sensors network composed of 21 nodes. The sampling period is 2 seconds and the query lifetime is 1 minute, whichs this means that we have 30 samples for each sensor. In order to execute scenario we run QLowpan on Cooja [15] simulation environment (see Figure 4 and Figure5).
MAC Layer
IEEE 802.15.4
Duty Cycling
ContikiMAC
RNG Seeds
New seed each iteration
Table 2 : SIMULATION CONFIGURATION In these experiences we explore the scalability of QLowpan. To measure this scalability we calculate the packet received ratio of downward transmission and upward transmission in the following figure we can show the evolution of PRR in function of nodes number (see figures 7,8,9 and 10).
Figure 5: QLowpan on cooja simulator
Figure 7: queries forwarding scalability (OF0)
Figure 6. QLowpan Validation
•
First remark is the good scalability of trickle multicast with independently of the used objective function
•
The second remark is the low value of PRR of the reception results. V. CONCLUSION
This paper is concerned with wireless sensors networks query processing system. We presented the typical architecture of such systems. Then, we proposed a new query processor system called Qlowpan. Contrarily to existing systems, our Qlowpan system supports the emerged protocols 6lowpan and RPL, which have enabled wireless sensor networks to become reachable on the global IP network. Our system is very promising. given the facilities it offers in the use of sensor networks. In future works, we will focus on still open research issues such as the support of spatial and temporal queries and the management of heterogeneity and interoperability. Figure 8: queries forwarding scalability (ETX)
REFERENCES [1] [2]
[3] [4] [5]
[6] Figure 9: received results ratio
(OF0) [7] [8] [9] [10] [11] [12] [13]
[14] [15] Figure 10: received results ratio
(ETX) [16]
Based on the precedent figures we can have many remarks: [17]
Ben Saad L., Chauvenet C, Tourancheau B., IPv6 (Internet Protocol version 6) heterogeneous networking infrastructure for energy efficient building, Energy elsevier journal, 2012. Karim Fathallah, Ali FRIHIDA, Nejib Ben HADJALOUANE,Poster: Application websig-sensorDB pour supervisons des réseaux de capteurs, conférence sur les Réseaux de capteurs et Internet des objets, Mahdia, juin 2012 L. AL-Jadir, “Sensor Network Databases - An Introduction,” Advanced Research Topics in Databases Summer 2004-2005. J. Gehrke, S. Madden, Query processing in sensor networks, pervasive computing, January, 2004 K. Fathallah,A. Frihida, N. Ben Hadj-Alouane, Wireless Sensor Network Queries Processor A survey, in proceeding of International Conference on Information Processing and Wireless Systems, Djerba, Tunisia,2013 Montenegro, G., Kushalnagar, N., Hui, J. W., & Culler, D. E. (2007). Transmission of IPv6 packets over IEEE 802.15.4 networks. RFC 4944. Tinyos OS .http://www.tinyos.net/,december 2013 Contiki OS. http://www.contiki-os.org/, december 2013 Winter (editor), T., Thubert (editor), P., Brandt, A., Hui, J., Kelsey, R., Levis, P., et al. (2012). RPL: IPv6 Routing Protocol for Low power and Lossy Networks. RFC 6550 IEEE P802.15.4/D18, Draft Standard:Low Rate Wireless Personal Area Networks, Feb. 2003 S. Madden, Michael J. Franklin, Joseph M. Hellerstein, Wei Hong , The Design of an Acquisitional Query Processor for Sensor Networks, Proceedings of ACM SIGMOD , 2002 J. Romkey, A Non Standard For Transmission Of IP Datagrams Over Serial Lines: SLIP, June l988, RFC 1055 Carzaniga, A., Khazaei, K., & Kuhn, F. (2012). Oblivious lowcongestion multicast routing in wireless networks. In Proceedings of the thirteenth international symposium on mobile ad hoc networking and computing (MobiHoc 2012) Hui, J., & Kelsey, R. (2012). Multicast forwarding using trickle. Internet Draft (version 01). (draft-ietf-roll-trickle-mcast-01). N. Tsiftes, J. Eriksson, N. Finne, F. Osterlind, J. H Hoglund, and A. Dunkels, “A framework for low-power ipv6 routing simulation, experimentation, and evaluation,” SIGCOMM Computer Communication, August 2010. Y Yao, J E Gehrke, The cougar approach to in-network query processing in sensor networks, Proceedings of ACM SIGMOD, 2002. R. Müller, Gustavo Alonso, Donald Kossmann, SwissQM: Next Generation Data Processing in Sensor Networks, Proceedings of
[18]
[19]
[20]
the Third Biennial Conference on Innovative Data Systems Research (CIDR 2007) X. Galpin , Christian Y. A. Brenninkmeijer , Alvaro A. A. Fern , Es Norman W. Paton, SNEE: A Query Processor for Wireless Sensor Networks, Distributed and Parallel Databases manuscript, 2010. A. P. Sayakkara, W. S. N. Prabath Senanayake, Kasun Hewage , Nayanajith M. Laxaman, Kasun De Zoysa, The deployment of TikiriDB for monitoring palm sap production, Proceedings of the 4th international conference on Real-world wireless sensor networks,2010 R. Khoury, Tim Dawborn, Bulat Gafurov, Glen Pink, Edmund Tse, Quincy Tse, K. Almi’Ani, Mohamed Gaber, Uwe R¨ohm, and Bernhard Scholz, Corona: Energy-Efficient Multi-query Processing in Wireless Sensor Networks, International Conference on Database Systems for Advanced Applications, 2010
