Enhanced IoT-Based End-To-End Emergency and Disaster Relief System

Abstract

In this paper, we present a new enhancement for an emergency and disaster relief system called Critical and Rescue Operations using Wearable Wireless sensors networks (CROW${}^2$). We address the reliability challenges in setting up a wireless autonomous communication system in order to offload data from the disaster area (rescuers, trapped victims, civilians, media, etc.) back to a command center. The proposed system connects deployed rescuers to extended networks and the Internet. CROW${}^2$ is an end-to-end system that runs the recently-proposed Optimized Routing Approach for Critical and Emergency Networks (ORACE-Net) routing protocol. The system integrates heterogeneous wireless devices (Raspberry Pi, smart phones, sensors) and various communicating technologies (WiFi IEEE 802.11n, Bluetooth IEEE 802.15.1) to enable end-to-end network connectivity, which is monitored by a cloud Internet-of-Things platform. First, we present the CROW${}^2$ generic system architecture, which is adaptable to various technologies integration at different levels (i.e., on-body, body-to-body, off-body). Second, we implement the ORACE-Net protocol on heterogeneous devices including Android-based smart phones and Linux-based Raspberry Pi devices. These devices act as on-body coordinators to collect information from on-body sensors. The collected data is then pushed to the command center thanks to multi-hop device-to-device communication. Third, the overall CROW${}^2$ system performance is evaluated according to relevant metrics including end-to-end link quality estimation, throughput and end-to-end delay. As a proof-of-concept, we validate the system architecture through deployment and extracted experimental results. Finally, we highlight motion detection and links’ unavailability prevention based on the recorded data where the main factors (i.e., interference and noise) that affect the performance are analyzed.

1. Introduction

According to the United Nations Office of Disaster Risk Reduction (UNISDR), the financial impact due to natural and man-made disasters is paramount. It is reported that by 2030, the global average of annual losses due to disasters is forecasted to increase and reach 415 billion USD [1]. These losses surely decrease when a preventive communication strategy is ready to be triggered in a disaster incident.

Indeed, two recent crises showed how important communication alternatives could be during the disaster relief operations. (1) In March 2011, a 9.0 magnitude earthquake caused a tsunami of 30 feet in Japan, the fourth-largest earthquake on record (since 1900), and six nuclear reactors in Fukushima Daiichi plant were affected (two pools of reactors exploded). Japan’s Fire and Disaster Management Agency confirmed that 22,000 people are dead or missing. During the Fukushima disaster, emergency teams and the army were using classic High Frequency (HF) military radio communication without data transmission. Local taxi drivers were coordinating rescue operations using their on-board radio communication devices traditionally used for reservations. (2) In January 2010, Haiti earthquake, of a 7.0 magnitude, was another example of the use of Very High Frequency (VHF) radio communication and satellite phones. During the 24 h after the disaster, disaster task forces did not have a clear vision of the whole situation. Such catastrophes’ relief operations are impossible to conduct without an alternative data communication system immediately deployable and operational.

To that end, we have recently proposed a new routing protocol called Optimized Routing Approach for Critical and Emergency Networks (ORACE-Net) [2]. ORACE-Net is a multi-hop routing protocol, which rates every end-to-end link with regards to its quality (i.e., end-to-end link quality estimation). This metric varies according to the nodes’ mobility, which is the most relevant criteria for reliable emergency systems.

Our previous work [3] was constrained by the following factors: First, there were no real on-body sensors. We generated data for a fictitious network on the mobile nodes as the application layer payload. Second, the initial experimental results indicate that the average disconnections increase significantly when the end-to-end route has more than two hops. Third, as the achieved results were collected in an indoor scenario, several wireless devices were causing interference on the deployed network and consequently reducing the global network performance. Fourth, with reference to one of the most studied problem in network design, the Capacitated Network Design Problem (CNDP) detailed in [4] on the basis of the results in [5], we re-studied the number of deployed nodes with regards to the network traffic uncertainty. Indeed, eight nodes caused an overhead on the routing layer and made the routing process too slow and, consequently, the round trip time was high. Thus, we reduced the number of deployed tactical nodes to four. It is important to note here that this given number of tactical devices must be carefully selected according to the area dimensions. Bertsekas in [6] provides a complete study of the discrete network optimization problems, and Marotta et al. in [7] propose a heuristic that can be used to warm-start the solution process of the solver, accelerating the convergence towards the optimum. The latter proposed solution approach would be perfect for selecting the optimal number of tactical nodes considering traffic uncertainty in discrete network optimization problems. For small and medium-sized networks (up to 25 nodes), an analytical study given in [8] consists of a reference to converge to an optimized network design independently of the traffic uncertainty. Finally, according to the collected results, we were unable to evaluate the throughput accuracy due to the significant number of disconnections and high round trip time delay.

