Performance analysis of 6LoWPAN protocol for a flood monitoring system

Abstract

The internet of things is a disruptive technology that has been applied as a solution to problems in many fields of monitoring environmental variables. It is supported by technologies such as wireless sensor networks, which offer many protocols and hardware platforms in the market today. Protocols such as 6LoWPAN are novel, so this work focuses on determining whether its implementation on TelosB mote is feasible; these would be placed on an experimental deployment for a particular scenario of flash floods in a sector known as “La Brigada”, in the city of Barranquilla. This proposal has not been evaluated in Colombia for this type of application, and no similar work has been done for this type of scenario. For the evaluation of 6LoWPAN, a deployment with two end nodes and a sink node has been designed, due to the monitoring section under study; 5-min tests are proposed where through round trip time traffic PINGv6 packets are generated back and forth (Echo) between a sink node and two end nodes. The results are based on the evaluation of metrics such as delay and ping packet request/response rate. The performance of these metrics is subject to test scenarios that vary according to distance, packet size, and channel scan time. Two routing options, static or dynamic, are also proposed for this application case. The tests performed yielded results in terms of better performance in the test scenarios for packets with an average size of 120 B and channel monitoring times of 1024 ms. Likewise, the use of the TelosB platform was validated as a viable and innovative option for a monitoring scenario to flash floods in short stretches of the city of Barranquilla—Colombia. This study is important because it can provide information on the use of the TelosB platform as a valid solution for similar application scenarios; furthermore, the tests performed can be replicated in similar studies to evaluate congestion, power consumption, routing, topologies, and other metrics. This study is providing a road map for the research community to follow the simulation scenario to apply the test to their own studies. This work also provides the guidelines for similar researchers to monitor the flood in their own regions and then compare their results with this study.

1 Introduction

The internet of things (IoT) is growing thanks to the development of technologies such as wireless sensor networks (WSN). These provide connectivity to smart devices from anywhere. In addition, it has enabled the evolution of many research fields such as smart hospitals, smart traffic, smart cities, environmental monitoring, and smart decision-making systems. This wireless connectivity also increases the data traffic in IoT solutions [1,2,3]. To transmit the data, the network needs some new platform, technologies, network architectures, and network protocols to route the data [4,5,6]. The wireless network has many protocols; one of these protocols is the IPv6 for Low Power Wireless Personal Area Networks (6LoWPAN). This is defined by the Internet Engineering Task Force (IETF) in the RFC4944 [7]. It is very vastly in use of IPv6 protocol over IEEE 802.15.4 [8] due to its compatibility with wireless sensor nodes [7,8,9].

In IoT, the research community has developed many environmental monitoring applications like Early Warning Systems (EWS) for catastrophic events to improve the life quality and lifesaving [9,10,11]. In the case of the EWS, a monitoring system for the flash floods, that occur in the rainy season in the city of Barranquilla—Colombia, is the scenario of application to this work. This problem has occurred for many years in this city. Therefore, this work is supported by the University of the Coast at a zone known as "The Brigade" for generating alerts when this event is occurred [12, 13]. The existing studies include damages of floods in terms of cost and life. We find few studies about the EWS system for Barranquilla—Colombia, focused on flood warnings. Due to the above, we focused on a research problem to determine if the use of the 6LoWPAN protocol on the TelosB platform is viable for implementation in the application scenario described above. For this purpose, we performed different types of tests with three nodes using the 6LoWPAN logical addressing method and two routing protocols. This allowed us to analyse the implementation of 6LoWPAN in a scenario for flash floods monitoring in the area of "La Brigada"; this is shown in Fig. 1a (area of interest where the flash flood occurs). This is important because there is no focused work with 6LoWPAN and its analysis in flash flood applications. Therefore, the aim of this work is to evaluate the use of 6LoWPAN in terms of wireless information transmission, taking into account the geographical location of the sensor nodes in the flash flood application scenario.

Fig. 1

A, B Flash foods Barranquilla City. B, C Flash food in “The Brigade” zone

