Implementing a Distributed WSN Based on IPv6 for Ambient Monitoring

Traditionally, Wireless Sensor Networks (WSNs) are used for monitoring an extensive area. In these networks, a centralized server is usually used to collect and store the sensor information. However, new distributed protocols allow connections directly to the WSN nodes without the need of a centralized server. Moreover, these systems are able to establish communications among heterogeneous networks. The new protocols strategy is focused on considering several WSNs as a unique distributed one. This way, a user of the system is able to analyze a process under study as a whole instead of considering it as a set of different subsystems. This is the case in the evaluation of migratory waterbirds' environment. In this case, it is usual to deploy several WSNs in different breeding areas. They are all interconnected and they measure different environmental parameters. However, this improvement in the data access flexibility may result in a loss of network performance and an increase in network power consumption. Focused on this problem, this paper evaluates different communication protocols: distributed and centralized, in order to determine the best trade-off for environmental monitoring in different migratory areas of waterbirds.


Introduction
Nowadays, the number of electronic devices present in our environment is increasing continuously. The technological improvements and cost reduction of these smart devices provide a significant increase in their capabilities, among which are their connectivity. The Internet of Things (IoT) [1] is a paradigm which is gaining importance in the current scenario of modern telecommunication. This concept represents a novel scenario in which we are completely surrounded by smart devices. These devices can interact among them, providing different information or adding capabilities to the network [2]. An important group of these devices is formed by the Wireless Sensor Networks (WSNs) [3].
A WSN consists of many small devices deployed in a physical environment [4]. Each device, called a node, has special capabilities such as communication with its neighbors, sensing, and data storage and processing [5]. All nodes make a mesh network of devices that can collaborate among them allowing the implementation of distributed solutions to solve complex problems. Due to this, WSNs have many applications [6], among which environmental monitoring as an area where the potential impact is huge [7]. It allows monitoring an area at a low cost and little need of human presence. However, they have some technical requirements, such as the following.
(i) Autonomy. Batteries must be able to power the nodes during the whole network lifetime. Despite typical WSNs using low power radio devices (such as IEEE 802.15.4 [8] radio transceivers), the radio transceiver spends most of the energy consumption in a node in typical monitoring applications. Due to it, the network has to reduce data traffic as much as possible.
(ii) Robustness. In this kind of application, human maintenance is usually difficult because of the hardness of the terrain. Therefore, it is important to design robust networks that are adaptable to any incident.
(iii) Flexibility. The network must to be able to add, move, or remove nodes to meet the application requirements. The network must automatically detect the changes, organizing the communications in consequence. WSNs are normally used in environmental monitoring applications to collect information through the sensors incorporated into each node. There is a special device called "Base Station" whose mission is to request and store the network information [9]. The Base Station generally acts also as a gateway, allowing the user to access the collected data through an infrastructured network, such as Internet.
To monitor an environment, the nodes of a WSN construct mesh networks that allow communications between devices. Due to the special characteristics of WSNs, such as their reduced energy available or low bandwidth, WSNs require the use of adapted protocols to establish communications. Nowadays, routing protocols with low power consumption continue being a main issue for WSNs. Several routing solutions have been proposed in the literature [10], mainly focused on energy consumption [11,12], security issues [13,14], or fault-tolerant capacity [15].
However, these proposed communication algorithms are classically designed to solve communication problems in an ad hoc manner. They solve particular scenarios, but they do not provide a general framework that allows intercommunication between heterogeneous networks with different communication requisites.
As an alternative to this classical WSN scheme and directly related to the IoT philosophy, some authors are currently proposing the use of IPv6 implementation over WSNs [16,17]. This implementation are focused on reducing as much as possible the requirements of the Base Station, that is, using the Base Station only as a gateway between the two networks [18] and without intelligence. The use of IPv6 provides a common framework where additional protocols can be added, maintaining a basic interoperability between networks. IPv6 framework for low power consumption systems (also known as 6LoWPAN) is currently a main research area. Some authors are proposing new uses of 6LoWPAN technology [19,20]. Other authors proposed additional schemes, for example, to compact addressing between devices [21] or to increase security [22,23]. Other authors, as classical architectures, focused on provided efficient routing protocols [24,25].
As can be seen, 6LoWPAN adds the IPv6 advantages of robustness and flexibility to WSNs, increasing the connectivity of the nodes. This implementation not only solves the retrieving information problem from the Base Station but it allows the access to every node in the WSN from anywhere in Internet [26]. Thanks to 6LoWPAN each node can be uniquely identified [27]. However, because IPv6 was not initially designed to operate over WSNs, it also has some constraints [28]. It could not make it interesting for all applications.
In this paper, we propose a comparison between IPv6 protocol implementation versus classical WSN communication protocols. This evaluation is focused on its use for monitoring application.
The rest of the paper is organized as follows. Section 2 describes the application of our interest. A description and some common WSN protocols are described in Section 3. These protocols are evaluated in Section 4. Finally, Section 5 introduces a comparison between the evaluated protocols, before describing the final conclusions and remarks in Section 6.