Some of the benefits of this paper are addressing the above limitations and improving the proposed routing approach behavior, in particular the average throughput, the round trip time delay ($RT{T}_{Delay}$) and the end-to-end link quality estimation ($E2E_{LQE}$). This work provides the following main contributions:

• The Critical and Rescue Operations using Wearable Wireless sensors networks (CROW${}^2$) system is one of the rare proof-of-concept implementations of emergency ad hoc autonomous systems. Unlike the detailed works in Section 2, as an application layer payload, we use real-time human vital signs (motion data, heartbeat, magnetometer, etc.) collected from the on-body sensors and pushed to the IoT platform. The evaluation of the proposed system is realized on a real indoor test-bed under realistic conditions. Indeed, we experimentally investigate the mobile devices’ behavior with regards to key performance metrics, such as throughput, end-to-end delay, end-to-end link quality estimation during sensing and disseminating data onto the IoT platform.
• The implemented scenario is a reference experiment for researchers and professionals to evaluate concretely the trade-off between the $\left\{E2E_{LQE},throughput\right\}$ and $\left\{RT{T}_{Delay},jitter\right\}$ in the disaster relief context [9]. Additionally, this work emphasizes the difference between UDP and TCP transport mode performances in disaster relief applications and may be considered as a reference for upcoming application implementations with regards to the bandwidth limitations. Moreover, the realized experiment advises also on the optimal hop count to guarantee the required throughput for the critical applications (medical support, military, firefighters, press and media, etc.).
• The proposed system is back-ended by an IoT platform. Indeed, at the IoT platform level, we prove the system’s capability for mobility pattern recognition and prediction. Then, we discuss the overall interference affecting the mobile devices behavior for the considered indoor scenario. The proposed system shows also a global connectivity status of all of the deployed devices during the disaster relief operations.

The remainder of this paper is organized as follows: In Section 2, we present research works proposed recently related to the emergency relief operation systems. In Section 3, we introduce the CROW${}^2$ system generic architecture. In Section 4, we focus on the implementation technologies in accordance with the on-body and body-to-body communications. In the last section, we describe the experimentation scenario, and we discuss the obtained results. Finally, we conclude by summarizing the paper’s contributions, and we present some promising directions for future research.

2. Related Works

When conducting disaster relief operations, two relevant challenges arise: (i) setting up an immediate emergency wireless network to inter-connect on-the-field rescuers with trapped survivors; and (ii) relaying the emergency network to the Internet and extended networks.

Chen et al. in [10] classify the applications into three main classes: (i) remote health and fitness monitoring, (ii) military and training and (iii) intelligent biosensors for vehicle area networks. Moreover, the authors in [10] discuss a list of research projects and implementations, in particular the Advanced Health and Disaster Aid Network (AID-N) [11], which targets disaster and public safety applications. AID-N uses a wired connection for BAN communication and mesh and ZigBee for the Body-to-Body Network (BBN). Off-body communication in AID-N is fulfilled through WiFi, cellular networks and the Internet. AID-N aims to sense pulse, blood pressure, temperature and ECG. Negra et al. in [12] focus more on the following major medical applications: (i) telemedicine and remote patient monitoring, (ii) rehabilitation and therapy, (iii) biofeedback and (iv) ambient assisted living. The latter work discusses also the QoS requirements for the medical context.

Recently, research trends have aimed at relying on large-scale LTE/4G-enabled networks to inter-connect deployed devices during disaster relief operations. For instance, the authors in [13] introduced the Device-to-Device (D2D) communication scheme to allow user equipment (UE) to communicate within the reachable neighborhood. The proposed scheme sets up an ad hoc wireless network, which relies on the base stations evolved NodeBs (eNBs) at the network startup. Therefore, the solution still depends on the 4G network infrastructure. Definitely, the unavailability of the 4G backbone causes the unavailability of the proposed D2D wireless network.

