Design and Construction of Wireless Sensor Network

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings

Design and Construction of Wireless Sensor Network Gateway with IPv4/IPv6 Support Bruno da Silva Campos 1 2 , Joel J. P. C. Rodrigues 2 , Lucas D. P. Mendes 2 , Eduardo F. Nakamura 3 and Carlos Maur´ıcio S. Figueiredo 3 1 Departament

of Computer Science. Federal University of Amazonas, Manaus, AM, Brazil de Telecomunicac¸o˜ es. University of Beira Interior, Portugal 3 Analysis, Research and Technological Innovation Center (FUCAPI), Manaus, AM, Brazil. [email protected], [email protected], [email protected], {eduardo.nakamura, mauricio.figueiredo}@fucapi.br 2 Instituto

Abstract—6LoWPAN opens a great opportunity for wireless sensor networks (WSNs) to be operated from the Internet. However, 6LoWPAN requires a gateway in order to make the use of IPv6 feasible inside the WSN. In this paper, a gateway is designed and constructed to interconnect 6LoWPAN wireless sensor networks with IPv6 clients, enabling them to receive sensor nodes readings or send commands to the 6LoWPAN WSN at anytime through direct communication with the sensor nodes. Furthermore, this solution allows IPv4 clients to exchange information with the WSN through a bridge architecture implemented at the gateway. The experimental results show that the communication between 6LoWPAN WSN and IPv6/IPv4 clients is successful. Index Terms—6LoWPAN, Gateway, IPv4, IPv6, Wireless Sensor Networks.

I. I NTRODUCTION Wireless sensor networks (WSNs) are an emerging technology that allows monitoring and control of the environment through limited devices called sensor nodes. Their goal is to perform distributed sensing over an area and send their results to base stations through multi-hop wireless communication. One of the challenges in this field is connecting these restrained devices directly to the Internet. It is usual that WSN applications use proprietary protocols to interconnect sensor nodes, because the use of the IP protocol is too heavy and does not consider the WSN applications requirements [1]. However, the inclusion of wireless sensor networks in the Internet became feasible due the standardization of IPv6 over Low-power Personal Area Networks (6LoWPANs), which introduces an adaptation layer below IP, enabling the transmission of IPv6 datagrams over IEEE 802.15.4 wireless links [2][3]. Basically, the adaptation layer performs header compression of IPv6 and transport layer headers, creating a new header composed by a few bytes. Inside the LoWPAN, nodes do not need to decompress this header, since every node knows the compressed fields contents. For instance, nodes use 16bit addresses or link-layer 64-bit unique IDs instead of full IPv6 addresses because their prefixes are the same for all nodes. The adaptation layer also handles packet fragmentation and reassembly in order to support the IPv6 minimum MTU (maximum transmission unit). These modifications made IPv6 suitable for low-power devices, including sensor nodes.

Although 6LoWPAN enables IPv6 connectivity for WSNs, they cannot connect to IPv6 networks since IPv6-enabled devices do not recognize the 6LoWPAN compression, fragmentation, and addressing schemes. Besides, current IPv4 hosts cannot communicate with WSNs, or vice versa, since 6LoWPAN was developed based only in IPv6 protocol. To solve these limitations, the design and construction of a gateway is proposed. It allows a WSN to receive data from and send data to IPv6 hosts through 6LoWPAN, as it is shown in Figure 1. Furthermore, the gateway acts like a bridge between IPv4 hosts and the WSN, receiving clients requests from IPv4 networks, sending a correspondent compressed IPv6 message for the WSN, receiving a response from the WSN, and finally returning the results to the IPv4 clients through IPv4 network. With this approach, IPv4 hosts are capable of obtaining sensing information from the WSN in real time.

Fig. 1.

Interaction between IPv6 and IPv4 hosts and the gateway.