Application Description
The evaluation of flooding areas, especially the estimation of flood level, is very important in monitoring waterbird colonies. Some studies relate the status of waterbird habits to the population of these kinds of birds [29]. Moreover, a change in the behavior and pathways of migratory waterbirds has been observed by biologists in the last decades [30], as can be seen in Figure 1. Due to this, biologists are very interested in this kind of environmental monitoring.
To capture that information, we already have a WSN deployed into the Doñana Biological Station [31]. Doñana is a wildlife reserve protected by the Spanish Government (located in the south of Spain). It covers a huge area of about 542 km 2 with little human interference through its entire history. This network is called ICARO [32] ("Inteligencia Computacional Aplicada a Redes de Observación, " a Spanish acronym which means computational intelligence applied to monitoring networks). ICARO has been built based on TelosB [33] nodes and TinyOS [34] operating system. Each node ( Figure 2) has a meteorological station with the ability to measure temperature, rainfall, wind speed and direction, and humidity. These nodes use a TelosB platform for processing and transmissions. Finally each node gets energy from a solar power system. These nodes use available information to predict the flood level of the marsh areas of Doñana [35].
ICARO network architecture is a centralized one, where the flood level estimation of each node is sent to a Base Station and stored later in a server. Node information is only accessible offline, and data is stored in a external database.
However, an effective monitoring of the habitat of migratory species requires deploying several networks in each International Journal of Distributed Sensor Networks breeding area. Therefore, we are designing new WSNs (i.e., ICARO2, ICARO3, etc.) to cover new areas (the new design of the improved nodes is shown in Figure 3). One of our goals is to provide a unified interface for all the ICARO networks. This set of networks is called eSapiens, a Spanish acronym that means intelligent acquisition and processing system integrated in natural environments.
Although we can keep the ICARO architecture (for reusing the hardware and the deployments), this scheme suffers several problems: ICARO depends on several harddefined bottle necks. All information goes through a sole Base Station. Inside nodes are not accessible from outside nodes. Therefore, it is not possible to access data directly from sources, but it is in a data server.
A new approach is chosen for eSapiens: flatten all hierarchical structures, allow direct communication to every node ( Figure 4) in all networks, and keep historical data in each node. To embrace this approach, a change to a more complete communication protocol is necessary.
One advantage obtained from a more complete communication protocol is that it makes easy the communication between nodes of different networks, redirecting the information through a heterogeneous networks. Therefore, a node in an ICARO network can exchange information with another node of another ICARO network. It is depicted in Figure 5. Additionally, the information stored in a node can be retrieved by a PC using a standard web-page browser, where a user can access individually and transparently each device of the different ICARO networks into eSapiens infrastructure.