We cite among, other works, approaches that studied and implemented alert messaging systems, such as the Reliable Routing Technique (RRT) [14] and TeamPhone [15]. Both approaches consist of setting up a smartphone messaging system, which is able to send alert notifications by bridging cellular networks or over ad hoc and opportunistic networks. These proposed systems seem to solve the connectivity issues on-the-field between rescuers and trapped survivors. However, devices in the disaster area may only communicate within one hop. Devices select one next hop only, and no neighborhood discovery is done. Thus, RRT and TeamPhone are not topology-aware and do not consider external network extension with the Internet or other networks.

The authors in [16] propose a localization-based and network congestion adaptive approach called “DistressNet”. DistressNet is claimed to be efficient in congestion avoidance during disaster relief operations; however, this approach is not appropriate for indoor rescue operations due to its localization mechanism, which renders multi-hop algorithms inefficient. The authors in [17] adopted the WiFi Direct standard for the “Emergency Direct Mobile App”, which is intended to divide the set of smart phones into groups communicating in peer-to-peer mode assured by WiFi Direct. One of the devices is selected as the Group Owner (GO) and acts as the access point for its group and as a gateway elsewhere. The rest of the devices act as Group Relays (GR). The network topology formation in this strategy causes an important delay. Additionally, with regards to the high mobility imposed by the emergency context, the network topology update (i.e., GO negotiation and election, GR selection) increases data transmissions latency.

The earliest proposed schemes aim to enhance the on-body devices’ transmission reliability and to improve the energy efficiency. Chen et al. in [18] proposed a novel Cross-Layer Design Optimization (CLDO) scheme. Indeed, the design of CLDO relies on the three lower layers (i.e., PHY, MAC and network layer). Power consumption is firstly optimized by selecting optimal power relays. Then, the remaining energy in leaf nodes is utilized to increase the lifetime and the reliability. An optimal packet size is given for energy efficiency. Chen et al. claim that an inevitably slight overhead accompanies CLDO processing for different factors. First, during network initialization, complex procedures are run. Second, the algorithm uses a certain number of iterations, which influences the overall performance. Third, CLDO lacks the capacity to manage dynamic location situations.

Another approach presented by Tsouri et al. in [19] relies on Dijkstra’s algorithm augmented with novel link cost function designed to balance energy consumption across the network. This latter technique avoids relaying through nodes, which spent more accumulated energy than others. Indeed, routing decisions are made based on the energy optimization. The authors claim that the proposed approach increases the network lifetime by 40% with a slight increase of the energy consumed per bit. However, this work does not fulfill the operational application requirements, which rely on the BBN network for connectivity and routing.

D’Andreagiovanni et al. in [4] introduced a new approach able to handle the uncertainty that affects traffic demands in the Multi-Period Capacitated Network Design Problem (MP-CNDP). Additionally, a hybrid primal heuristic based on the combination of a randomized fixing algorithm was proposed by the authors based on ant colony optimization and exact large neighborhood search. This previous strategy has been improved by D’Andreagiovanni et al. in [20]. The authors adopt a best performance solution based on the min-max approach algorithm, which relies on a combination of a probabilistic fixing procedure, guided by linear relaxations, and an exact large variable neighborhood search, which has been proposed in [4]. D’Andreagiovanni et al. extended their preliminary work [20] by the new Integer Linear Programming (ILP) heuristic to solve the design problem. Furthermore, new techniques detailed in [21] fix the variables expressing routing decisions and employ an initial deterministic fixing phase of the variables modeling the activation of relay nodes. Experiments conducted in this work show that the proposed approach outperforms the existing optimization solvers’ strategies.

Miranda et al. in [22] implemented and evaluated a complete Common Recognition and Identification Platform (CRIP) for the healthcare IoT. CRIP enables a basic configuration and communication standardization of healthcare ‘things’. Security and privacy and health devices’ integration are also covered within this approach. Miranda et al. deployed CRIP according to different communication standards, such as NFC, biometrics (fingerprints) and Bluetooth.

The above proposed approaches are limited for various reasons according to two main classes (O: Operational; T: Technical): (O1) the implemented network is not open to be connected to extended networks (i.e., Internet or military communication platforms); (O2) no command center is considered on-the-field for operations conduct, and therefore, nodes only share their status between each other; (O3) limited services (i.e., alert messages, notifications, etc., only); (T1) nodes in the network have no visibility on the neighborhood and the network topology; (T2) routes (which do not exist for some non-multihop approaches) are neither updated according to the quality of the links’ variations based on the mobility, nor according to energy efficiency and commanding proximity. To summarize the various protocols and systems, a benchmark comparison is given in