In this context, a key aspect is to study the performance of 6LoWPAN considering different routing methods, static and dynamic. To compare the 6LoWPAN performance, the present work is based on the TelosB platform [14]; including TinyOS as an embedded operating system and the Berkeley Low-Power IP stack (BLIP) [15] as 6LoWPAN network stack. Another key aspect of this work is the use of additional libraries, such as IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), for dynamic IPv6 routing [16], and Low-Power Listening (LPL) for energy-saving purposes. The most important results in this work focus on the methodologies for evaluating the performance of 6LoWPAN with the established metrics; these allowed defining another key aspect of this work, as the type of routing and channel scan time to improve energy savings with the LPL protocol. Furthermore, is possible to analyse the network performance according to the select packet length. Criteria are also provided for the selection of the TelosB platform and 6LoWPAN applied a monitoring network for flash floods in the "The Brigade" area of the city of Barranquilla. This study is important because it can provide information on the use of the TelosB platform as a valid solution for similar application scenarios; furthermore, the tests performed can be replicated in similar studies to evaluate congestion, power consumption, routing, topologies, and other metrics. This study is providing a road map for the research community to follow the simulation scenario to apply the test to their own studies. This work also provides the guidelines for similar researchers to monitor the flood in their own regions and then compare their results with this study.

The rest of the paper is organized as follows: Sect. 2 provides an overview of the most relevant work about 6LoWPAN applications and metrics for WSN. Section 3 describes the materials and methods, as well as the test scenarios used. Section 4 presents the results and its analysis. Finally, Sect. 5 describes the most relevant conclusions of this paper.

2 6Lowpan: applications and metrics for WSN

2.1 Emerging technologies for early warning system

This section aims to show the importance of the context of the application scenario of this work. For this purpose, the global importance of having studies that allow validating technologies for EWS is reviewed. An important reason for its use is to mitigate the impact on the population of natural hazards in vulnerable areas. EWS is an important tool for hazard risk management, and many applications require this solution to cope with phenomena such as tornadoes [17, 18], floods [19, 20], landslides [21, 22], flash floods [23, 24], tsunamis [25], and the like. Therefore, the use of emerging technologies in EWS is relevant and is a challenge for researchers. Those technologies consist of innovations such as IoT, new protocols, and low-cost platforms, which have been implemented in solutions for monitoring systems and IoT. It is important to highlight the use of EWS and alternative technological developments that can propose solutions to the monitoring of hazardous conditions for the population.

For example, in Surabaya—Indonesia, an IoT-based EWS has been developed to collect the garbage through robots and be able to monitor severe and hazardous conditions; this prototype can monitor the battery level information and operation to the robot; the ESP8266-12 module allows the WIFI communication with an android platform [26]. In Malaysia, an IoT system is proposed for a flood EWS; this system consists of a wireless sensor network, wind sensors, and cellphone images that are sent to the cloud using Zigbee and 3G for monitoring and warning to the users [27]. In Pakistan, a low-cost flood EWS is developed using Raspberry Pi platform, video camera, temperature and humidity sensors, energy system (battery and solar panels); this system sends GSM data to Web dashboard, showing the level water [28]. In Italy, a WSN is used to estimate landslide; for this, the RF signal is analysed in the nodes of the WSN and establish its location in drawing a grid map; the change in the location to the node can indicate that a landslide is present by soil movement [29].

For this work, the flash floods are the principal context, because have caused material and human losses in recent decades in the Barranquilla city, also causing congestion of traffic and dragging sediments by the flow. There are thirty zones where flash floods occur due to the absence of sewerage over the city; although some canalizations work has been carried out in some cases, it is important to have systems based on emerging technologies that can generate warnings for the vulnerable population. This motivated different studies from the “Universidad de la Costa” to generate solutions to this problem in Barranquilla [30,31,32].

2.2 6LoWPAN and applications

The use of emerging technologies for environmental applications is important for evaluating its possible application in EWS. These studies can be complemented by the analysis of IPv6 applications for constrained environments such as the technique 6LoWPAN, in order working on top of the IEEE 802.15.4-standard (see Fig. 2). Between the set of wireless protocols [33], 6LoWPAN shows a major increase in use in several fields like the web or military applications [34, 35] or even as a preferred communication method for embedded operating systems such as TinyOS or ContikiOS [36].

Fig. 2

RPL-6LoWPAN network stack

Previous studies on the performance of 6LoWPAN have been carried out in high precision agricultural applications [37], high mobility networks to analyse latency and energy consumption of nodes (NEMO) [38]; other studies have analysed network congestion problems using proprietary algorithms [39], security in point-to-point networks [40], the impact on medical applications in high mobility environments [41, 42] or in-depth analysis of energy consumption between nodes. [43, 44].