WSN Communications in Environmental Monitoring
Typically, WSN protocols allow mesh typologies of nodes with multihop structures. Thanks to this, it is possible to monitor huge areas with low cost and low power devices. Moreover, it requires the use of low power radio transceivers. Typically, these radio transceivers are based on the IEEE 802. 15.4 Standard [8]. This standard defines the physical and the MAC layers as is detailed in Figure 6. Based on this standard, several protocols have been defined. These protocols are necessary to enable the communication between nodes with multiple hops. Each node is required to know its neighbors and what routes it can use to send a message to another node, without sight line. Due to this, WSN protocols used for environmental monitoring require two classes of messages.
(i) Network Messages. These messages are used to maintain the network. It is used to discover node neighbors and obtain the routing table.
(ii) Information Messages. These messages are used to transmit useful information for application purposes.
In environmental monitoring, these messages typically contain sensor measurements.
Both types of messages are needed; however the use of network messages increases the power consumption and increases the occupation index of the channel with information not directly related to the proposed application. Moreover, obtaining a high reliability requires the use of big headers. Therefore, to reduce the power consumption it is necessary to obtain a trade-off between the required reliability of the network and the amount of additional information sent between nodes.
Currently, there are different solutions for routing protocols in WSNs. Communication protocols designed specifically for WSNs, such as Collection Tree Protocol or ZigBee, are less flexible but their implementation over WSNs has less power consumption. On the other hand, IPv6 implementation, such as BLIP, takes advantage of the information messages to update the routing table.
In this section, we are going to describe some common WSN protocols, highlighting their advantages and disadvantages to use on the proposed application. types of nodes are identified: a coordinator, routers, and end devices. The application layer ZigBee defines an application support sublayer (APS) on which the denominated end points (similar to TCP/IP ports) are defined. An application or object can be defined for each end point. However, there is a reserved end point for the ZigBee device object (ZDO) which is responsible for communicating the binding tables to the network. These tables keep information about the network nodes' presence and their services. In the ZigBee network the services define the profiles whereby the devices are grouped in clusters (devices within the same profile).

Collection Tree
Protocol. The Collection Tree Protocol (CTP) [37] is a tree-based collection protocol. In this protocol, a single or small group is shown as sink nodes (tree roots) which are the main branches of the tree (connectivity between nodes). Based on this tree, when each node sends a message to a sink node, it looks for the most suitable neighbor node, using a routing gradient. With this technique, the protocol is responsible for network management discovering the neighbors and estimating the best transmission path (minimizing the number of hops and the global consumption). This is possible because each node has a table with a list of the best neighbors to reach a root node. The CTP is common in data collection applications where nodes periodically send information to a root node (typically called Base Station). A specific implementation of this protocol is CTP Noe [38].  a mechanism to easily translate a protocol like HTTP to a less complex one. It allows integration between constrained networks (such as WSNs) and standard Internet networks.

6LoWPAN.
CoAP is a single protocol over UDP (as is shown in Figure 8) and is subdivided into two sublayers. The first one, the CoAP message sublayer, is responsible for dealing with UDP (CoAP operates over UDP) and defines four types of messages: Confirmable, Nonconfirmable, Acknowledgement, and Reset. The second one is the request/response sublayer. It contains methods and response codes. An implementation of this protocol is libcoap which provides the same methods as the ones used by HTTP: GET, PUT, POST, and DELETE. However, there is specific implementation of these libraries for WSNs [45] with a more reduced set (only GET and PUT) which is typically sufficient for most applications.

Experimental Evaluations
In this paper, we are going to compare different protocols which allow us to use IPv6 in a WSN (a network of TelosB nodes with TinyOS Operating System). Additionally, some other well-known protocols are included in the comparison. A developed test application sends the same application data using each studied protocol. A sniffer captured the whole wireless traffic between nodes. To acquire data traffic, our testbench comes with a USB dongle 802.15.4 sniffer (IA OEM DAUB1 2400 by Adaptive Modules Ltd.) [46] and "Perytons Protocol Analyzers" [47] (Figure 9) software to analyze the packets detected.
The network used to test the protocols is made of 3 nodes with the architecture described in Figure 10.  A limitation of output power in the transceiver of nodes (down to −12 dB) allows the experimentation in a close controlled scenario. It causes each node not to have full connectivity with the rest of the nodes. Due to this, in some cases nodes have to route messages through other nodes. Same coverage is used for all the experiments.
All the IPv6 dependent protocols use the Berkeley implementation for WSNs (6LoWPAN).
Our test application is developed to imitate the behavior of the proposed flooding estimation application.
(i) Every node is cyclically acquiring environmental information.
(ii) Once per day, a WSN node executes the data aggregation algorithm, to predict flood level.
(iii) Only if the flood level is different from the last estimation, it sends a message to the Base Station with the new estimation.
Based on this simple architecture, a count of sent bytes per data has been done. In all measurements, it only showed size in bytes of any layer above MAC layer. To get real size of messages, it is necessary to add the MAC size. Usually WSNs based on IEE802.15.4 radio transceiver use short addresses (9 bytes) to reduce the overhead. When some protocols depend on responses in MAC layer (i.e., wait for MAC ACK), those messages are shown too.
Moreover, all experiments done in both topologies show an -hop communication which is an equivalent to times 1hop. The overhead of frames for the evaluated protocols does not increase with multiple hops. So, the results only show the last transmission (1-hop).
All the expressed results are obtained without considering fragmentation. To maintain a low power consumption, it is necessary to reduce as much fragmented messages as possible because it increases the required transmissions with their associated ACK and therefore it increases the overhead.