Table 1. Recent implemented disaster management systems benchmark. RRT, Reliable Routing Technique.

Protocols and Systems	Wireless Standard	Multi-Hop	Topology Awareness	Infrastructure Dependency	Network Extensibility	Sensing Devices Integration
RRT [14]	N/A	No	No	No	No	N/A
DistressNet [16]	ad hoc WiFi	Yes	Yes	No	No	N/A
Disaster 4 G [13]	LTE/4G	Yes	Yes	Yes	Yes	N/A
Emergency Direct [17]	WiFi Direct	No	Yes	No	No	N/A
TeamPhone [15]	ad hoc WiFi/SMS	No	No	Yes	No	N/A
CROW2 (this work)	ad hoc WiFi	Yes	Yes	No	Yes	Yes

.

3. The CROW² System

The Critical Rescue Operation using Wearable Wireless sensor networks (CROW${}^2$) is a standalone system that enables a wireless ad hoc network in order to connect human beings (rescuers, trapped survivors, civilians, media and press, etc.) to each other, from one side, and to the Internet (or any extended network), from the other side, during disaster relief operations. The overall objectives and challenges to be addressed were initially described in [23].

3.1. History of the CROW${}^2$ System

The CROW${}^2$ system is realized under the CROW${}^2$ project. Among the contributions of the project, notably, we proposed realistic channel models and simulation environment for Body Area Networks (BAN) and Body-to-Body Networks (BBN or B2B) [24]. We evaluated the IEEE 802.15.6 WBAN standard under the realistic channel, radio and mobility models; in particular, the proposed MAC protocols were compared for application-specific design; additionally, new dynamic MAC protocols were proposed in [25,26]. Furthermore, at the MAC layer, the IEEE 802.15.6 standard’s proposed coexistence schemes for co-channel were evaluated in order to investigate the impact of interference from co-located BANs [24].

For that, we studied and compared the effectiveness of distributed and cluster-based architectures for Body-to-Body communications (BBNs or B2B). Then, various routing protocols among different classes including proactive, reactive, geographic-based and gradient-based were simulated and evaluated in [2]. Finally, we proposed a new optimized routing protocol specifically designed for the emergency and disaster relief communication networks. The routing protocol was implemented and evaluated on the WSNet [27] simulator within a realistic disaster mobility pattern. Finally, we implement the entire system on real mobile devices (smart phones and Raspberry Pi devices) for performance assessment within this paper.

3.2. CROW${}^2$ System Architecture

The CROW${}^2$ system is a set of wireless distributed devices equipped with wireless sensors intended to collect real-time data (i.e., vital signs, stress level, locations, ambient intelligence [28], etc.) from Wireless Body Area Network (WBAN) nodes towards a cloud IoT platform. Figure 1 depicts the general architecture of the next generation WBAN. A node in the proposed system could be either: (i) tactical (deployed by rescuers while moving inside the disaster area) or (ii) mobile (carried on-body by rescuers or trapped survivors). Tactical nodes establish a wireless tactical backbone, which extends the network coverage. Mobile nodes, being in proximity of the tactical backbone, could route packets through it as depicted in Figure 2b. We call these tactical devices ORACE-Net Tactical Devices (OTDs). Mobile devices carried on-body rely on both the OTDs and the other mobile devices to route data. Data collected from deployed nodes (i.e., tactical and mobile) are routed through the network towards the Command Center node (CC node). The CC node is a tactical command center deployed as a gateway allowing the emergency network to be linked to wide infrastructure networks (e.g., Internet, military platforms, other emergency networks, etc.). The CC node is also the node through which the operations’ commanders send their instructions to the rescuers and the rescuers send back their feedback to the CC node. It is important to note here that multiple CC nodes could be deployed and activated in the case of single CC failure.

3.3. CROW${}^2$ System Enhancement