The rest of the paper is organized as follows. Section II reviews available related work on WSN gateways. Section III introduces and describes the gateway architecture and its interactions with the WSN and IPv6/IPv4 hosts. Section IV discusses the implementation of the gateway, followed by the presentation of a laboratory testbed in Section V. Finally, conclusions and further research work are presented in Section VI. II. R ELATED W ORK In the past few years, several gateway architectures were proposed to integrate WSNs and other networks, including the Internet. Steenkamp et al. [4] developed a gateway node to remotely configure and retrieve data from the WSN. Qiu et al. [5] proposed an architecture to exchange data between

978-1-61284-231-8/11/$26.00 ©2011 IEEE


Zigbee sensor networks and client using a web server. Dunfan et al. [6] proposed a gateway architecture for environmental monitoring applications which gather WSN data and make them accessible through Web Service. The drawback of these solutions is that the WSN was implemented based on proprietary protocols and it is not possible for a client to interact directly with the sensor nodes. The use of IPv6 in these networks enables end-to-end communication with every IPv6 devices and reduces the gateway development complexity. With the standardization of 6LoWPAN, some applications were developed using IPv6 in sensor networks. Iiang et al. [7] designed a 6LoWPAN-based WSN application for AC energy usage monitoring. Edge routers were used to route packets inside and outside the WSN and to send ACme nodes data to a data base. Jara et al. [8] developed a 6LoWPAN gateway to collect healthcare information from mobile sensors in a hospital application. A gateway device was also proposed to connect sensor nodes in a disaster scenario with a disaster management center somewhere in the Internet using WAN infrastructure [9]. However, all these solutions have the main focus on the development of the application, and only a short excerpt was used to describe the gateway design. There is a implementation [10] that focus on the design of an IPv6 gateway for wireless sensor networks. In this work, a gateway at the border of a 6LoWPAN-based WSN is developed to provide translation between sensor node short addresses to IPv6 full addresses. However, this solution does not allow IPv4 hosts to obtain sensing information from the WSN. Despite the expectation that IPv6 will replace IPv4 in the next years, this migration will take some time to be concluded. Besides, there are currently many IPv4 hosts connected to the Internet and, with the proposed solution, they will still be capable of receiving or sending data to WSNs. III. G ATEWAY D ESIGN Figure 2 shows the structure of the gateway that establishes communication between end users and a WSN. This architecture is composed by four main elements: i) gateway, ii) IPv6 hosts, iii) IPv4 hosts, and the iv) 6LoWPAN WSN.

Fig. 2.

Structure of the 6LoWPAN gateway.

The gateway is an intermediate component responsible for integrating the 6LoWPAN WSN in IPv6 networks. Its main tasks involve compression and decompression of IPv6/6LoWPAN headers, in order to forward 6LoWPAN messages from the WSN to external IPv6 networks and vice versa, and fragmentation/reassembly of large messages. To do these

tasks, the gateway must have a 6LoWPAN adaptation layer, and it needs to be set up to route IPv6 packets. WSN users can be represented as IPv6 hosts or IPv4 hosts. The former are capable of communicating with sensor nodes directly. Therefore, they can send commands for specific nodes or test whether a node is reachable or not. IPv4 hosts cannot connect to 6LoWPAN WSN directly, due the incompatibility between IPv4 and IPv6. In this case, the gateway acts like a proxy for them, becoming responsible for sending commands to a specific node, using an IPv6 packet, and returning the result back to the IPv4 host, using an IPv4 packet. The 6LoWPAN WSN is a network capable of routing IPv6 packets through 6LoWPAN compression and fragmentation techniques. In order to do this, it is necessary that all nodes in the WSN support the 6LoWPAN stack. As the transport layer protocol, user datagram protocol (UDP) is used because it is lightweight and has low complexity when compared with transport control protocol (TCP). However, TCP can also be used. In this study, the protocol stack of the sensor nodes is illustrated in Figure 3.

Fig. 3.

Protocol stack of sensor nodes in the 6LoWPAN WSN.