Static Ad Hoc Implementation.
This implementation is used only for comparison purposes. An Ad hoc implementation is specific to application and network. The efficiency of an ad hoc implementation is maximum because its topology is fixed in programming time and routing tables are static. Due to this, these networks do not require network messages to obtain the topology neither to provide information to help the routing of the packets.
Against that, it needs to know beforehand the location of the network nodes. A change in its topology requires reprogramming all nodes. Neither of these problems have been considered here.
This kind of implementation is not very common due to the difficulty in the evaluation of topologies in networks.
Despite their lack of flexibility, these implementation have very few overheads and do not require additional messages to build a routing table. So, it is considered as an ideal case and it is used as reference to compare other routing protocols. With the proposed testbench, we talk about two different protocols: a one similar to UDP without ACK (1 byte to destination, 1 byte to source and payload) and a one similar to TCP with ACK (2 bytes more with source and target to send ACK) (see Table 1). If both protocols do not coexist, it is not necessary to have an extra byte to identify the protocol.
This implementation does not allow communication between devices. Moreover, they cannot acquire information from a remote WSN. Therefore, all the acquired information must be stored in a central server. Figure 11. In this case, a remote node is sending a nonrequested message. ZigBee requires the use of ACK messages at link and MAC layers. Figure 12 shows a ZigBee frame. As can be seen, it has a reduced overhead, similar to CTP one. Table 2 sums up the size of messages transmitted with ZigBee. These messages do not increase in size with multihop transmissions.

ZigBee. The structure of ZigBee transmissions is depicted in
ZigBee allows direct communication between devices of a network, but it does not allow to redirect messages with a remote network. ZigBee has not been designed to allow fragmentation.

Collection Tree Protocol Implementation.
Collection protocols are useful to gather information from different sensors to a central device in a network, generally to the Base Station. This is the typical application in environmental monitoring where all the information gathered in the Base Station is stored in a database.
Collection nodes only store a reduced number of routes. They try to send information through an optimum path to a Base Station. If the nodes in the path are busy, they search for other paths, always trying to minimize the cost (estimated as number of hops).
This implementation does not allow communication between devices. The network only maintains routes to the Base Station. Moreover, it cannot acquire information from other remote WSNs. Therefore, all the acquired information must be stored in a central server. Figure 13 shows a generic frame of a collection message. Its overhead is reduced.
Typical CTP schema is depicted in Figure 14. This protocol only sends ACK at MAC layer, maintaining the number of exchanged messages low. Table 3 sums up the size of messages transmitted with the evaluated CTP protocol (from TinyOs Stack). CTP messages do not increase their size in multihop nodes.    Figure 15. TCP transmission require a complex message negotiation. This negotiation ensures the integrity of the information, but drastically increases the overhead. Messages vary in function of the application. For example, the scheme to transmit a webpage over 6LoWPAN is depicted in Figure 16.
As can be seen, a webpage structure increases the number of required messages even more. Due to this, in transmission with constrained communications, such as that used in WSNs, it is better to use transmissions without a protocol in application layer, that is, sending the information after establishing the socket connection.
TCP allows communication between devices, whether they are in the same network or not. Moreover, the accessibility of each device in a TCP network allows the user to request information stored locally. So, transmission is only by demand.
TCP BLIP permits message fragmentation. If a message is higher than the maximum payload, BLIP automatically fragments it. To do this, it adds fragmentation header to the first fragment (4 bytes). This header is added between the MAC header and the 6LoWPAN header.
The rest of the fragments are sent only with MAC header and a 5-byte fragmentation header that identifies the full message. The rest of the headers in these fragments are avoided to reduce the overhead as much as possible. Figure 17 depicts a standard payload message, using TCP frames without header compression. TCP frames require the use of big headers. It considerably reduces the size of the payload or fragments the message. Table 4 sums up the size of messages with a TCP connection without header compression. As can be seen, the number of transmitted messages and the number of bytes sent in communications are high. TCP requires a high number of transmissions. Firstly, it requires to start explicit connection with an SYN message. After that, we need to send the message with the payload. Finally, it is necessary to close the connection explicitly. Moreover, TCP requires the use of the ACK messages link layer, in addition to the ACK in MAC layer. Due to this, the TCP protocol is in general too costly to be used in devices with limited bandwidth, such as WSN devices.  header compression is lower than that of messages without it. However, their headers are still too high for a protocol with constrained maximum message size, such as in 802.15.4. Table 5 sums up the size of transmission messages in a TCP connection with header compression. As can be seen, TCP header compression reduces the overhead, but it does not reduce the number of transmissions.