As depicted in the layer-based architecture in Figure 2a, CROW${}^2$ consists of two Wireless Body Area Networks (WBANs), or more, connected to a cloud IoT platform through the CC node. Each WBAN node is composed of: (i) a WBAN coordinator, which is a wireless device with advanced energy and communication features, (ii) on-body sensors, which may feature different communications technologies (i.e., Bluetooth IEEE802.15.1, WiFi IEEE802.11a/b/g/n, ZigBee IEEE802.5.4 and WBAN IEEE802.15.6). Sensors are connected among one of the previous technologies to the WBAN coordinator. The BBN routing is assured by the ORACE-Net routing protocol according to the architecture depicted in Figure 1. As the payload at the application layer, we deployed an Message Queuing Telemetry Transport [29] client (on tactical and mobile devices) to push data to the IoT platform.

The CROW${}^2$ system is improved through this work. Compared to our previous work [3], we have installed on-body sensors provided by Shimmer [30]. Therefore, the current system payload consists of real sensed vital sign data from the human body towards the IoT platform. To improve connectivity and mitigate interference, we reduced the tactical devices (OTDs) to four. Additionally, we reduced the number of active indoor wireless access points, since we assume that during the disaster, they will be damaged.

4. CROW² System Implementation

In this section, we explain how the CROW${}^2$ system is implemented. We present first the on-body communication; then, we present the body-to-body communication implementation. Finally, we describe the off-body components’ implementation, in particular the Labeeb-IoT platform.

4.1. On-Body Communication

WBAN covers the communication between the coordinator (which is the main on-body device responsible for communication with other BANs and off-body devices) and the rest of the on-body or under skin sensors. For the CROW${}^2$ system, on-body communication is established between sensors (i.e., Shimmer [31]) and the Android mobile application (i.e., Labeeb-IoT Shimmer Sensing Android App).

Shimmer sensors [31] are sensing devices capable of measuring physical quantities (e.g., acceleration, gyroscope X, Y, Z and angle, triple axis magnetic field, pressure, etc.) and sharing them via Bluetooth. Shimmer provides a Service Development Kit (SDK) that affords the possibility to read real-time data from the sensor by an Android or IOS mobile application. We place the Shimmer sensor on-body as shown in Figure 3. Once connected via Bluetooth, our mobile application (Labeeb-IoT Shimmer Sensing Android App) starts reading data from the sensor and sharing them with the IoT platform.

The Labeeb-IoT Shimmer Sensing Android App is responsible for collecting data from sensors and transmitting them onto the Labeeb-IoT platform using the Message Queuing Telemetry Transport (MQTT) protocol [29]. Figure 4a depicts a screenshot from the live activity of the mobile app with the different real-time sensed parameters before being pushed to the Labeeb-IoT platform.

4.2. Body-To-Body Communication

Body-to-body communications consist of the communications between coordinators (i.e., mobile devices) carried by the rescuers, survivors and also the communications between coordinators and tactical devices, as shown in Figure 2b. The ORACE-Net routing protocol assures routing between CROW${}^2$ devices. With regards to the operational requirements of a disaster relief mission, we assume that the first rescue teams reaching the incident area deploy wireless tactical devices (i.e., OTDs) to enable a wireless ad hoc tactical network on site. We describe these in the two following subsections. The implementation of the ORACE-Net routing protocol is describe for: (i) ORACE-Net Tactical Devices (OTDs) (ii) and ORACE-Net Android Mobile Device (OMD). Both devices are depicted in Figure 5.

4.2.1. Android Mobile Devices

These devices are designed based on the ORACE-Net Android application, which is a mobile app coded in Java and deployed on Android v4.2.2 CyanogenMod 10.0 distribution. This mobile app is dedicated to route data through the emergency network based on the ORACE-Net routing protocol. The ORACE-Net Android application is implemented at the user level as depicted in Figure 6a. It exploits the features of the Linux operating system at the kernel layer through the Dalvik Virtual Machine. Figure 6b depicts the ORACE-Net mobile application components, which are: (1) events listener, (2) broadcast receivers, (3) services, (4) content providers and (5) display activities. The relevant component in the architecture is the events listener, which triggers the rest of the tasks. An events listener is used to catch events (e.g., unicasted, multicasted or broadcasted packets, clicked button, typed text, etc.). In the ORACE-Net Android application, the events listener is implemented as a socket with a multi-cast IP address/Port: 224.0.0.1/10000. A similar socket is implemented with the C-language on Linux for the tactical deployed devices. Received packets through the events listener are handled by the broadcast receivers component to be hulled. Particularly, the content provider allows the application to share the application output with other servers or platforms. Figure 4b is a screenshot of the ORACE-Net mobile app showing the received/transmitted Hello and Advertisement (ADV)packets, the next-hop and the hop count to the CC node.