For this work, it is important to establish metrics and factors that allow describing the 6LoWPAN performance. For this purpose, the review of the literature to different performance metrics and the factors that produced incidence in they were consulted. For 6LoWPAN implementation, some similar works focused on high-precision agriculture have been developed using the TelosB platform. TelosB is used with different sensors jointly with TinyOS, RPL-6LoWPAN, and LPL. In this work, different time intervals (512, 1024, and 2048 ms) and their impact on the battery lifetime have been tested; as a resulting have an improvement using a 2048 ms interval [45]. Other relevant work is focused on the carbon-cycle measuring in the Peruvian Amazon jungle, using the same platform [46]. Other applications use the same platform, testing instead of TinyOS, ContikiOS [47]. This revision is important for selecting the TelosB platform how a tool for tests in this work. Likewise for the time selection in the tests with the LPL protocol.

Another similar work has analysed the performance of different platforms covering a wide spectrum among the uses of various microcontrollers like Waspmote, TelosB, Arduino, and radios like XBee, MicaZ, and iMote2. These works also apply different metrics and parameters, such as the delay in the message reception or the throughput using different payloads [48]. Researches in the field of MAC layer protocols [49] have reviewed different metrics such as the duty cycle, latency, and throughput, looking for the optimal use conditions in ContikiOS [50]. The above studies are important for the selection of metrics, such as latency and jitter. Similarly is defined platform TelosB and framework TinyOS for the use in traffics tests on the proposed scenario. On the other hand, RPL, as a part of 6LoWPAN, is being widely studied [51], not only in the field of Wireless Personal Area Networks (WPANs), but also in the field of Body Area Networks (BANs) [52, 53]. Thus, the comparative between RPL and static routing is an important factor for the analysis in the tests.

Similar work has focused on the use of 6LoWPAN through performance metrics to describe congestion in an experimental network, using the Cooja tool simulator; for this purpose, a new algorithm is proposed to improve congestion, energy consumption, and performance over the deployment of nodes [54]. Also, another work focuses on improving routing in 6LoWPAN-based networks; for this purpose, several metrics are tested using the Cooja simulator tool; metrics such as packet delivery ratio, energy consumption, and control message overhead are tested through an experimental network [55]. But the work is not working with the same scenario of simulation for flood monitoring and our proposed algorithm. Thus, our work is quite novel and efficient for the 6LoWPAN protocol followers and research community. We also do not find any research that works with this protocol for flood monitoring in Colombia.

In our work, we are studying 6LoWPAN as an alternative for future use in a wireless warning system application scenario; this will be focused on a flash flood event within an area known as "La Brigada" in the city of Barranquilla. Different types of traffic and hops scenarios have been considered, as established in the previous literature review. For the implementation of our system, the well-known TelosB platform has been used together with TinyOS, BLIP 2.0, and LPL.

3 Mitigation of system

3.1 Materials and methods

This section presents the scenarios and tests carried out; WBS (Work Breakdown Structure) was the methodology applied to “breakdown” this work into steps and activities, to its development. This work is based on the TelosB platform, which is a low-cost and well-known platform in the academic world. This platform also offers support to the IEEE 802.15.4 and 6LoWPAN through the use of TinyOS, BLIP, RPL, and LPL. To capture and analyse traffic, like the Internet Control Message Protocol version 6 (ICMPv6), Wireshark [52, 53, 56] has been used. The traffic for these tests is ICMPv6 (Internet Control Message Protocol for the Internet Protocol Version 6) packet, which has been generated using the tool PINGv6. As a result, the Round Trip Times (RTT) of the nodes is received on the sink, measuring Ping Request/Reply rate and packet delays for the performance analysis. Figure 3 shows a flowchart for the implementation of 6LoWPAN on the TelosB platform and the basic tests for the initial connectivity.

Fig. 3

Steps by configuration the TelosB platform

In Fig. 3 for the implementation of RPL, "Makefile" file of each sensor mote is modified by adding a code or flag as follows:

$$PFLAGS \, + = \, - DRPL\_ROUTING \, - DRPL\_STORING\_MODE \, - I\$ \left( {TOSDIR} \right)/lib/net/rpl$$

This code allows the RPL libraries to be associated when compiling, according to the path that is established, where for the particular example we have: /lib/net/rpl.

Next, the following lines are added to the UDPEchoC file of each sensor chip:

#ifdef RPL_ROUTING

components RPLRoutingC;

#endif

No modifications are made to the "PppRouter" application, since by default the files related to it are already configured with the necessary values to work with the RPL.

For the implementation of LPL, the following is added to the "Makefile" file:

$$CFLAGS \, + = - DCC2420\_LOW\_POWER\_LISTENING$$

The previous flag allows enabling the LPL mode in the motes, both in the sink node and in the end nodes. In addition, a flag is added to indicate that every few milliseconds the mote performs a scan of the channel, to verify if there is traffic on the network that is directed to it; this is done with the following instruction:

$$CFLAGS \, + = - DLPL\_SLEEP\_INTERVAL = 1024$$

The above instruction shows a particular case with a channel scan every 1024 ms. In addition, the code allows to vary the time that the speck lasts scanning the channel using the following flag:

$$CFLAGS \, + = - DMAX\_LPL\_CCA\_CHECKS = 800.$$

For this particular case, 800 ms is the time in which the chip scans the medium to analyse the signal it is receiving.

3.2 Scenarios

The scenario presented in this paper is based on three nodes and a host computer, which are the materials for all tests performed. The topology used is point-to-point and involves a node working as sink and two as sensor nodes. Figure 4 shows the proposed scenario, where node 1 jointly with the computer acts as a sink and node 2 acts as a router.

Fig. 4

Snapshot of the scenario tested

This work considers the Line-Of-Sight (LOS) as a reference to deploy the nodes. Thus, the network has been designed to avoid the LOS between nodes 1 and 3 in order not to generate a directed routing scheme (i.e. the 2-hops route used in the tests). Both static and dynamic routing methods have been considered for this network. Table 1 shows IPV6 addressing used and nodes location.

Table 1 IPV6 addressing for 6LoWPAN network

3.3 Test description

The tests performed were based on sending PINGv6 messages; these corroborated the connectivity between nodes through traffic generated for 5 min. The requests and responses were captured and reviewed by means Wireshark tool on the sink node. Network performance is studied based on the packet size and the distance between nodes. Table 2 shows all the different tests carried out.

Table 2 Performance tests for 1- and 2-hops 6LoWPAN networks

This evaluation obtained in these tests is relevant for the proposed scenario since they help to determine the correct configuration of packet sizes to be sent and the sending times; this implies obtaining a better energy consumption of the TelosB platform with the use of the 6LoWPAN protocol.

The metrics analysed in the present work are shown below and are based on previous works [56,57,58], considering those, which generate delays in the network and changes in the packet delivery rate.

• Ping request/reply rate

• RTT average time

• RTT average delay

• Sending packet delay

• Average Jitter

3.3.1 Ping request/reply rate

This metric firstly measures the ping request/reply rate between the sink and node 2 (one hop); for the applied tests payload, LPL time interval configuration and distance between both nodes are varied. After this test, a second analysis has been performed using all nodes in the network and analysing the performance with two hops; LPL time slot configuration is also varied and in addition, routing type in all the applied tests. The size of all packets in the second test was set to 1133B.

This metric compares the number of echo pings generated from the sink and the response obtained by the nodes; this is an indicator of the echo ping messages that get responses from the nodes during the test. Traffic monitoring has focused on nodes 2 and 3. It is important to highlight the number of packets obtain in the test interval (during five minutes).

3.3.2 RTT average time

To calculate this metric, the average ping echo time was measured, i.e. the time of sending the ping packet generated by the sink and the time of the response sent by the destination node. Previous theoretical analysis indicates that packets may suffer delays, due to the processing time, which is associated with routing tasks between the network. It may also be affected by delays resulting from the application of LPL. Average RTT time is measured as the average RTT times obtained in a 5-min test; furthermore, similar criteria to those used in the ping request/response test were applied for this test [59].

3.3.3 RTT sending average delay

RTT sending delay is measured as the elapsed time between sending two packets with acknowledging receive (Echo Ping), consecutively. This metric is calculated because in some cases the packets sent from the sink do not produce any reply from the nodes. Then, RTT sending average delay is the average time elapsed between sending two packets with acknowledging receive consecutively, using the same factors and conditions as in Ping Request/Reply rate analysis. RTT delay is measured in the sink by the information received in the Wireshark tool [60, 61].

3.3.4 Sending packet average delay

Average packet sending delay has been analysed as the time elapsed between the sending of two pings generated from the sink to a destination node; in this case, it is not considered whether there is successful reception of the acknowledgment message. The tests performed have been with conditions similar to the previous ones.

3.3.5 Average jitter

Average jitter has been measured from the comparison of packet sending delays. Subsequently, the jitter obtained in each test was averaged.

4 Results and discussion