A. Gateway architecture As can be seen in Figure 2, the gateway communicates with a 6LoWPAN WSN through an IEEE 802.15.4 base station. In this implementation, it is considered that the base station is an IEEE 802.15.4 enabled sensor node connected to the gateway through USB. The gateway can also be equipped with several network interfaces to receive or send packets to IPv6 or IPv4 hosts. The choice of which interfaces will be used depends on the scenario where the gateway will be deployed or the characteristics of the WSN application. The 6LoWPAN adaptation layer is the component responsible for compression/decompression and fragmentation/reassembly of the packets targeted to the 6LoWPAN WSN or destined to an IPv6 client. The explanation of how these tasks are performed by the 6LoWPAN adaptation layer is out of the paper scope, but good references on the issue can be found in RFC 4944 [3] and Hui’s thesis [11]. A logging solution was coupled to the adaptation layer to register all packets sent and received from the 6LoWPAN WSN. As a result, every communication between the gateway and the WSN is time stamped and stored in a text file. IPv6 hosts communicate with 6LoWPAN WSN through a virtual interface, which is a component that simulates a network device. Thus, the gateway routes packets into the virtual interface and, consequently, to the 6LoWPAN adaptation layer where it is attached when they are addressed to the 6LoWPAN WSN. In the same way, a packet received by


the virtual interface can be routed to the Internet using an Ethernet network or another that may be available. Hence, the IPv6 address prefix of the virtual interface defines the IPv6 address prefix of all sensor nodes in the 6LoWPAN WSN. At the application layer, an IPv4/IPv6 adapter was designed and attached to the gateway, enabling IPv4 hosts to communicate with 6LoWPAN WSNs. The internal structure of the IPv4/IPv6 adapter is illustrated in Figure 4. In order to listen incoming IPv4 connections, an IPv4 socket interface is created when the gateway is started. A command received from the IPv4 host is extracted by the Query Extractor and analyzed to decide if it should be forwarded to the WSN. The Address Table module is used to check whether the destination node exists and it is activated in the WSN. If the command is invalid or the destination node is unavailable, an error is reported to the IPv4 host. After checking the command, an IPv6 packet containing the command is sent to the respective sensor node. When the command is sent, a timer is also started in the Message Receiver. If a reply does not come back in a determined time, an error message is also sent back to the client. The Message Receiver module receives sensor node replies. After that, the result is extracted, encapsulated in an IPv4 message and sent to the IPv4 host.

part of the figure, represented by the symbol “(1)”, shows how the IPv6 client sends a command to the sensor node, whereas the second part shows the opposite. The gateway plays the role of an IPv6 router, with the additional functionality of compression/decompression/fragmentation/reassembly of the IPv6/6LoWPAN packets, and registration of the operations in the log file. In WSN based on multi-hop communication, sensor nodes forward the 6LoWPAN packet to the destination, which will process it. If the WSN is designed for only send information to an IPv6 client, the communication between them is represented just by the second part.

Fig. 5. Message flows between IPv6 hosts, gateway and 6LoWPAN wireless sensor network.

Fig. 4.

Internal structure of the IPv4/IPv6 adapter.

The message flow between IPv4 hosts and the 6LoWPAN WSN is presented in Figure 6. Similarly to the previous figure, the first part shows the transmission of a message from IPv4 hosts to a WSN, whereas the second part shows the opposite. In this case, the gateway acts like a server, waiting for IPv4 hosts connections in a determined port. All the commands from the IPv4 hosts are addressed to the gateway, and not to a sensor node in 6LoWPAN WSN. These commands contain the destination node or the node ID, and the action to be executed by it. They are encapsulated in an IPv4 packet and delivered to the IPv4/IPv6 adapter, in the application layer, which will perform the operations described in the previous subsection. When the command is invalid, the gateway sends an error message to the IPv4 host, avoiding the communication with the WSN. IV. C ONSTRUCTION OF THE GATEWAY

Some mechanisms such NAT-PT [12] have been proposed in order to make IPv4/IPv6 translation at the network layer. Nevertheless, the IPv4/IPv6 adapter was created aiming to evaluate the message contents before sending it to the WSN. If the command sent by the IPv4 client is incorrect, it will not be forwarded to the WSN, avoiding the waste of energy by the sensor nodes. B. Message flow Figure 5 illustrates the exchange of messages between IPv6 clients and the 6LoWPAN WSN through the gateway. The first