TCP BLIP with Header Compression.
As conclusion, the TCP over 802.15.4 radio transceiver requires a large number of transmissions and it has a big overhead, even with header compression. TCP is only useful with not so frequent communication with reduced payload,    where the system reliability is more important than its power consumption.

UDP BLIP Implementation.
In contrast to TCP connection, UDP does not have negotiation to ensure correct transmission. Due to it, UDP needs to send less messages. Therefore, it is not reliable (i.e., there is no guarantee that sent UDP messages or packets would reach their destinations at all). Figure 19 shows a scheme of an UDP connection. Despite its less overhead, the lack of reliability of UDP messages is a drawback, especially in wireless communication with a nonnegligible packet error rate, such as 802.15.4 communications.
Due to this, to increase the reliability in WSNs using UDP, it is necessary to add a communication protocol at the application layer, such as CoAP or an adaptation [48] of IEEE1451 Standard [49].  Like in the TCP BLIP implementation, if messages are longer than the available payload, they are fragmented. This fragmentation has the same structure of TCP communications: first fragment adds a header fragmentation (4 bytes) to the original header. The rest of the fragments only have fragmentation header of 5 bytes without any other header.
As TCP protocol, UDP allows communication between devices, whether they are in the same network or not, and it also allows to store information locally, transmitting it only on demand to a user. Figure 20 summarizes a UDP frame between two nodes, without multihop, without header compressions or security.

UDP BLIP without Header Compression.
As can be seen, it has less overhead than TCP, but it does not ensure the receiving of the message. Table 6 summarizes the number of bytes required to send a message between nodes with UDP without compression.
UDP without compression significantly reduces the overhead in comparison with TCP connection.   Figure 21 summarizes a UDP frame between two nodes, without multihop, with header compression and security.

UDP BLIP with Header Compression.
As can be seen, it has very low overhead, especially if short MAC addresses are used. Table 7 summarizes the number of bytes needed to send a UDP message between nodes with compression.
The overhead of UDP communications is slightly higher than the case of CTP networks, but it allows more flexibility. As it was mentioned before, its main drawback is the lack of reliability. 4.6. CoAP Implementation. CoAP implementation add a minimal negotiation to UDP messages with the purpose of increasing the reliability, but maintaining the overhead low. Figure 22 shows the structure of a CoAP negotiation.
The use of Piggy-backed messages prevents the use of a link level ACK, reducing the traffic. Moreover, it uses an implicit socket connection. Due to this, it does not require additional messages to establish or close connections. Like TCP or UDP, CoAP is able to communicate between devices which allow transmittng data on demand.

CoAP without Header
Compression. The overhead of most common CoAP messages are depicted in Table 8 and Figure 23.
This protocol is a good trade-off between reliability and overhead. It does not increase too much the overhead, but establishes messages to ensure a correct transmission. Figure 24 depicted a CoAP frame with header compression. As can be seen, this protocol has a reduced overhead.    Table 9 sums up the results obtained with the most common CoAP messages used in 802.15.4 WSNs. It is important to consider that CoAP implementation for TinyOS is still a work in progress, and not all the methods are currently available.