4.2.2. ORACE-Net Tactical Devices

These tactical devices are implemented based on Linux applications. Indeed, we implemented the ORACE-Net protocol on Raspbian v8.0, a free operating system based on Debian optimized for the Raspberry Pi hardware. Linux libraries are used to operate various protocol events (i.e., socket connections, packets encapsulation, multicasting and broadcasting). We use shell scripts to display the status and statistics and to manage the processes of the protocol. The logging system in the tactical devices is based on the operating system logging service Syslog. Finally, data are pushed to the Labeeb-IoT platform via the MQTT protocol client installed on every OTD.

4.3. Off-Body Communication

Communication between the CC node and the Labeeb-IoT platform covers the off-body communication of the CROW${}^2$ system, as depicted in Figure 1 and Figure 5.

The Internet of Things (IoT) is an emerging technology developed for smart living solutions. IoT solutions are online platforms capable of receiving sensed real-time data from diverse types of devices (including sensors, actuators, coordinators, gateways, etc.) that could be deployed in a vast geographic area. Such platforms are able to collect, store, publish and analyze data according to many parameters. With respect to the MQTT standard [29], the Labeeb-IoT platform uses a publish/subscribe architecture in contrast with the HTTP request/response paradigm architecture. Publish/subscribe is event-driven and enables messages to be pushed by clients using the MQTT protocol. The MQTT client communicates with the broker using predefined methods (e.g., connect, disconnect, subscribe, publish). Labeeb-IoT offers various APIs and RESTful and/or JavaScript Object Notation (JSON) web services.

In our experiments, ORACE-Net devices (mobile and tactical) push continuously and instantly the following data to the Labeeb-IoT platform: (1) device identifier ($Devic{e}_{Id}$), (2) device location ($Location$), (3) device neighbors’ list ($Neighbors$), (4) next-hop to the CC node ($N{H}_{CC}$), (5) $E2E_{LQE}$ and (6) $Ho{p}_{count}$ to the CC node. Data are stored in the platform database and then could be extracted and displayed on Labeeb-IoT as shown in Figure 4c.

5. Experimentation

5.1. Deployment Scenario and Experimental Setup

In our experiments, we consider a disaster scenario in our office, Qatar Mobility Innovations Center (QMIC), in Qatar Science and Technology Park (QSTP). Our test-bed consists of four Raspberry Pi devices (Raspberry Pi Foundation, Cambridge, UK) and two rooted Samsung Galaxy S3-I9300 smart phones (Samsung Electronics Co. Ltd., Suwon, South Korea) with the ORACE-Net routing protocol implemented. The office map is shown in Figure 5. The scenario is as follows: rescue teams access the office from the Back Gate (BG). First, they deploy the CC node in a trusted and safe location (near the entrance gate) where they are connected to the Internet through an Ethernet or WiFi access point (these links could be provided with military microwave or satellite connections). Upon their entrance inside the office, rescuers start deploying tactical devices (OTD) as base stations in order to have the maximum wireless network coverage in the operations area. Two to five OTDs are deployed (as shown in Figure 5). Mobile nodes (smart phones) carried by the rescuers are connected (to the CC node) through the tactical network. Shimmer sensors are connected to ORACE-Net mobile devices via Bluetooth. Since the experimentation area is limited, we reduced the Raspberry Pi’s and smart phone’s WiFi antenna transmission power to 0 dBm. Experimentation parameters and configuration settings are detailed in

Table 2. Experimentation parameters and configuration settings.

General Settings
Parameter	Setting
ORACE-Net Tactical Devices	4 (Raspberry Pi 2) OS: Raspbian v8.0
Mobile nodes	2 (Samsung Galaxy S3-I9300, rooted) OS: Android 4.2.2 CyanogenMod 10.0
Wireless mode	Ad hoc
ESSID	CROW2
Wireless standard	IEEE 802.11n/2.412 GHz (Channel 1)
Transmission power	0 dBm
Experiment area	30 m × 150 m
CC-node connection	Ethernet to Internet Ad hoc WiFi to ORACE-Net network
Experimentation duration	30 min/iteration
Power batteries	- Smart phone: 2100 mAh Li-Ion (3.7 v) - Raspberry-Pi: 10,000-mAh Li-ion (12 v) - CC-node: 12 V power supply
ORACE-Net Protocol Settings
Application layer	MQTT client used for pushing data to the Labeeb-IoT platform
MQTT msgsize/intervals	30 Kb/1 s
Hello/ADV packet size	20/25 bytes
Hello/ADV intervals	3 s
Multicast address/port	224.0.0.0/10000
Shimmer Sensing Settings [30]
Wireless standard	Bluetooth IEEE 802.15.1
Sensed data	Pressure, Temperature, Gyroscope (x, y, zaxis-angle), acceleration (x, y, z), magnetometer (x, y, z), battery level
Device/Body	1 (with multiple sensors)
Buffer [31]	1024 bytes
Message interval	1 s