In order to validate the architecture proposed in the previous section, a testbed was created and it is depicted in Figure 7. All tests were made in indoor environments. A 6LoWPAN WSN was deployed to gather temperature, light and battery voltage readings. These readings are stored in a database system through an application created apart from the gateway that receives WSN data using IPv6/UDP protocols. Furthermore, IPv6 and IPv4 clients were developed to gather raw sensor data of a specific sensor node whenever requested. This approach was chosen to demonstrate that the gateway supports bidirectional communication.


IPv6 and IPv4 client applications were tested in the client notebook shown in Figure 7. The Ethernet interface card was also used for connection with the gateway. These applications were developed using the Qt framework [15] for the C++ programming language. V. E XPERIMENTAL R ESULTS Upon the activation of the 6LoWPAN WSN, the connectivity between the gateway and the sensor nodes was tested using the ping6 command. Figure 8 shows the results. The connection was successfully established, but duplicate packets were received. It happened because another sensor node was also activated and this created a second possible route to the ICMP echo request.

Fig. 6.

Message flows between IPv4 hosts, gateway and 6LoWPAN WSN.

Fig. 8.

Fig. 7.

Picture of the devices used in the testbed.

In the 6LoWPAN WSN design, five Iris motes running the TinyOS operating system [13] were deployed in a single hop network. As they are compliant with IEEE 802.15.4 standard, a 6LoWPAN protocol stack provided by the TinyOS, called BLIP [14], was installed on the motes and a UDP socket component for transport service was used. MTS300 sensor boards were attached to the motes for sensor data readings. Furthermore, a base station application was installed in one of the Iris motes, enabling it to forward packets to the gateway via USB or to the WSN through radio communication. In the testbed, a desktop computer running the Linux operating system was chosen to be the gateway. An Ethernet interface card was used to communicate with the IPv6 and IPv4 clients, and the base station node was attached to one of the USB ports available at the gateway. The software IP-driver provided by TinyOS was installed to act as the 6LoWPAN adaptation layer. It creates a TUN virtual network interface with a 64-bit IPv6 address prefix to handle IPv6 packets destined to the 6LoWPAN WSN. Header compression/decompression performed by BLIP is compliant with RFC 4944 [3].

Result of the ping6 command to a specific sensor node.

After setting up the WSN, IPv6 clients are able to retrieve the temperature, light and voltage readings from the motes in real time. A simple IPv6 client was created to request these readings from a single sensor node. The results are shown in Figure 9. The user selects the IPv6 address of the respective node and sends it a message through a specific port. When the sensor node receives the message, it gathers sensor readings and send the results back. Finally, the IPv6 client receives the response message and updates the table of readings.

Fig. 9.

IPv6 client application that requests sensor readings.

In order to evaluate the communication between IPv4 clients and the WSN, an IPv4 client application, similar to the abovedescribed application was also developed. In this case, the


client sends an IPv4 message to the gateway containing the identification of the sensor node. This message is processed at the IPv4/IPv6 adapter, which maps the identification to the sensor node IPv6 address, creates an IPv6 message and sends it to the corresponding sensor node. After the corresponding sensor replies to the request, the IPv4/IPv6 adapter converts the IPv6 message in an IPv4 message and sends it to the IPv4 client. Finally, the table of readings is updated. The result of this process is shown in Figure 10.

In order to validate the proposed architecture, a laboratory testbed was created. It allows that simple IPv6/IPv4 clients communicate with a 6LoWPAN wireless sensor network constructed in indoor conditions. The results show that the gateway successfully enables interoperability among them. Furthermore, the gateway was able to handle bidirectional communication between clients and the sensor node enabling also actuation on sensor nodes. As future work, the proposed solution may be extended to a real testbed for environmental monitoring. Therefore, issues involving hardware components, security, deployment, and power management of the gateway will be investigated and integrated in this architecture. Furthermore, the performance between a WSN with proprietary protocols and a WSN with 6LoWPAN also may be evaluated. ACKNOWLEDGMENTS Part of this work has been supported by Instituto de Telecomunicac¸o˜ es, Next Generation Networks and Applications Group (NetGNA), Portugal, in the framework of the BodySens Project.