CoAP with Header Compression.
The reliability and extra cost are similar to CTP protocols or ZigBee, but CoAP provides more flexibility.
In conclusion, CoAP is presented as an interesting compromise between the reliability of TCP and the reduced overhead of UDP. Its overhead is reduced, but nonetheless, it is higher in the case of CTP messages.

Comparison between Protocols
This section describes a comparison between the different tested protocols.

Routing Overheads and Evaluation of Power Consumption.
Routed messages between networks require the use of headers. But headers increase the number of total sent bytes in  the network. Therefore, it is necessary to search for a tradeoff between size of header and reliability. Table 10 shows the number of messages interchanged in order to send a packet of data (5 bytes) and total number of sent bytes (including our payload of 5 bytes). The ratio between total number of bytes versus payload is the overhead factor. Overhead factor (also shown in Table 10) is related directly to energy consumption. The time of transmission or, in other words, the number of sent bytes are the main influence on energy consumption. Bigger overhead implies bigger energy consumption for the same payload, as energy consumption is the main issue in Wireless Sensor Networks [11] because of limited autonomy in nodes.
To evaluate the energy consumption of sending a packet, it can be estimated as described in [35]: where is time of transmission and is power of emission.
At the same time, there is some energy consumption in the receiving node. It can be estimated as where on is the time that its transceiver is active and is the power consumed in reception (41 mW [33]). on depends on energy saving policies on each protocol.
So, if we only consider energy losses in transmission time, that energy can be modeled as : where is the transmission rate of the platform (i.e., = 250 kb/s) and is the total amount of bits sent in communication process. Based on data of Table 10, Table 11 shows estimation of energy losses in transmission calculated on each protocol. The overhead factor depends on the length of headers and payload. As payload increases, the overhead will decrease. Figure 25 shows the evolution of the overhead factor versus payload size for each tested protocol.
As can be seen, the use of an ad hoc solution has reduced headers, but this system provides almost no services. The use of complete TCP/IP headers only justified sending large messages. UDP and CoAP offer good ratios of overhead with a limited set of services.
To estimate total global consumption, it is necessary to add all the messages of network construction. This amount depends on protocol and topology and they are arranged based on the design time of the application. Table 12 depicts the latency between the different evaluated protocols. Latency is obtained measuring the time between starting a request of new information and the time when the node receives this information.

Latency.
TCP latency is several times higher than the rest of the evaluated protocols. UDP and CoAP have similar latency, with CTP having the lowest latency (approximately, 5 times lower than UDP). Despite of the extra information added by CoAP, it presents a similar latency to UDP.

Evaluation of the Comparison.
According to the above results, the main advantages and disadvantages of the evaluated protocols are depicted in Table 13.
For a distributed application, such as the proposed flood level monitoring for waterbirds, 6LoWPAN based protocols are the best trade-off between flexibility and power consumption.
Among the evaluated protocols based on 6LoWPAN, CoAP is the best option for constrained networks. This protocol has advantages such as reliability, but it maintains a low overhead. Moreover, its last draft [50] provides techniques to reduce power consumption like using local proxies or sleeping radio transceiver.  The use of local storage and direct communication between devices reduces interchanged messages to Base Station and they avoid the maintenance of a central server. The maximum storage of information depends on the memory of platform and the number of nodes. That is, TelosB nodes have an external Flash of 1 Mb, and for flood level estimation, we need 5 bytes in each change (4 bytes with a timestamp + a byte with the estimated flood level). In a worst case scenery with a daily flood level modification, every node can retain up to 7 months of information.

Conclusions
This paper proposes eSapiens, a distributed WSN for monitoring flood level in several breeding areas of migratory waterbirds. The used data aggregation algorithm allows the use of local storage. Thus it avoids the use of a central server, simplifies the architecture, and reduces the cost. Moreover, the proposed infrastructure requires communication between remote devices. This architecture offers a trade-off between power consumption and reliability.
Focusing on these issues some algorithms have been evaluated. These algorithms can be divided into two families: classic centralized algorithms and fully distributed algorithms.
According to our conclusions, current fully distributed algorithms, such as IPv6 over WSNs, provide flexibility without too much extra cost. For all this, eSapiens has chosen CoAP as best option for its IEEE 802.15.4 WSN devices.
Currently, the authors are developing additional WSNs to spread in other flooded areas where waterbirds live.