.

5.2. Results and Discussion

In this subsection, we present the results of the experiment aimed to evaluate the CROW${}^2$ system performance based on the ORACE-Net routing protocol on a real test-bed. To do so, we consider the following metrics: throughput and jitter, End-to-End delay ($E2E_{delay}$) and End-to-End Link Quality Estimation ($E2E_{LQE}$). Throughput is the maximum amount of data processed for sending from the source node (i.e., ORACE-Net mobile device) to the destination node (i.e., Labeeb-IoT platform). “Jitter” is the amount of variation in latency/response time (typically in milliseconds). Reliable connections consistently report back the same latency over and over again. Much variation (or ‘jitter’) is an indication of connection issues. Jitter is a relevant indicator of the network performance because it defines what kind of applications the network is able to support. The $E2E_{LQE}$ is calculated by the ORACE-Net protocol to estimate end-to-end links. The $E2E_{delay}$ is the round trip time delay recorded from the source node to the destination node. This latter metric informs also about nodes’ disconnections. In addition to the above performance metrics, we discuss the collected data from the IoT platform to detect motions and prevent unavailability. Finally, we discuss the overall approximate interference and noise affecting the indoor signal using an academic version of the AirMagnet software.

5.2.1. Throughput and Jitter

The average throughput and jitter recorded on the mobile device over the time during the experiment plotted by UDP/TCP packets is depicted in Figure 7. These results are collected using local Linux logging tools, runnable also on Android (i.e., iptraf and trafshow). It can be seen that the UDP throughput is higher than the TCP throughput. Indeed, the TCP protocol uses connected mode, and it is highly optimized to make reliable use of the link. Therefore, this decreases the throughput and increases the jitter compared to UDP because of the handshake mechanism for the pre-/post-connection process. However, UDP is used for real-time data (e.g., voice and video over IP) and recommended for high-latency links.

Now, with regards to the hop counts, UDP and TCP throughput averages within one hop are 38.8 and 32.71 Mb/s, respectively. Throughput decreases when the hop count increases to reach 18.47 and 9.87 Mb/s for UDP and TCP, respectively, within three hops. According to the authors of [33], a minimum data rate of 10 Mb/s is required for audio, medical imaging and video and hundreds of kbps for other WBAN applications. It is perceived that CROW${}^2$ achieved a real throughput higher than the data rate requirements. It is also important to note that the throughput is expected to decrease significantly starting from four hops based on the behavior shown in Figure 7. The average throughput reduction is accompanied by jitter increase. Recorded jitter values increase also following the same pattern as the throughput. It is important to note here that the maximum accepted jitter for the video streaming application must be less than 40 ms according to [34] and under 30 ms according to Cisco for interactive video (video-conferencing) [35]. Indeed, jitter reaches 9.227 ms with TCP mode within three hops, which stays under the limits of the use of video-streaming. According to the results of throughput and jitter, we conclude that the recommended hop count that guarantees throughput for audio/video streaming and files (i.e., photos, reports, etc.) might be less than or equal to three hops, according to the standard definition video (3 Mb/s). The CROW${}^2$ system assures an acceptable throughput and jitter for routes less than or equal to three hops with regards to the required thresholds cited above.

5.2.2. End-To-End Delay and Link Quality Estimation