Fig. 10.

IPv4 client application that requests sensor readings.

In the presented experiments, the gateway was able to establish communication from the IPv6/IPv4 clients to the 6LoWPAN WSN. An application was created in order to show that the inverse communication is also possible. In this application, sensor nodes periodically send sensor readings to a database located at the gateway. Figure 11 shows some readings stored in the database. This approach can be extended to create a Web server, enabling users to monitor a WSN through the Web.

Fig. 11.

Database receiving sensor readings from the 6LoWPAN WSN.

VI. C ONCLUSIONS AND F UTURE W ORK This paper proposed a gateway solution to interconnect 6LoWPAN WSNs with IPv6 and IPv4 clients. The gateway enabled IPv6 hosts to communicate directly with sensor nodes, obtaining sensor readings or testing their connectivity in real time. The gateway also allows IPv4 hosts to exchange messages from the sensor nodes through the created IPv4/IPv6 adapter.

R EFERENCES [1] J. W. Hui and D. E. Culler, “Ip is dead, long live ip for wireless sensor networks,” in SenSys ’08: Proceedings of the 6th ACM conference on Embedded network sensor systems. New York, NY, USA: ACM, 2008, pp. 15–28. [2] J. Hui and D. Culler, “Extending ip to low-power, wireless personal area networks,” Internet Computing, IEEE, vol. 12, no. 4, pp. 37 –45, July-Aug. 2008. [3] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, “Transmission of ipv6 packets over ieee 802.15.4 networks,” September 2007. [4] L. Steenkamp, S. Kaplan, and R. Wilkinson, “Wireless sensor network gateway,” Sep. 2009, pp. 1 –6. [5] P. Qiu, U. Heo, and J. Choi, “The web-sensor gateway architecture for zigbee,” May. 2009, pp. 661 –664. [6] Y. Dun-fan, M. Liang-liang, and W. Wei, “Design and implementation of wireless sensor network gateway based on environmental monitoring,” vol. 2, Jul. 2009, pp. 289 –292. [7] X. Jiang, S. Dawson-Haggerty, P. Dutta, and D. Culler, “Design and implementation of a high-fidelity ac metering network,” in IPSN ’09: Proceedings of the 2009 International Conference on Information Processing in Sensor Networks. Washington, DC, USA: IEEE Computer Society, 2009, pp. 253–264. [8] A. Jara, M. Zamora, and A. Skarmeta, “Hwsn6: Hospital wireless sensor networks based on 6lowpan technology: Mobility and fault tolerance management,” vol. 2, Aug. 2009, pp. 879 –884. [9] K. Mayer and W. Fritsche, “Ip-enabled wireless sensor networks and their integration into the internet,” in InterSense ’06: Proceedings of the first international conference on Integrated internet ad hoc and sensor networks. New York, NY, USA: ACM, 2006, p. 5. [10] G. R. S, Z. Suryady, U. Sarwar, and M. Abbas, “A gateway solution for ipv6 wireless sensor networks,” Oct. 2009, pp. 1 –6. [11] J. W. Hui, “An extended internet architecture for low-power wireless networks - design and implementation,” Ph.D. dissertation, EECS Department, University of California, Berkeley, Sep 2008. [Online]. Available: http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008116.html [12] G. Tsirtsis and P. Srisuresh, “Network address translation - protocol translation (nat-pt),” February 2000. [13] “Tinyos operating system,” Aug. 2010. [Online]. Available: http://www.tinyos.net/ [14] “Blip tutorial,” Aug. 2010. [Online]. Available: http://docs.tinyos.net/index.php/BLIP Tutorial [15] “Qt - cross-platform application and ui framework,” Aug. 2010. [Online]. Available: http://qt.nokia.com/