Figures 5 and 6 and Tables 3 and 4 present the results corresponding to the tests previously explained. The most important values have been highlighted in the table for each test.

Fig. 5

Results obtained in the 1-hop tests

Fig. 6

Results obtained in the 2-hops tests

Table 3 Average results of 6LoWPAN performance in one hop test

Table 4 Average results of 6LoWPAN performance in two hops test

4.1 Ping request/reply rate

Figure 5A shows the results of the ping request/response rate considering different distances, packet size, and the use of the LPL protocol. These results show that there are more ping packet acknowledgments without applying LPL; that is, responding to 288 ping requests, for 5 min, in the worst case (40 m). However, by not applying LPL, it is interpreted that the node will be constantly scanning the channel, resulting in energy losses. Using LPL with a time interval of 1024 ms and a packet size of 1133 Bytes (maximum ping packet size), successful ping response rates are obtained between 73 and 109, for 5 min; this can be considered a high rate of packets received in this time interval. This packet rate for environmental or agricultural monitoring applications is very important and shows sufficient information capture for an EWS. It should also be noted that the packet size has an impact on the rate of successful responses to the ping command, being more than twice as high when using a packet size of 120 B (standard ping) than when applying a packet size of 1133 B. Interestingly, increasing the distance does not show any high impact on the results for this scenario and configuration.

Figure 6A shows the ping requests and responses generated from the sink to nodes 2 and 3, using static and dynamic routing (two-hop scenario). This scenario would be with the deployment of the network according to the stretch of the stream to be monitored in the future. On the nodes, LPL has been applied with a configuration of 0, 512, and 1024 ms, with the 1024 ms configuration being the best in terms of energy consumption; in addition, the tests have been performed with maximum packet size, i.e. with 1133 B packets. Figure 6A shows that the routing type does not affect performance, in this particular application scenario. Another interesting fact is that node 2 answers all ping requests on average, for the 0 ms LPL configuration; on the contrary, node 3 answers half of the ping requests for the same scenario and configuration. However, 58 ping responses are received for routing with RPL and 158 ping responses for static routing. Similarly, as in the one-hop scenario, the number of packets received is optimal, for a time interval of 5 min in an EWS application. The LPL configurations with 512 ms and 1024 ms show similar ping acknowledgments, with no significant difference between the tests on nodes 2 and 3. The lowest tests (1024 ms) show that for node 2 ping acknowledgments are received between 132 and 141 for static and dynamic routing, respectively. Similarly, for node 3, ping acknowledgments are received between 60 and 57 packets during 5 min, for static and dynamic routing. This indicates a sufficient rate of packets received to detect environmental changes in the EWS application.

Finally, the 1024 ms setting for LPL is shown to be an important aspect that does not affect the performance of the amount of information that needs to be received for the operation of the EWS in the scenario presented.

4.2 RTT latency

Figure 6B presents the RTT duration results for a 2-hops scenario, showing no significant difference in the results derived from the routing type. With 0 ms LPL-configuration, the overall performance in terms of RTT duration is shorter than with the other configurations. Figure 6B also shows differences of 0.3 s for node 2 and 0.5 s for node 3 with a 512 ms LPL-configuration; however, the RTT duration is even higher for a 1024 ms LPL-configuration. These test results show that node 3 has a higher RTT, almost being twice as much as the duration as node 2 shows, in all the 2-hop tests carried out, considering all the different configurations.

Tables 3 and 4 show the average RTT latencies. Figure 5B shows similar results for the different distances tested in the 1-hop scenario. From Table 3 and Fig. 5B, it is clear that an RTT with a smaller packet size shows a shorter duration, due to the shorter processing time between routes. There is no significant difference for RTT duration (Echo ping) with packet sizes of 120 B, using times of 0 and 1024 ms in LPL configuration. In contrast, RTT duration increases up to 50% for sending 1133 B packets with LPL setup times of 1024 ms. This indicates that the best results are shown in the test for sending 120 B size packets with LPL setup times of 1024 ms; it is also observed that distances have no impact on the throughput analysis.