Figure 8 depicts the average round trip time delay ($E2E_{delay}$) recorded from the OMD to the Labeeb-IoT platform versus $E2E_{LQE}$. It can be seen that the $E2E_{LQE}$ decreases with the rise of $E2E_{delay}$. Indeed, $E2E_{delay}$ exceeds 1 s when $E2E_{LQE}$ reaches less than 0.7 between 1030 and 1070 s. The same behavior appears between 1155 and 1175 s. $E2E_{LQE}$ and $E2E_{delay}$ are proportional. An $E2E_{LQE}$ equal to zero means that the link is disconnected; the same link shows an infinite $E2E_{delay}$. Figure 8 shows also the effectiveness of the metric used in the ORACE-Net routing protocol (i.e., $E2E_{LQE}$). The route update mechanism based on the optimal $E2E_{LQE}$ then is validated by our experiment. Indeed, ORACE-Net prevents the link quality degradation, then looks for a better route with optimized link quality, delay and disconnection avoidance.

5.2.3. Motion Detection and Link Unavailability Prevention

On-body sensors carried by the rescuers push data regularly to the IoT platform. Based on the type of recorded data, we can extract several human behaviors. For instance, gyroscope data recorded and depicted by the Labeeb-IoT platform in Figure 9 inform about human mobility. Sensors placed on the hand detect and send gyroscope variations tending to zero when the human has stopped and is not moving. Small variations may be distinguished in the first part of the figure when the human is walking and higher variations of the gyroscope when he/she is running. Figure 10 depicts the gyroscope angle variations over more than 2000 s. The gyroscope angle informs about the movement direction. Furthermore, some vital sign information may help the command center to switch rescue teams and send support there; we cite for example magnetometer and heart beat variations reflecting the stress level. All collected data on the IoT platform side could provide also the connectivity status for every deployed node, as can be seen in Figure 10. Disconnected nodes inform about the unavailable intermediate links or network over-saturation.

5.2.4. Interference Score and Noise

As given by Table 2, the CROW${}^2$ ad hoc network is configured on WiFi Channel 1. Figure 11a shows a sample of the interference score recorded indoors along 25 s. Interference varies from 0–53 dBm (as the maximum peak recorded). We assumed during our previous work [3] that the overall network achievements were affected by the indoor interference caused by WiFi access points, microwaves, etc. Thus, we have recorded the interference score and noise to verify whether these facts affect the overall behavior of the emergency network or not. The recorded interference is important compared to the Received Signal Strength Indicator (RSSI), so the signal is notably affected by the interference. However, the overall interference score is likely to decrease because the wireless infrastructure devices and access points are mostly out-of-order post-disaster. Figure 11b shows a sample of real-time variation for signal and noise strength as a percentage for Channel 1 during 50 s. The noise floor is given by the red curved waves, and the Signal-to-Noise Ratio (SNR) is depicted in yellow color. The figure shows that the signal strength varies between 3 and 50%. To conclude, interference clearly affects the RSSI and, then, the overall performance of the system. Interference is an important factor that must be considered in indoor emergency operations.

6. Conclusions

In this article, we presented the CROW${}^2$ system, an IoT end-to-end emergency and disaster relief system. CROW${}^2$ is implemented based on the ORACE-Net routing protocol, especially designed for the disaster context. To evaluate the performance of the proposed system, we deployed the routing protocol and the payload applications on two different platforms (Raspberry Pi and Android smart phone). We equipped a rescuer with on-body sensors connected to a smart phone via Bluetooth. The entire system uses an IoT platform as a back-end to push, record, publish and analyze sensed data. The performance of the system is investigated according to the following relevant metrics: average throughput and jitter, average end-to-end delay and average link quality estimation. We emphasized also motion detection and links’ unavailability prevention based on the collected data. Finally, we sampled the indoor interference score and noise to estimate its impact on the system behavior. It can be concluded that the CROW${}^2$ system outperformed the given requirements for wireless body-to-body communications in terms of throughput and jitter. However, being effected by the indoor environment, the behaviors of $E2E_{LQE}$ and $E2E_{delay}$ are moderately fair. This article validates a few research works, especially simulation-based ones, with a real implementation and experiment. Further, it highlights also the limitation of other theoretical proposals, specifically those adopting low power consumption wireless standards for body-to-body communications. This work could be considered as a reference to researchers for real wireless body-to-body implementation using a dedicated routing protocol for the disaster relief context. It is also a reference for routing and technology standards’ adoption for similar use cases. As future works, an outdoor experiment could be conducted to provide a complete overview of the system behavior in different situations. Furthermore, a study supported by implementation could be provided to advise on the optimal number of tactical devices for both indoor and outdoor scenarios. An autonomous disaster mode in wireless devices may be proposed based on the ORACE-Net routing approach.