Figure 6B presents RTT duration results for a 2-hop scenario; it shows that there are no significant differences in the results when varying the routing type. With the 0 ms LPL configuration, the performance in terms of RTT duration is lower than other configurations; however, there will be higher power consumption. Figure 6B also shows a difference of 0.3 s for node 2 and 0.5 s for node 3 with the use of 512 ms LPL configuration; RTT duration increases with 1024 ms LPL configuration. These results indicate that node 3 has a higher RTT; its duration on average is twice that obtained by node 2 for all the 2-hop tests performed, in all different configurations. The results when applying a configuration time of 1024 ms for LPL do not offer a significant difference from those of 512 ms. The application of a 0 ms LPL time setting results in an increase in terms of power consumption, but it also results in improvement of RTT time duration. Thus, between a 512 ms LPL time setting and a 1024 ms LPL time setting, RTT duration differences are not significant, so it would be better to use a 1024 ms LPL setting to improve power consumption.

Figure 5C presents the results in terms of RTT sending delay from the sink for 1-hop scenarios, showing a shorter delay in tests with a setup time of 0 ms in LPL. It can be seen that the delay increases slightly with distance by 0.2 s between 10 and 40 m scenarios; this small difference does not affect the performance of the tests.

Figure 6C shows the results of the average RTT sending delay from the sink for a 2-hop scenario, with no significant differences between the routing types. For an LPL configuration with 0 ms times, RTT sending delay is generally shorter than for other LPL time configurations. In this scenario, the difference in sending delays between nodes is significant, reaching 2–3 s. For LPL configurations at 512 ms and 1024 ms, no significant difference in RTT sending delay from the sink is observed. As in other tests, an LPL setting of 1024 ms results in better energy consumption.

4.3 Sending delay and Jitter

Tables 3 and 4 show the packet forwarding delay and jitter results for the 1-hop and 2-hop scenarios with different configurations. Figure 5D presents the packet sending delay for the 1-hop scenarios, showing times of 1 s for all distances considered, regardless of packet size. Therefore, the distance has no impact on the packet sending delay.

Figure 5E shows the jitter for the distances evaluated in the 1-hop scenario. Distances do not show variations in the scenarios, but the packet size has an impact on very short times of 3–4 ms, which have been associated with inter-path processing time. No significant differences are seen between LPL time settings at 0 ms and 1024 ms for sending packets with size 120 B. The higher jitter is seen sending packets of size 1133 B and using an LPL configuration with times of 1024 ms.

Figure 6D presents the packet sending delay for 2-hop scenarios, confirming that the routing type has no impact on packet sending delay. For both routing types, the LPL configuration with a time of 0 ms shows a lower delay than the LPL configuration with a time of 1024 ms; however, the lower LPL time will imply higher power consumption.

As for jitter, Figs. 5E and 6E show similar jitter in 1-hop and 2-hop scenarios. For the 2-hop scenarios, changes in distances show no significant impact on jitter results. For these tests, the shortest jitter is shown with an LPL configuration of 0 ms; while for other LPL configurations, they do not show any significant difference in the variation times. The difference in jitter between a 0 ms and 1024 ms LPL configuration remains below 4 ms; this indicates that 1024 ms LPL configuration is more suitable for reducing power consumption. Again, the type of routing does not affect the overall performance in terms of jitter.

5 Conclusions

Based on the 1-hop tests performed, the use of 1024 ms as channel scan time setting (LPL setting) is recommended because network throughput does not decay and power consumption is reduced. It has been observed that the packet size has an impact on the analysed scenarios, resulting in the use of the 1133 B payload in longer delays and optimum ping request/response rates. Ping acknowledgment response rate for 2-hop scenarios is adequate for an EWS application; a reception of more than 50 packets in a time of 5 min is achieved for node 3 and 120 or more packets for the node with 1133 B packets and 1024 ms LPL configuration.

A 1024 ms LPL configuration results in a good compromise between loss and energy consumption. Routing types do not present any significant difference for different metrics analysed in this paper. Packet sending delays are not significant between the 1-hop and 2-hop scenarios; this metric remains below 5 ms, so there is no significant impact on network performance. Inter-node distances do not appear to be significant for network performance, at least not for the scenarios and configurations considered. It is recommended to use LPL configuration with 1024 ms times for the 2-hop ones, to obtain an overall improvement in terms of energy consumption.

The values obtained in the RTT sending delays and ping request/response rate tests indicate that sufficient packets are received at an acceptable time rate in a 5-min interval. This amount is sufficient for environmental applications, as is the case for the application scenario, an EWS.

Finally, the TelosB platform is a system that allows its use for data transmission evaluation. Although it is not a robust system, its use for flash flood monitoring is possible; it should be complemented by the implementation of sensors such as rain gauges, given its easy integration. Currently, there is no evidence in the literature of works that apply the TelosB platform and 6LoWPAN method for flash flood monitoring systems.