Ben Dhafer
email: [dhafera@qmic.com

Arbia

Muhammad Mahtab Alam

Rabah Attia
email: rabah.attia@enit.rnu.tn

Elyes Ben Hamida

A Novel Multi-hop Body-to-Body Routing Protocol for Disaster and Emergency Networks

Keywords: Public Safety Networks (PSN), wireless Bodyto-Body Networks (BBN), Multi-Hop Routing Protocol, Performance Evaluation, WSNet simulator, Optimized Routing Approach for Critical and Emergency Networks Simulations

In this paper, a new multi-hop routing protocol (called ORACE-Net) for disaster and emergency networks is proposed. The proposed hierarchical protocol creates an ad-hoc network through body-to-body (B2B) communication between rescue members and the command center. The on-body coordinators establish forward routes towards a command center, whereas, the command center builds reverse routes towards these nodes. The Routing tables are optimized based on real-time endto-end Link Quality Estimation (LQE) metrics (i.e., end-to-end signal strength level and end-to-end hop count). We evaluate our proposed protocol with other widely used protocols in the disaster context which are covered by the routing classes (i.e., Reactive, Proactive and Geographic-based). The evaluation is based on a realistic disaster mobility trace. The results show that the proposed protocol outperforms the other studied protocols in terms of packet reception rate and energy consumption. The proposed ORACE-Net protocol increases the body-to-body network lifetime and reliability.

I. INTRODUCTION

The worldwide climate change and the growing increase in disasters are not only impacting severely on human lives but also causing significant economic losses. According to the latest statistics from United Nations International Strategy for Disaster Reduction, 1.7 billion dollars were lost in disasters worldwide only in 2013 [START_REF]Global assessment report on disaster risk reduction 2013[END_REF]. The role of emerging wireless communication technologies is critical because often during the disaster the existing network infrastructures are either completely damaged or over-saturated [START_REF] Baldini | Survey of wireless communication technologies for public safety[END_REF].

In Public Safety Networks (PSN), the data traffic is bidirectional which means the Command Center (CC) collects needed information from the deployed rescue teams and the rescue teams receive back real-time instructions to execute from their CC. From application perspectives, PSN may offer the possibility to transfer real-time video streaming and live data (e.g. physiological vital signs, position, orientation, mobility, etc.) through Internet. Thus, there are various purposes and requirements at the application layer.

Regarding the existing PSN, there are several challenges. In addition to the radio technologies and their inter-operability, coexistence and energy consumption issues, routing is also an important and critical challenge for the delay sensitive emergency networks [START_REF] Arbia | Behavior of wireless body-to-body networks routing strategies for public protection and disaster relief[END_REF]. For PSN, multi-hop communications is inevitable while routing the information from the incident area to the command center. In this context, it is expected that Wireless Body-to-Body Networks (BBNs) which is an evolution of traditional Body Area Networks(BAN), can act as an ad-on to the existing PSN networks [START_REF] Hamida | Wearable body-to-body networks for critical and rescue operations, the crow² Project[END_REF], [START_REF] Alam | Surveying wearable human assistive technology for life and safety critical applications: Standards, challenges and opportunities[END_REF]. It creates an adhoc network which enables fast response and effective disaster management for monitoring the health conditions, movements, status of the rescue members and the victims [START_REF] Arbia | Data dissemination strategies for emerging wireless body-to-body networks based internet of humans[END_REF].

Typically the existing routing techniques and protocols for PSN are limited by; a) Rescue members or deployed nodes are only able to transmit the information towards the command center node [START_REF] Lu | Networking smartphones for disaster recovery[END_REF], whereas, bi-directional network connection is not supported; b) Inefficient beacon enabled and broadcast of hello packets to discover and update the neighbor nodes; c) Inability to communicate with the standard networks (e.g. Internet), in addition to limited services being provided (i.e., emergency messaging and nodes status sharing [START_REF] Lu | Networking smartphones for disaster recovery[END_REF]); d) MANET routing protocols (which are often used in PSN) consider the entire network as flat (i.e., all the nodes of the network have the same level of privilege), while disaster networks need to be hierarchically organized (logically or operationally) in order to the communication based on its priority.

In this paper we propose a new hierarchical multi-hop bodyto-body optimized routing approach targeted for critical and emergency networks (ORACE-Net) with an aim to improve the connectivity of the multi-hop body-to-body routing for PSN. Specific contributions are explained as follows. In contrast with existing routing protocols, ORACE-Net relies on the broadcast of advertisement (ADV) packets (for neighborhood discovery) which avoids the transmission of control overheads such as route request and route reply messages. At first by using the ADV packets, the protocol establishes forwarddirection communication paths from the entire network to the command center, and then we introduce reverse routing path establishment for bi-directional routes (i.e., from the command center to the rest of the network) based on the data packets transmission. This helps in optimizing the overall communication overheads and increases the network performance. The proposed protocol continuously update the routes based on the link quality estimation (i.e., received signal strength) and the reliable shortest path estimates in a mobile environment. Finally, packet oriented network simulator is exploited for extensive performance evaluations and comparisons. The simulations are performed under realistic assumptions with the disaster mobility models. The obtained results show that ORACE-Net outperforms the conventional routing approaches both in terms of packet reception rate and energy consumption. Specific contributions of this paper are listed as follows: 1) We present ORACE-Net approach which is based on the Endto-End Signal Strength Level (E2E SSL ) to optimize routing in disaster networks. 2) We simulate and evaluate the protocol in realistic disaster scenario and scheme: dimensions of the area, disaster mobility pattern, MAC and PHY layers (pathloss, TX-power, modulation, etc.). 3) We compare our protocol behavior to eligible routing candidates from each routing class (proactive, reactive and geographic-based).

II. RELATED WORKS

With regards to routing the information in emergency and public safety networks, there is hardly any dedicated routing standards. Recent works are mainly focused on three main approaches: a) To investigate the existing standards behaviors in the disaster and emergency context [START_REF] Quispe | Review: Behavior of ad hoc routing protocols, analyzed for emergency and rescue scenarios, on a real urban area[END_REF], [START_REF] Arbia | Behavior of wireless body-to-body networks routing strategies for public protection and disaster relief[END_REF]; b) To enhance the existing standards to fit disaster networks requirements [START_REF] Saha | Designing delay constrained hybrid ad hoc network infrastructure for post-disaster communication[END_REF], [START_REF] Laha | An energy efficient routing protocol for device-to-device based multihop smartphone networks[END_REF]; c) To propose new approach and compare it to existing standards to evaluate their performance [START_REF] Lu | Networking smartphones for disaster recovery[END_REF], [START_REF] Varun | Ensuring reliable communication in disaster recovery operations with reliable routing technique[END_REF]. However, these new approaches are very basic and limited in terms of real disaster characteristics.

Latest research trends are tending towards evaluating the performance of enhanced existing conventional routing protocols. However, some recent studies (such as [START_REF] Lu | Networking smartphones for disaster recovery[END_REF], [START_REF] Laha | An energy efficient routing protocol for device-to-device based multihop smartphone networks[END_REF]- [START_REF] Group | Delay tolerant network 2[END_REF]) are adapted to the network dynamic aspects for viable and effective disaster operation. For example, localizationbased and network congestion adaptive approach called "Dis-tressNet" [START_REF] George | Distressnet: a wireless ad hoc and sensor network architecture for situation management in disaster response[END_REF] is very interesting to avoid congestion in the network during disaster operations. However, this approach creates network sparseness which impacts localization and renders multi-hop algorithms inefficient especially in the indoor rescue operations. Further, recent proposed approaches such as Reliable Routing Technique (RRT) [START_REF] Varun | Ensuring reliable communication in disaster recovery operations with reliable routing technique[END_REF] and TeamPhone [START_REF] Lu | Networking smartphones for disaster recovery[END_REF], on principal, are based on Greedy Perimeter Stateless Routing (GPSR) [START_REF] Karp | Gpsr: Greedy perimeter stateless routing for wireless networks[END_REF] and Delay Tolerant Network version-2 (DTN2) [START_REF] Group | Delay tolerant network 2[END_REF] concepts respectively. The authors claim that RRT approach is better in terms of delay, however, it has significantly higher energy consumption because of unnecessary broadcast packets. On the other hand, TeamPhone is limited in terms of service, in fact it considers only basic emergency messages with up to only one hop neighbors based on ad-hoc and opportunistic networks. Some other varieties of DTN protocols are efficient in terms of packet delivery rate, however, delay is a big drawback that makes DTNs not suited for our context. Finally, the concept of multihop smart-phone networks based on WiFi-Direct is proposed in [START_REF] Laha | An energy efficient routing protocol for device-to-device based multihop smartphone networks[END_REF]. An energy efficient cluster-based routing protocol, called Quasi Group Routing Protocol is used. In addition, virtual hierarchical distributed cluster algorithm for smartphone networks is introduced. The simulations demonstrate that the proposed protocol can save significant amount of energy. However, the proposed approach is limited to a basic simulation environment without considering the impact of the mobility.

With regards to the behavior of the existing standards which were designed for general purposes, such as Mobile Ad-hoc Networks (MANET), Geographical Location based, or Wireless Sensor Networks (WSN) routing protocols [START_REF] Arbia | Behavior of wireless body-to-body networks routing strategies for public protection and disaster relief[END_REF]. Typically, proactive and reactive multipath routing Protocols are commonly referred as the link-state and distance vector algorithms, hence their classification is based on network discovery and the routing information update mechanism [START_REF] Sharma | Routing protocols for ad hoc mobile wireless networks: A comparative study[END_REF]. Proactive routing protocols create and maintain continuously their routing tables and are also called table-driven. In this routing class, nodes keep exchanging information to learn the network topology. The most widely known proactive routing protocols include Optimized Link State Routing protocol (OLSR) [START_REF] Clausen | Rfc7181: The optimized link state routing protocol version 2 (proposed standard)[END_REF], Wireless Routing Protocol (WRP), Destination-Sequenced Distance-Vector (DSDV) and recently the OLSR version 2. In PSN, such routes discovery techniques and computation cause network overloading that impacts the bandwidth utilization and increases the power consumption. Drawbacks of proactive routing protocols in PSN are not only due to energy inefficiency and bandwidth overload, but also the routing convergence delay caused by the intensive routes discovery broadcasts at the network start-up is also considerable.

Unlike proactive protocols, reactive routing protocols look up for routes only when it is needed. The route discovery procedure is invoked when data packets are ready to send. The route discovery mechanism in reactive routing protocols is the same i.e., a source node starts by flooding a request message to all reachable nodes looking up for the destination, then, each node relays this request message until it reaches the destination. If the destination is reached, a reply message is sent back to the source node through the reverse route followed by the request. Most known on-demand routing protocols are Ad-hoc On demand Distance Vector (AODV) [START_REF] Perkins | Dynamic manet on-demand (aodvv2) routing draft-ietf-manet-dymo-26[END_REF], Dynamic Source Routing protocol (DSR), Temporally Ordered Routing Algorithm (TORA) and more recently AODV version 2 (called also DYMO). Reactive routing protocols in mobile ad-hoc networks seem to solve the bandwidth utilization and energy efficiency issues based on the on-demand routing request, but the delay caused by the route discovery before data transfer, does not meet the PSN requirements. In addition to Ad-hoc routing protocol classes mentioned above, hybrid routing protocols class merge both reactive and proactive routing techniques. These routing protocols offer generally a combination between proactive routing for nearby nodes and reactive routing protocols for faraway nodes. Some other protocols are 3GPP based and are out of our related works scope since our proposed protocol is WiFi based. These approaches may be investigated in our upcoming studies and among the experimentation.

To summarize, multi-hop body-to-body communication is incapable to connect the whole disaster network. In our latest findings in [START_REF] Arbia | Behavior of wireless body-to-body networks routing strategies for public protection and disaster relief[END_REF], it is found necessary to build a bi-directional routes between the PSN command centers and the deployed rescue members in emergency and disaster situations. However, to the best of our knowledge, the aforementioned routing protocols are not optimized for the PSN context and have many limitations. While comparing the studied routing protocols both MANET and PSN, as illustrated in Table I, our proposed

III. MULTI-HOP BODY-TO-BODY OPTIMIZED ROUTING APPROACH FOR CRITICAL AND EMERGENCY NETWORKS (ORACE-NET)

In this section we present the newly proposed routing protocol (called ORACE-Net: Optimized Routing Approach for Critical and Emergency Networks) with the main objective to have instant neighborhood links visibility and available optimized routes according to the specific link quality estimation metrics. The new proposed routing protocol consists into three main phases. First, Advertisement broadcasts, second, Direct Route Establishment (DRE) and third, Reverse Route Establishment (RRE).

1) Advertisement broadcasts and Link Quality Estimation: The Command Center node (CC-node) initializes the connection by broadcasting periodically Advertisement packets (ADV ) which are flooded over the entire network as a wave to introduce the CC-node to the rest of the nodes in the network. A node receiving an ADV packet, rebroadcasts it to all its reachable neighbors. The header of the ADV packet contains a sequence number used to discard the duplicated received ADV packets. The last visited node is also recorded into the ADV packet header and then utilized as the next-hop in the established routes towards the CC-node.

In our proposed approach, ADV broadcasting process has three key roles. First, it replaces conventional neighbors discovery process, since all neighbors rebroadcast the received ADV packets, so a classical Hello protocol is not needed anymore. The ADV communicates to the network the CCnode(S) information and provides the neighborhood discovery. Second, based on the ADV packets (flooded within a period of 3 seconds) nodes establish their routes towards the CCnode(S). Third, it provides the Signal Strength Level between two nodes. The new proposal relies on two main metrics: the cumulative end-to-end links quality estimation (LQE) and the end-to-end hop count. The first metric might be calculated based on the Signal Strength Level (SSL), the link quality indicator (LQI) or the signal to noise ratio (SNR) measurement [START_REF] Hamida | Investigating the impact of human activity on the performance of wireless networks: An experimental approach[END_REF]. To that end, each ADV packet contains specific header's entries to track the hop count and the cumulative LQE (noted as E2E SSL ) along the traversed route. When an ADV packet is rebroadcast, the E2E SSL field in the packet header is updated by summing the SSL values recorded at each hop as depicted in Figure 1, according to the following equation:

E2E SD SSL = D S SSL ij (1)
where: S is the source of the E2E route, D is the destination, i and j are the visited nodes from the source to the destination. SSL ij is the received signal strength between node i and j (i.e., on one hop only).

In the remaining sections of the paper we consider the Endto-End Link Quality Estimation (E2E LQE ) as the End-to-End Signal Strength Level E2E SSL . As an example, E2E SSL of the route from node 7 towards the CC-node(S) is calculated based on 1 and as follows:

E2E SSL = (-30dbm) + (-60dbm) + (-40dbm) +(-70dbm) = -200dbm (2)
2) Direct Route Establishment (ADV-Based): The CC-node broadcasts periodically ADV packets with incremented sequence number, when the ADV packet is received by a neighbor node, that node updates both its neighbors and routing tables, then it rebroadcasts the ADV again. The ADV packet header contains the E2E SSL and the Hop Count . Once received by a node, first step is updating the neighbors table. Second, the E2E SSL and the Hop Count fields are extracted and their values are compared to those recorded in the current route towards CC-node. If the new values of E2E SSL and the Hop Count offer better optimized route, then the routing table is updated, otherwise, the ADV packet is rebroadcast without any change. These steps are depicted in the Algorithm 1. According to algorithm 1, each node selects the best route based on the highest end to end Signal Strength Level value and in case of equality the algorithm chooses the shortest path. In the case where E2E SSL (ADV ) is lower than E2E SSL (Route), the node waits until the lifetime (3 times periods of ADV ) of the route is expired, then, the sender of the first received ADV is selected as next-hop and the DRE process is relaunched again.

The Direct Route Establishment phase of the protocol ends up by a routing table at every reachable node with only one way routes (i.e., from nodes towards the CC-node). Once a route is established towards the CC-node, nodes send back a data packet to the CC-node, this data packet has a key role for the next phase called Reverse Route Establishment (i.e., RRE).

3) Reverse Route Establishment(Data-based): Based on the previous phases (i.e., ADV broadcast and DRE), each node of the network is able to establish an optimized route towards the CC-node and to estimate the E2E SSL and the hop -count accordingly. As a reply to the ADV packet, nodes start sending back data packets to the CC-node. The main challenge raised by our proposed approach is to establish the reverse way routes: Routes from the CC-node(S) to the rest of the nodes in the network. Indeed, the data packets are forwarded hopby-hop until they reach the CC-node. When a node receives a data packet with the CC-node as a final destination node, the following fields are extracted from the data packet header: E2E SSL , the hop-count, and the last visited node. A new (or existing) route is created (or updated) with the gathered values from the extracted fields of the data packet to fill respectively the following entries in the route: E2E SSL , the hop -count, and next-hop. Figure 2 illustrates the data packets flow towards the CC-node and the final routing table established by the CC-node. Once a data packet reaches the CC-node, an entire route is established towards the source of the data packet. Similarly to the DRE phase, the E2E SSL metric is calculated and updated using the same process and equation 1.

IV. DISASTER SCENARIO

In this paper we investigate a disaster scenario (fire trigger as a case study) in the "Landmark" shopping mall in the State of Qatar as depicted in figure 3 (500/300m). The mobility model used is generated by the BonnMotion tool [START_REF] Aschenbruck | Bonnmotion: A mobility scenario generation and analysis tool[END_REF]. Bonnmotion generates a mobility trace file which is used later in the packet oriented network simulator WSNET [START_REF]WSNET 3.0 Simulator[END_REF]. The total number of rescuers (i.e., firefighters, medical teams, helping civilians) is equal to 100. We assume that the fire is triggered into two opposite sides of the mall (i.e.,incidents areas), and the speed of the rescuers is less than 1.3 m/s. Rescuers, considered as mobile nodes, follow the disaster mobility model generated by Bonnmotion. Bonnmotion disaster mobility scheme is detailed in [START_REF] Aschenbruck | Modelling mobility in disaster area scenarios[END_REF].

Figure 3 shows the different areas of the disaster scenario generated by Bonnmotion, where nodes (rescuers) are saving and transporting victims from the incident areas to a safe place (patients waiting for treatment area and patients clearing area). The entire nodes inside the mall consist of an ad hoc network, where the CC-node is placed at the main-gate of the mall (shown as '♦' symbol in figure 3). Nodes send their data (i.e., images, videos, medical status) towards the CC-node, where a command center is conducting the operations.

V. PERFORMANCE EVALUATION

In this section we present the network level performance evaluation and simulations results of the proposed routing protocol. For comparison, with the respect to each relevant class of routing protocols (i.e., Reactive routing, Proactive routing, and Geographic-based routing) we selected the pertinent standard or protocol. The eligible selected candidates to investigate and compare are the most widely used routing protocols (i.e., AODVv2, OLSRv2 and GPSR). It is crucial to reproduce the realistic critical and disaster relief environment for the realistic performance evaluation. Therefore, several essential factors must be considered. First, a realistic mobility model (spatial and temporal consideration, mobility pattern, unpredictable crowd behavior, multiple incidents areas, etc.). Second, command and control operational requirements (e.g., Command Center location, rescue groups formation, logistic and medical resources, etc.). Third factor, simulated dynamic information generation (data flow in two ways: from the Command Center to the incident area and vice versa). In fact, first and second factors are related to the mobility modeling tool features, whereas, third factor depends on the network simulator used (detailed in the following sub-section i.e., V-A).

A. Simulation Setup and Mobility Modeling

The mobility scenario generation and analysis tool called Bonnmotion implements widely used existing models [START_REF] Aschenbruck | Bonnmotion: A mobility scenario generation and analysis tool[END_REF]. The Disaster Area Mobility model proposed in Bonnmotion is designed and implemented specifically for the crisis and public safety context (e.g., Earthquake, Air crash, storm, tsunami). The disaster scenario mobility model is the most appropriate model to use in case of critical and emergency simulation [START_REF] Arbia | Behavior of wireless body-to-body networks routing strategies for public protection and disaster relief[END_REF]. Indeed, this model provides a realistic pattern of real disaster theater composed of incident area(s), casualties clearing area(s), transport and medical evacuation zone(s).

The simulation setup and respective parameters are detailed in Table II as follows: The mobility trace file is generated according to the disaster mobility model. For systems level simulations, we are using an event-driven, packet-oriented network simulator called WSNet (version 3.0) [START_REF]WSNET 3.0 Simulator[END_REF]. Once, the mobility trace file is converted into the input file format of WSNET, we start the simulations in the following order. We select one of the routing protocols (i.e., ORACE-Net, AODVv2, OLSRv2 or GPSR), then, an application layer payload is selected (from: 200, 400, 600, 800 or 1000 bytes per second (Bps)). We are considering these payloads for simulation only, without consideration of big overhead in the applications layer for all the protocols. We are considering a free-space path-loss because the mobility model considers obstacles inside the disaster area where nodes can not cross and have to go around them. Indeed, a free-space path-loss would be fair for the model with an approximate range of 50 meters (based on the TX-power). We ran 15 iterations with the combination "Protocol-Payload", when done, we select the next payload value with the same routing protocol, once finished, we select the next routing protocol. We run the simulation with 95% of confidence interval considered. Once a specific routing protocol simulation is completed with all the payload values for the considered iterations, the next routing protocol is selected, and so on. This process is coordinated by shell scripts that select, run and save the results.

B. Simulations Results

The performance metrics considered for the evaluation of the protocols are: First, the Average Packet Reception Rate (i.e., PRR) which consists of the number of received packet divided by the number of the transmitted packets at the application layer. Second, the Average Communication Delay, which is the average packet delay between the source node II. It is important to note here that the energy efficiency is an important challenge in the disaster context. Indeed, a rescue team may be working along few hours to more than one day.

a) Packet Reception Rate: Figure 4-(a) shows the average PRR for the different studied protocols. Our proposed protocol (ORACE-Net) achieves the best performance with nearly 70% of PRR while OLSRv2 has a difference of more than 10% of PRR lower than our approach. On the other hand, AODVv2, achieves the worst performance with 23% of PRR mainly due to the high number of re-transmissions and the non-resolved destinations. Indeed, a route in AODVv2 is established on-demand, when the route is set, and the nodes have a high mobility behavior (which is the case here), the route must be updated continuously, if AODVv2 keeps on using an old route where intermediate nodes moved away, that route is no more available, a Route Error (i.e., RERR) is received by the sender, and a new request is flooded into the network. All this process has an impact on the average PRR, communication delay and the energy consumption. GPSR has an average PRR around 40% with the different payloads. Obviously, GPSR may have better performance in outdoor scenario, an indoor GPS location system is not efficient, and has a significant impact on the energy consumption.

b) Energy Consumption: The energy consumption with a disaster scenario is shown in the Figure 4-(b). The energy consumption for each transmitted packet is calculated as follows,

E P acket = T P acket × 3 V olts × I mA (3)
where, T packet is the duration in milliseconds which is based on the effective packet length (including all the PHY and MAC headers [START_REF] Alam | Performance evaluation of ieee 802.15.6 mac for wearable body sensor networks using a space-time dependent radio link model[END_REF]).

GPSR has increasingly higher energy consumption starting from 200Bps payload, this is due to its considerable energy consumption of the GPS receiver. Our proposed approach performs much better compared to the other protocols mainly because of having lower network control packets (i.e., RREQ, RREP, REER, Topology Control) and the non-use of periodic beacons which reduces the energy consumption. The behavior of AODVv2 and OLSRv2 are quite comparable, but according to the average PRR results, AODVv2 is not resolving the routes since it has lowest PRR. Thus, AODVv2 is consuming this amount of energy in sending the Route Error and the new Route Request packets. Overall, the energy consumption of all the routing protocols is increasing accordingly with the payloads.

c) Communication Delay: Figure 4-(c) depicts the average communication delay for the four studied routing protocols with a Disaster Area mobility model. It can be seen that AODVv2 has the highest and variable results. The unstable behavior of AODVv2 is due to the high topology change which ensues in low average PRR recorded (as explained above) and high average delay. However, OLSRv2 and GPSR have better performance in terms of delay accordingly with the low PRR. Indeed, the PRR of OLSRv2 and GPSR is low, so there is no much data delivered and there will be lower communication delay. On the other hand ORACE-Net records a higher average delay than OLSRv2 and GPSR which is related with the higher average PRR. Moreover, the quantity of processed data packets with the ORACE-Net is much higher than the rest of the protocols. ORACE-Net behavior in terms of delay is fair with reference to the number of delivered packets. d) Average Hop Count: Figure 4-(d) shows the average hop count with a disaster mobility scenario. All the routing protocols except AODVv2 have approximately the same performance (i.e., between 2.7 and 3.5 hops) in terms average hop count. ORACE-Net has the highest hop count (3.5 hops). However, based on the average PRR and energy, the established routes have higher hop count but they are more reliable than those established by the other protocols (i.e., AODVv2) despite they are shorter.

Finally, the proposed protocol is the most performant routing protocol simulated with realistic disaster mobility scenario. OLSRv2 is close to ORACE-Net in terms of energy consumption and average hop count, but far in terms of PRR. Whereas, it is concluded that AODVv2 and GPSR are not suitable to be deployed in disaster mobility network. To summarize, for higher connectivity in a mobile disaster scenario, the proposed ORACE-Net is the most appropriate routing protocol.

VI. CONCLUSION AND FUTURE WORKS

In this work, we have presented a new optimized routing approach for critical and emergency networks ORACE-Net). Based on advertisement packets to establish routes from deployed nodes towards the Command Center node, we call this process Direct Route Establishment (DRE). DRE is followed by the Reverse Route Establishment (RRE) step, which allows the CC -node to build routes towards all the nodes of the network. Our proposed protocol has been evaluated based on realistic disaster mobility model with an event-driven simulator (i.e, WSNET). Compared to eligible selected standards and protocols from each routing class (i.e., AODVv2 as reactive, OLSRv2 as proactive and GPSR as geographic-based routing protocols), our approach shows best performance compared to the other protocols in terms of average PRR. Additionally, the proposed approach is energy efficient. To conclude, the new proposed approach increases the network lifetime and optimizes the routes based on an End-to-End Signal Strength Level with minimum hop count. ORACE-Net will be implemented to experiment the protocol in real conditions and investigate its behavior to fulfill the application layer requirements (i.e, Internet connection, medical services, vital monitoring), and this will be covered in the future works.

Fig. 1 .

 1 Fig. 1. Routing tables (for Nodes 7, 5 and 8) when the 1 st wave of ADV reaches all nodes. Nodes X are base stations deployed by the rescue teams while they are moving towards the incident area.

Algorithm 1

 1 Direct Route Establishment Algorithm (Node 'i') 1-RX (SRC, DST, ADV_packet) 1'-Drop_Duplicated_ADV(Seq_Number) 2-Update_Neighbors_Table() if (E2E SSL (ADV ) > E2E SSL (Route)) OR (E2E SSL (ADV ) == E2E SSL (Route) AN D Hop Count (ADV ) ≤ Hop Count (Route)) thenUpdate_E2E_SSL() Update_Hop_Count() Update_Routing_Table() end if 3-TX (SRC=CC-node, DST=Bcast, ADV_packet); Go To 1

Fig. 2 .

 2 Fig. 2. Reverse Route Establishment (i.e., RRE) based on data packets.

Fig. 3 .

 3 Fig. 3. Disaster Area Nodes Locations, Areas and Obstacles.

Fig. 4 .

 4 Multi-hop Body-to-Body Routing Protocol Behavior with Disaster Scenario mobility model. and the final destination over a multi-hop communication. Third, the Average Hop Count, which consists of the average number of hops starting from the source to the destination in the network. Finally, the Average Energy Consumption per delivered packet with the considered radio transceiver parameters detailed in Table

TABLE II SIMULATION

 II SETUP PARAMETERS -WSNET V3.0

	Parameters	Values
	Area	500m/300m
	Number of nodes	100
	Number of CC-nodes	1 (located in the left corner of the area with the
		coordinates [0 , 250 , 0])
	Simulation Duration	300s/iteration
	Mobility Modeling	Disaster Area Scenario
	Application Layer	Constant Bit Rate(CBR) with 1 packet/s/node
		Payloads : 200, 400, 600, 800 and 1000 bytes
	Routing Layer	AODVv2, OLSRv2, GPSR and ORACE-Net
	MAC-Layer Standard	IEEE802.11b CSMA/CA DCF with ACK
	PHY & Radio-Layer	Pathloss = freespace, Modulation = BPSK,
		Sensitivity = -92dBM, TX Power = 0dBm,
		2.4GHz
	Packets Sizes	According to the protocols standards [16][17][14]
	Number of iterations	15 per protocol per payload

ACKNOWLEDGMENT

This publication was made possible by NPRP grant #[6 -1508 -2 -616] from the Qatar National Research Fund (a member of Qatar Foundation). The statements made herein are solely the responsibility of the authors.


Ben Dhafer

Muhammad Mahtab Arbia

Rabah Alam

Elyes Ben Attia

Abdullah Hamida

Kadri

Attia

CROW 2 : Internet of Humans-based Platform for Disaster Relief and Emergency Communication

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Abstract-During a disaster incident, existing network infrastructures might either be damaged or overloaded. However, disaster operations require real-time and low latency data communication, especially live video and audio streaming, as well as in integration with social networks. Thus, deployed tactical networks face several challenges to connect intervening teams. To date, there is still a lack of routing standards for such networks. Indeed, in such harsh environment, medical rescue teams, firefighters, military, police and even victims need to be steadily connected to a distant command center (CC) which conducts the rescue operations. In our recent works, a new routing protocol called ORACE-Net was proposed, evaluated and compared to the existing approaches. ORACE-Net aims to create a tactical Internet of Humans (IoH) emergency network. ORACE-Net is implemented on mobile devices and evaluated within realistic conditions. The complete proposed solution consists of the CROW 2 , an Internet of Humans -based platform for disaster relief and emergency communication. In this paper we describe the setup and the demonstration of the CROW 2 platform based on the our conducted experimentation.

Keywords-CROW 2 , disaster relief, ORACE-Net, Internet of Humans;

I. OVERVIEW

The important growing number of natural or humanmade disasters, make the wireless communication technologies facing several challenges. Indeed, during the disaster incident, existing network infrastructures might be either damaged or over saturated. Thus, tactical wireless networks are deployed along the incident areas in order to connect rescue teams to a distant Command Center (CC) which is conducting the operations. Rescue teams must be able to send their realtime feedback and receive missions to execute such as: i) medical teams may have live medical assistance from the CC, ii) firefighters, police and army may record their missions or use live broadcast within the CC, iii) civilians and injured persons may use the tactical network to tag, share their locations, or search and find their contacts on social networks. With regards to these required services, limitations are expected on the state of the art of the wireless technology. Indeed, in addition to radio technologies inter-operability, coexistence, and energy consumption issues, routing is an important and critical challenge for the tactical emergency networks [START_REF] Alam | Surveying wearable human assistive technology for life and safety critical applications: Standards, challenges and opportunities[END_REF], [START_REF] Tata | Multipath routing algorithm for device-to-device communications for public safety over lte heterogeneous networks[END_REF]. In this context, some researches have evaluated existing routing standards in the disaster and emergency relief. Based on our recent works [START_REF] Ben Arbia | Implementation and benchmarking of a novel routing protocol for tactical mobile ad-hoc networks[END_REF], we have concluded that our proposed approach, which is called Optimized Routing Approach for Critical and CROW 2 platform has three main levels of wireless communication as depicted in Figure 1: i) On-Body network: vital sensors connected to the rescuer body which sense and send the data towards the Wireles Body Area Netowk (WBAN) coordinator, ii) Body-to-Body network: on-body collected data is then routed from one WBAN coordinator to another until it reaches the CC, iii) Off-Body network: collected data from the entire network at the CC is then shared and published on Internet of Things (IoT) platform. Figure 2

II. DEMONSTRATION

We will demonstrate the CROW 2 platform including the following components:

1) CC node. Special node of the network with enhanced capacities. CC node is in charge of gathering data from tactical base station and on-body mobile devices. The CC node publish collected data on an IoT platform through Internet. CC node is a raspberry-pi device on which ORACE-Net routing protocol is running. It is connected to Internet via Ethernet and with the deployed nodes via ad hoc WiFi 802.11n. 2) Tactical nodes (or base station). Raspberry-pi devices on which ORACE-Net routing protocol is implemented. They are used as tactical base stations only to extend the network coverage, and are intended to be dropped by the rescue teams when they get inside the incident area as detailed in [START_REF] Ben Arbia | Implementation and benchmarking of a novel routing protocol for tactical mobile ad-hoc networks[END_REF]. Tactical base stations may be used as on-body devices, in this they are called tactical nodes. In the latter case the on-body sensors are connected to it, and the base station is a WBAN coordinator. Figure 3 our IoT platform and will be presented and explained along with the demonstration. Labeeb IoT platform assures the monitoring and supervision of the deployed nodes of the network. An example of output is depicted in Figure 3 (c).

The demonstration scenario will include at least one mobile node and one tactical node (or base station) in addition to the CC node. Ideally, for 150 m 2 , 8 nodes might be used (as we tested in our experimentation). Network starts up by powering on the tactical and mobile nodes. Sensed data (e.g., photoplethysmography, heart rate variability, stress, relaxation, electrodermal activity, Galvanic skin response, 3axis accelerometer, 3-axis gryroscope, 3-axis magnetometer and integrated altimete), being published on Labeeb IoT platform, could be investigated immediately. The platform shows also statistics of disconnections and delays, hop counts , routing tables and real time updates.

CROW 2 :

 2 Internet of Humans-based Platform for Disaster Relief and Emergency Communication Dhafer Ben Arbia * † , Muhammad Mahtab Alam * , Rabah Attia † , Elyes Ben Hamida * , Abdullah Kadri * * Qatar Mobility Innovations Center (QMIC), Qatar University. Qatar Science and Technology Park (QSTP) PO. Box. 210531, Doha, Qatar. Email: [dhafera, mahtaba, abdullahk, elyesb]@qmic.com, rabah.attia@enit.rnu.tn † SERCOM Lab, Polytechnic School of Tunisia, University of Carthage B.P. 743. 2078 La Marsa. Tunisia

Fig. 1 :

 1 Fig. 1: CROW 2 system wireless communication levels.

Fig. 2 :

 2 Fig. 2: CROW 2 system design (Layers Overview).

  depicts the CROW 2 layers architecture overview.

Fig. 3 :

 3 Fig. 3: (a) CROW 2 On-Body System: One Coordinator and three sensors (b) A photo of the ORACE-Net mobile devices displaying the real-time events (received Hello and ADV packets) and the current default route. (c) Labeeb-IoT interface (on the right) shows the variation of the Hop count for the connected nodes(mobiles and statics) over the time.

  On-body sensors. Different types of sensors were tested and connected to the CROW 2 platform. During the demonstration we use Shimmer[START_REF] Danger | Shimmer sensing website[END_REF] Consensys GSR Development Kit. 5) IoT Labeeb Platform. Live data are published on

	(a) depicts
	a on-body tactical base station connected over Zigbee
	IEEE 802.15.4 standard with the sensors and on ad
	hoc Wifi 802.11n with the rest of the coordinators in
	the network. It is important to note here that the CC
	is a tactical base station with enhanced features and
	accessibility.
	3) On-body mobile devices. Android mobile devices
	on which ORACE-Net protocol is deployed and ad
	hoc mode is configured to join the tactical network.
	Mobile devices are connected to sensors via Bluetooth
	IEEE 802.15.1. More details on the used sensors in the
	next paragraph. Once started, the mobile application
	connects the device to the ad hoc network and starts
	receiving ORACE-Net messages as detailed in [3].
	4)

ACKNOWLEDGMENT

This publication was made possible by NPRP grant #[6 -1508 -2 -616] from the Qatar National Research Fund (a member of Qatar Foundation). The statements made herein are solely the responsibility of the authors.


Ben Dhafer
email: [dhafera@qmic.com

Arbia

Muhammad Mahtab Alam

Abdullah Kadri
email: abdullahk@qmic.com

Rabah Attia
email: rabah.attia@enit.rnu.tn

Elyes Ben Hamida

Implementation and Benchmarking of a Novel Routing Protocol for Tactical Mobile Ad-Hoc Networks

Keywords: Tactical Multi-Hop Routing Protocol, Ad-hoc Wifi, Internet of Things, Optimized Routing Approach for Critical and Emergency Networks

Providing efficient routing service over tactical multi-hop ad-hoc networks is a crucial building block in wireless communication networks especially during a disaster relief. To date, there is still a lack of routing standards for such networks. Indeed, in such harsh environment, medical rescue teams, firefighters, military, police and even victims need to be steadily connected to a distant command center (CC) which conducts the rescue operations. In this paper, we propose a new multi-hop routing approach called ORACE-Net. The proposed protocol uses advertisement packets to establish routes from deployed nodes towards the CC (i.e. Direct Route Establishment). Then, it utilizes the data packets to establish reverse routes (from the CC to all nodes in the network). We implemented and evaluated our approach in realistic scenario using tactical and onbody mobile nodes. Our experiments include also an Internet of Thing (IoT) platform and a real-time dynamic topology website which are used for analyzing the behavior of the protocol. The experimental results show that our protocol increases the mobile nodes connectivity and packet delivery rate. Also, it reduces the average round trip time delay for the on-body nodes compared to the tactical deployed base stations.

I. INTRODUCTION

Disasters are increasing worldwide with more devastating effects than ever before. In fact, the absolute number of disasters around the world has almost doubled since the 1980s [START_REF]Natural disasters in the middle east and north africa: a regional overview[END_REF]. The growing number of disasters and accidents has a significant impact on humans living conditions, asset safety, as well as the economy. According to the United Nations Development Program (UNDP) Office for Disaster Risk Reduction (UNISDR), during the last decade (between 2000-2012) the overall worldwide estimated damages due to various disasters results in loss of 1.7 Trillion dollars, 1.2 Million loss of lives and overall 2.9 Million affected people [START_REF] Alam | Wireless Public Safety Networks 2, 1st Edition -A Systematic Approachs. Chapter 3: Wearable Wireless Sensor Networks for Emergency Response in Public Safety Networks[END_REF].

Information and communication technologies (ICT) has a vital role both in early prediction as well as in effective rescue and evacuation phase to minimize the loss of lives and assets. On one hand, the public safety networks (PSNs) are evolving rapidly from the classical land mobile radio systems to the long term evolution (LTE) technologies. On the other hand, there is a growing need for reliable ubiquitous communication system which should be fast and easy to deploy.

In this context, instant mobile ad-hoc networking is emerging as an effective alternative to be deployed during the disaster [START_REF] Varun | Ensuring reliable communication in disaster recovery operations with reliable routing technique[END_REF], [START_REF] Zhuang | Managing ad hoc networks of smartphones[END_REF]. In addition to radio technologies inter-operability, coexistence, and energy consumption issues, routing is an important and critical challenge for the tactical emergency networks [START_REF] Alam | Surveying wearable human assistive technology for life and safety critical applications: Standards, challenges and opportunities[END_REF]- [START_REF] Tata | Multipath routing algorithm for deviceto-device communications for public safety over lte heterogeneous networks[END_REF]. To the best of our knowledge, the existing routing techniques and protocols for PSN are not optimized for the tactical and disaster context.

In this paper, we introduce a tactical and mobile multihop routing protocol called Optimized Routing Approach for Critical and Emergency Networks (ORACE-Net). The protocol enables two-way communication to-and-from command center (CC) to the rest nodes in the network. Please note that the CC may include one or more CC nodes.

Specific contributions of this paper are listed as follows: 1) We present ORACE-Net approach which is based on the End-to-End Link Quality Estimation (E2E LQE ) to optimize routing in tactical networks. 2) We discuss the experimental results of the proposed approach implementation in a realistic tactical testbed. 3) We used an Internet of Things platform in the application layer to evaluate the network connectivity and reliability.

II. RELATED WORKS

The development of ad-hoc networking via WiFi IEEE 802.11n standard on smart phones is rare. In wireless adhoc mode, each device can directly communicate with another device and the management of the ad-hoc network is done through collaboration between the nodes in the network. The authors in [START_REF] Jung | Designing content-centric multi-hop networking over wi-fi direct on smartphones[END_REF] present similar networking over WiFi Direct standard on the smart phones. The proposed architecture enables building multiple group formations using multi channels on Wi-Fi Direct for providing multi-hop communications which help to achieve power saving for energy constraint smart phones. This content-centric multi-hop networking study is limited to only energy optimization. Other performance metrics (i.e., communication delay, hop-counts and packet reception rate) are not targeted. Further, similar concept is exploited in [START_REF] Laha | An energy efficient routing protocol for device-to-device based multihop smartphone networks[END_REF], where authors propose an energy efficient cluster-based routing protocol (called QGRP), which relies on virtual hierarchical distributed clustered algorithm. The simulation results show that the proposed QGRP is energy effi-cient. However, the study presents only preliminary simulation results and it misses detailed study including implementation.

The design and implementation of the wireless multi-hop ad-hoc networks using smart phones is presented in [START_REF] Zhuang | Managing ad hoc networks of smartphones[END_REF]. The middle-ware of the mobile Android devices is implemented in the user-space and therefore, kernel modifications are not required. The implementation evaluation results show that the middle-ware achieves around 5 Mbps transmission bandwidth in single-hop and around 4 Mbps bandwidth in two hops communications with strong WiFi links. The experiments were carried out with forced multi-hop setup. Almost 100 ms average round trip delay time is reported. However, the experiments lack real multi-hop communication as it is only limited to small-scale networks with the maximum of twohops. The Optimized Link State Routing Protocol (OLSR) is implemented in [START_REF] Shuai | The research on olsr routing protocol based on android system and its implement[END_REF]. The implementation includes two android (HTC) smart phones and three PCs. The results show that the OLSR protocol always ensures strong connectivity under dynamic mobility. The implementation study is interesting as it validates the connectivity of the mobile network in heterogeneous devices. However, the performance metrics and their analysis of the protocol at network level are not addressed.

The preliminary results of the prototype implementation on Android smart phone over WiFi using software defined networking (SDN) are presented in [START_REF] Baskett | Sdnan: Softwaredefined networking in ad hoc networks of smartphones[END_REF]. Text messaging and file transfer applications were demonstrated for SDN in adhoc networks (SDNAN). This approach is based on three layers i.e., ad-hoc networking layer (which is based on AODV routing protocol), a network operating system layer (which controls the dynamic variations of the routing protocol) and control program (which manages forwarding rules, routing table, and routing protocol on the fly). Android Interface Definition Language (AIDL) is used for inter-process communication which simplifies the code complexity of the interface among three layers. Some more recent studies (such as [START_REF] Varun | Ensuring reliable communication in disaster recovery operations with reliable routing technique[END_REF], [START_REF] Laha | An energy efficient routing protocol for device-to-device based multihop smartphone networks[END_REF], [START_REF] Group | Delay tolerant network 2[END_REF]- [START_REF] Lu | Networking smartphones for disaster recovery[END_REF]) are adapted to the network dynamic aspects for viable and effective disaster operation. For example, localization-based and network congestion adaptive approach called "DistressNet" [START_REF] George | Distressnet: a wireless ad hoc and sensor network architecture for situation management in disaster response[END_REF] is efficient in congestion avoidance in the network during disaster operations. However, this approach creates network sparseness which impacts localization and renders multi-hop algorithms inefficient, especially in the indoor rescue operations. Recent proposed approaches called Reliable Routing Technique (RRT) [START_REF] Varun | Ensuring reliable communication in disaster recovery operations with reliable routing technique[END_REF] and TeamPhone [START_REF] Lu | Networking smartphones for disaster recovery[END_REF], are based on Greedy Perimeter Stateless Routing (GPSR) [START_REF] Karp | Gpsr: Greedy perimeter stateless routing for wireless networks[END_REF] and Delay Tolerant Network version-2 (DTN2) [START_REF] Group | Delay tolerant network 2[END_REF] respectively. The authors claim that RRT approach is delay-efficient. However, it has significantly higher energy consumption. On the other hand, TeamPhone is limited in terms of services. In fact, it is based on ad-hoc and opportunistic network and it provides only basic emergency messages with up to one hop only.

To conclude, wireless mobile ad-hoc networking using smart phones is appearing to dominate future rescue and critical operations. In most of the above mentioned implementations and prototypes, network connectivity and mobility under indoor rescue environment are not considered. Addi-tionally, the number of nodes used is too low (around three nodes). To address some of these limitations, in this paper, we consider heterogeneous architecture including smart phones (Android-based), raspberry pi (Linux-based) devices for effective connectivity in ad-hoc tactical network. We mainly considered above protocols in the literature, because they were implemented or evaluated in realistic scenario. Other approaches such as [START_REF] Kang | Virtual back-pressure routing in mobile ad-hoc networks for disaster scenarios[END_REF] were not covered because they are multi-path and will be a part of our future implementations..

III. MULTI-HOP OPTIMIZED ROUTING APPROACH FOR CRITICAL AND EMERGENCY NETWORKS

In this section, we present a new routing protocol called Optimized Routing Approach for Critical and Emergency Networks (ORACE-Net). The main objective of ORACE-Net is to have instant neighborhood links visibility and establish available optimized routes according to the specific link quality estimation metrics. The proposed protocol consists of three main phases: 1) Beacons, Advertisement broadcasts and Link Quality Estimation, 2) Direct Route Establishment (DRE), and 3) Reverse Route Establishment (RRE). These phases are described in the following subsections.

1) Beacons, Advertisement broadcasts and Link Quality Estimation: Each node from ORACE-Net network broadcasts continuously periodic Hello packets for neighborhood discovery according to the standard NeighborHood Discovery Protocol (NHDP) [START_REF] Clausen | Mobile ad hoc network (manet) neighborhood discovery protocol (nhdp)[END_REF]. In addition, Hello packets are used in the link quality estimation for the nodes [START_REF] Ben Hamida | Short-term link quality estimation for opportunistic and mobility aware routing in wearable body sensors networks[END_REF]. Each Hello packet has a sequence number. When a node receives the first Hello packet from a neighbor, this neighbor is inserted into the neighbors table with a Link Quality Estimation (LQE) equal to 1.0. Based on the Hello packets broadcasted every 3s, a node can estimate the number of Hello packets supposed to be received during a certain period of time. The LQE of a one hop neighbor is assigned according to the following equation:

LQE = H R H E (1)
where H R is the number of Received Hello packets, and H E is the expected number of Hello packets to be received which is equal to:

H E = T C -T S P H (2)
where T C is the current time, T S is the connection starting time with each specific node, P H is the Hello period. The CC node initializes the connection by broadcasting periodically Advertisement packets (ADV ) which are flooded over the entire network as a wave to introduce the CC node to all other nodes in the network. A CC node is a node deployed by the command center in the closest safe place to the incident area.

A node receiving an ADV , processes it and then rebroadcasts it to all of its reachable nodes. The header of the ADV contains a sequence number which is used to discard the duplicated received ADV s. When a node receives an ADV , a route is established towards the CC node with the last visited node by the ADV selected as the next-hop. The following received ADV will initiate the second phase of ORACE-Net detailed in the next subsection.

In our proposed approach, ADV broadcasting process has three key roles: 1) it contributes in the conventional neighbors discovery process, 2) it provides routes establishment towards the command center node(s) (CC node(s)), 3) it provides also the E2E LQE . The proposed approach relies on two main metrics: E2E LQE and the Hop Count . The first metric can be calculated based either on the Signal Strength Level (SSL), the link quality indicator (LQI), or the signal to noise ratio (SN R) measurements [START_REF] Hamida | Investigating the impact of human activity on the performance of wireless networks: An experimental approach[END_REF] [START_REF] Ben Hamida | Short-term link quality estimation for opportunistic and mobility aware routing in wearable body sensors networks[END_REF]. To that end, each ADV contains specific header's entries to track the hop count and the E2E LQE along the traversed route. When an ADV is rebroadcasted, the E2E LQE field in the packet header is updated by multiplying the LQE values recorded at each hop. Figure 1 depicts an example of the ADV broadcasting process. The E2E SD LQE between a source node S and a destination node D is calculated according to the following equation:

E2E SD LQE = D S LQE ij (3)
where: S is the source of the E2E route, D is the destination, i and j are the visited nodes from the source to the destination. LQE ij is the Link Quality Estimation between node i and j (i.e., on one hop only).

The proposed ORACE-Net routing protocol operates based on two different algorithms. Algorithm 1 is run upon the reception of ADV s (i.e. DRE), while Algorithm 2 is executed upon receiving a DAT A packet (i.e. RRE).

2) Direct Route Establishment: The CC node broadcasts an ADV , then it waits for a predefined period (i.e. 3s) to broadcast the next ADV with a new sequence number. On the other hand, when a node receives an ADV , it updates both its neighbors and routing tables. Then it rebroadcasts the ADV only once. The direct route establishment algorithm (as explained below) is depicted in Algorithm 1.

The routing table is only updated when the received ADV has better E2E LQE than the one of the current used route. According to Algorithm 1, all the ADV packets are considered (even duplicated), but each ADV is re-broadcasted only one time (based on the sequence number). Indeed, the E2E LQE (ADV ) is compared with the E2E LQE (Route). If the first value is higher, then the current route is updated as 3) Reverse Route Establishment: ORACE-Net proposes bidirectional path establishment for efficient routing in public protection and disaster networks. Indeed, the data packets are forwarded hop-by-hop until they reach the CC node. The DAT A packet header records the E2E LQE , Hop Count , the last visited node, and the originator of the packet. If the routing table does not contain a route to the originator of the packet, then a new route is created. Otherwise, if the route already exists and the E2E LQE (DAT A) is higher than E2E LQE (Route), or, they are equal and the Hop Count (DAT A) is less or equal than Hop Count (Route), fields are extracted from the header to create or update route as follows: 1) The originator of the DAT A packet becomes the final destination in this route. 2) The last visited node is the next-hop to reach that final destination. 3) The E2E LQE is updated with the LQE (given by Equation 2) of the link (Current node, last visited node) according to Equation 3, then inserted into the route. 4) The Hop Count is incremented and inserted within the route. Figure 2 illustrates the data packets flow towards the CC node. When a node receives a data packet, the node updates its routing table then forwards the packet. A duplicated DAT A packet is used to update the routing table and then dropped based on the sequence number. Similarly to the DRE phase, the E2E LQE is calculated and updated using the same process as detailed in Algorithm 2.

IV. IMPLEMENTATION ARCHITECTURE

In this section, we describe ORACE-Net implementation. Two versions of ORACE-Net are implemented (i.e. Linux and Android). Linux version is developed in C-language whereas Android version is Java-based implementation. A systemoriented stack is depicted in Figure 3a. The stack presents the common system layers (i.e., Hardware, Linux Kernel) and the specific layers for each architecture (i.e., libraries, runtime, environment and user interface). With regards to the operational requirements of a disaster context, first rescue teams reaching the incident area, deploy tactical base stations to initiate a wireless tactical network. Each rescuer is equipped with a mobile device. Consequently, an ad-hoc tactical-mobile network will cover the disaster area. All devices are running according to ORACE-Net over wireless ad-hoc network. In the following subsections we describe the different components and devices of the experiments: 1) mobile devices, 2) tactical base stations, 3) Labeeb-IoT platform, and 4) dynamic topology website.

A. Mobile Devices : ORACE-Net Android application

ORACE-Net Android application is implemented on the user's level as depicted in Figure 3a, it exploits the features of Linux operating system at the kernel layer through the Dalvik Virtual Machine. Figure 3b depicts 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. multicasted or broadcasted packets, clicked button, typed text, etc.). In ORACE-Net javabased Android application, the events listener is implemented as a socket with a multicast IP address/Port: 224.0.0.1/10000. Similar socket is implemented on C-language under Linux for the tactical base stations. Received packets through the events listener are handled by the broadcast receivers component to be hulled. In fact, each field from the packet is retrieved separately: packet sequence number (Seq N umber ) Source, Destination, Hop count , and E2E LQE . Non-duplicated received packets are passed to the services component to be exploited. The services block is also responsible for broadcasting Hello and rebroadcasting the ADV packets. Algorithms 1 and 2 are implemented under the services component. Finally, the content provider allows the application share the results on other servers or platforms. Both outputs of ORACE-Net Tactical and Android applications are transmitted to an Internet of Things platform called: Labeeb-IoT [START_REF] Center | Labeeb iot platform and solutions[END_REF]. Figure 4a shows the interface of the Android mobile application displaying the real-time events (i.e., received Hello and ADV packets), the current route used by each device, and the Internet connection status.

B. Tactical Base Stations: ORACE-Net Linux application

For tactical base stations, we implemented ORACE-Net on Raspbian v8.0, a free operating system based on Debian optimized for the Raspberry Pi hardware. Linux libraries are used to operate the 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 operation system logging service Syslog. Finally, the data is pushed to Labeeb-IoT platform via the machine-to-machine (M2M) Message Queuing Telemetry Transport (MQTT) protocol client.

C. Labeeb-IoT Platform

Internet of Things (IoT) is emerging technologies developed for smart living solutions. IoT solutions are online platforms capable of sensing real-time data from diverse types of devices and sensors that could be deployed in a vast geographic area. This platform collects, stores and publishes the data according to many predefined parameters. With respect to the MQTT standard [START_REF]Information technology message queuing telemetry transport (mqtt)[END_REF], Labeeb-IoT uses a publish/subscribe architecture in contrast with HTTP request/response paradigm architecture. Publish/Subscribe is event-driven and enables messages to be pushed to clients using MQTT protocol. MQTT client communicates with the broker using predefined methods (e.g., connect, disconnect, subscribe, publish). Labeeb-IoT offers various APIs and Restful/JSON web services.

In our experiments, ORACE-Net devices (mobile and tactical) push continuously and instantly specific data to Labeeb-IoT platform: 1) the device identifier (Device Id ), 2) the device location (Location), 3) the device neighbors list (N eighbors), 4) the next-hop to the CC node (N H CC ), 5) the E2E LQE , and 6) the Hop count to the CC node. This data is stored into the platform database and then extracted to the dynamic real-time topology website as shown in Figure 5.

D. Dynamic Topology Website

In order to display real-time network dynamic topology, we developed Javascript-based website. This tool reads instant data from Labeeb-IoT platform and displays nodes as spots linked to each others and to the CC node (a screenshot appears in the experimentation architecture at the right of. Figure 5). In addition to the network dynamic map, this tool displays the next-hop table for each connected node and the variation of the E2E LQE . As an example, a snapshot of the ORACE-Net network is depicted in Figure 6. It shows that the mobile node is four hops far from the CC node, and the E2E LQE (M ) = 0.78.

V. EXPERIMENTAL EVALUATION

In this section, we describe the settings of our testbed, then we present the adopted performance metrics, followed by the discussion of the obtained results.

A. 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 testbed consists of eight raspberry-pi devices model 2-B and two Samsung galaxy S3-I9300 smart phones with ORACE-Net routing protocol implemented on-board. The office map is shown in Figure 5. Rescue teams access to the office from the back-gate (BG). First, they deploy the CC node in a trusted and safe location at the gate to be connected to Internet through an Ethernet or WiFi access point. Upon their entrance inside the office, rescuers start deploying tactical base stations in order to have the maximum network wireless coverage above all the operations area. Tactical static base stations are deployed as shown in Figure 5 from 1 to 8. Mobile nodes (smart phones) carried by the rescuers are connected through the tactical network to the CC node. Since the experimentation area is limited, we reduced the raspberry-pi's and smart phone's WiFi antennas transmission power to 0 dBm. Disaster area is divided into four zones: incident area (zones 1 and 2), victims waiting for evacuation (zone 3) and evacuation area (zone 4). Rescuers evacuate victims from incident area to the evacuation area. Experimentation parameters and configuration settings are detailed in Table I.

B. Experimentation Results

In this subsection, we present the results of experiments aimed to evaluate ORACE-Net tactical mobile routing protocol in real disaster scenario. In fact, with regards to the disaster context, we consider the following relevant performance to the network or not. Average Disconnections metric gives the average connection of a specific node. It is important to note that the following results were recorded inside QMIC's office. This office already includes many wireless base stations and devices. Thus, the resulting interference has a significant impact on the obtained results of ORACE-Net implementation. 1) Mobile node behavior over the time: Figure 7 shows the behavior of a smart phone mobile node during the entire experimentation. According to Table II, it can be seen that the Hop count and the zone are not correlated. In fact, when a mobile node is in zone 2, this does not mean that it is always 2 hops far from the CC node. It could select a route through 2 nodes and then will have 3 hops to reach the CC node. Whereas, the E2E LQE and the Hop count are correlated. In fact, the E2E LQE decreases when the Hop count increases (as shown in Table II andFigure 7). On the other hand, the delay provided as the Round Trip Time from the mobile node to the CC node, shows three main peaks when the mobile node is in zone 4. Indeed, this caused significant delay and even disconnection, which is explained in details below in subsection V-B5. 2) Average Packet Delivery Rate: The results of the Average Packet Delivery Rate are shown in Figure 8. Average PDR is given by zone and based on the tactical and mobile nodes separately. Overall, mobile nodes are more performant than the tactical nodes. But similarly, mobile and tactical nodes achieve the best PDR average in zone 2 with 69.23% and 64.75% respectively. Mobile nodes behave similarly in zone 1 and 2 in terms of packet delivery rate. However, tactical nodes have lower average PDR in zone 1 than in zone 2. Indeed, it is true that distance from node 3 in zone 2 to the CC node is higher than distance from node 2 in zone 1 to the CC node. But, there is an open space between the CC node and node 3 in zone 2. Whereas, many obstacles between node 2 (zone 1) and the CC node causes the SNR degradation. Additionally, zone 1 is the congestion zone in the network, since all nodes are sending their data towards one destination (CC node) which is in zone 1. The lowest average PDR for mobile and tactical deployed nodes is recorded in zone 4, achieving 28.37% and 50.87% respectively. According to our scenario, zone 4 is the safe zone as explained above, where victims and rescuers are considered out of danger. Thus, in this safe area, there is no urgent need to be connected to the network. So, mobile nodes may get disconnected from the network, which can affect the obtained average PDR recorded in that zone. Moreover, the tactical nodes have a low average PDR value, because zone 4 contains the most important number of persons (medical teams, civilians, media, etc.) compared to the other zones in the whole disaster area. Therefore, the reason for low PDR is mainly the radio signal blockage by the human bodies rather than being out-of-range. For the same reason, the number of re-transmissions increases and affects consequently the Average Round Trip Time Delay.

3) Average End-to-End Link Quality Estimation per zones: The E2E LQE results for mobile and tactical nodes are depicted in Figure 9. The best performance is recorded in zone 1 and 2 similarly for mobile and tactical nodes. The average E2E LQE is used for routing decisions in ORACE-Net, when the node is disconnected, routing table is empty and E2E LQE is not considered. For that reason, the average E2E LQE in zone 4 is higher than 0.9, because the average E2E LQE is only calculated when a node is connected with available route to the CC node. This observation leads to the fact that the E2E LQE is a relevant metric to consider in tactical disaster relief routing.

4) Average Round Trip Time Delay for mobile nodes per zones and hops: Figure 10 shows the average round trip time delay for the mobile nodes by zones and hops in milliseconds. As can be seen, the best performance is recorded in zone 1. The delay increases slightly from zone 1 to 3 and it reaches 29 ms. Results of the RTT delay are coherent with the average PDR explained above. Indeed, the delay increases significantly in zone 4 and with 4 hops, reaching up to 72.5 ms over 4 hops and 55ms in zone 4. Definitely, the significant delay recorded is not caused only by radio signal mitigation by the human bodies and obstacles as explained in V-B2, but also due to the low TX-power configured on the devices, which is reduced to 0 dbm. 5) Average Disconnections for mobiles nodes per zones and hops: The average disconnections for the mobile nodes is shown in Figure 11. The lowest disconnection rate is recorded in zone 1 and it is equal to 2%. Whereas, the best performance by hops is within 1 hop and equal to 12.01%. The network coverage in zone 1,2 and 3 is better than zone 4, that's why the highest average disconnections is recorded in zone 4. Additionally, the average disconnections within 3 hops is also relatively high (i.e, 37.15%). Figure 7 shows that 65% of the 3 hops are recorded in zone 4. This explains, that the average disconnections within 3 hops is high because the mobile nodes were in zone 4. Therefore, in the considered scenario, the mobility of the nodes decreases the average disconnections. Finally, please note that according to our scenario, zone 1, 2 and 3 are the most critical zones in the rescuing operations. Hence, in zone 1, 2, and 3 the protocol is more efficient than in zone 4.

VI. CONCLUSION

In this work, we considered the issue of tactical mobile ad-hoc communications inside a disaster area. We proposed a new routing approach which relies on end-to-end link quality estimation and shortest path for routing decisions. We conducted extensive experiments using eight tactically deployed wireless devices and two smart phone devices on which we implemented ORACE-Net protocol. Then, we evaluated the protocol in a real indoor scenario. Despite the important interference inside and outside the office, the experiments show that the proposed approach provides a good average connectivity and average packet delivery rate. Further, we observe a decrease in round trip time delay for the mobile nodes compared to the tactical deployed nodes. As future works, we will investigate the performance of ORACE-Net by connecting on-body sensors to the smart phone devices in order to send the vital data of the rescuers and victims to the command center.

Fig. 1 .

 1 Fig. 1. Routing tables after DRE phase (for Nodes 7, 5 and 8) when the 1 st wave of ADV reaches all nodes. Please note that, Nodes Xs are base stations deployed by the rescue teams while they are moving towards the incident area. Route from Node 7 to the CC node is represented by the bold dashed line.

  Fig. 2. Reverse Route Establishment (i.e., RRE) based on data packets.

Algorithm 2

 2 Reverse Route Establishment Algorithm (Node 'j') 1-RX (SRC, DST, Sender, DAT A P acket ) 2-Update_Neighbors_Table(DAT A P acket ) if (E2E LQE (DAT A P acket ) > E2E LQE (Route)) OR (E2E LQE (DAT A P acket ) == E2E LQE (Route) AN D Hop Count (DAT A P acket ) ≤ Hop Count (Route)) then Update_E2E LQE (DAT A P acket ) Update_Hop Count (DAT A P acket ) Update_Routing T able (DAT A P acket ) end if if (DAT A P acket (Seq N umber ) == already_broadcasted) then 3-Drop_Duplicated_DAT A P acket (Seq N umber ) 4-Go To 1. else 5-TX (SRC, DST=CC_node, Sender=j, To_Nexthop, DAT A P acket ) 6-Go To 1 end if

Fig. 3 .

 3 Fig. 3. (a) ORACE-Net System-Oriented Stack over Linux and Android. (b) ORACE-Net Android Application Architecture

Fig. 4 .

 4 (a) Testbed: A photo of the ORACE-Net mobile devices displaying the real-time events (received Hello and ADV packets) and the current route. (b) Labeeb-IoT [20] interface (on the right) shows the variation of the Hopcount for the connected nodes(mobiles and statics) over the time.

Fig. 5 .

 5 Fig. 5. Experimentation Scenario and Data Flow from Deployed Nodes to Labeeb-IoT Platform. Command Center (CC Node) is placed at the Back Gate (BG), ORACE-Net Android Devices (OAD) are mobile devices carried by the rescuers. The tactical ORACE-Net network is made by the ORACE-Net Linux Devices (OLD). Various experimentation area is divided into 4 zones. All collected data does through CC Node to Labeeb-IoT platform. A real-time dynamic topology website displays instantly the network topology.

Fig. 6 .

 6 Fig. 6. Snapshot of the network topology after 24 minutes and 13 seconds of the experimentation.

Fig. 7 .

 7 Fig. 7. Zone, Hop count, Delay and E2E-LQE variation during the experimentation (1 hour) for a smart phone mobile node.

Fig. 8 .

 8 Fig. 8. Average Packet Delivery Rate per zone for Mobile and Tactical static nodes.

Fig. 9 .

 9 Fig. 9. Average End-to-End Link Quality Estimation per zone for Mobile and Tactical nodes.

Fig. 10 .

 10 Fig. 10. Average Round Trip Time Delay per zone for Mobile nodes.

Fig. 11 .

 11 Fig. 11. Average Disconnections per zone for Mobile nodes.

TABLE I EXPERIMENTATION

 I PARAMETERS AND CONFIGURATION SETTINGS Average Packet Delivery Rate, E2E LQE , Average Round Trip Time Delay, and Average Disconnections. The Average Packet Delivery Rate is an application layer metric that provides the average of the received data packets on Labeeb-IoT platform against the data packets sent by each node of the network. The E2E LQE is calculated by ORACE-Net protocol as detailed in Section III. The Average Round Trip Delay is the time for an ICMP (ping) protocol to send a packet and get the acknowledgment between a node and the CC node. Also the ICMP protocol provides whether a node is connected

		General Settings
	Parameter	Setting
	Tactical base station nodes	8 (raspberry pi 2) OS: Raspbian v8.0
	Mobile nodes	2 (Samsung Galaxy S3-I9300 -rooted) OS: Android 4.2 CyanogenMod 10.0
	Wireless mode	Ad hoc
	ESSID	CROW2
	Wireless standard	IEEE 802.11n / 2.412 GHz
	Transmission power	0 dBm
	Experiment area	30m × 150m
	CC-node connection	Ethernet to Internet WiFi to ORACE-Net network
	Number of iterations	3
	Experimentation duration	1 hour / iteration
		-Smart phone: 2100 mAh Li-Ion (3.7v)
	Power batteries	-Raspberry-Pi: 10000 mAh Li-Ion (12v)
		-CC-node : 12v power supply
	ORACE-Net Protocol Settings
	Application layer	MQTT client used for pushing data into Labeeb-IoT platform
	MQTT message size	30 KB
	MQTT message interval	1s
	Hello/ADV packet size	20 / 25 Bytes
	Hello and ADV intervals	3s
	Multicast address/port	224.0.0.1 / 10000
	metrics:

TABLE II

 II

		CORRELATION BETWEEN THE METRICS
		E2E-LQE	Zone	Hops	Delay
	E2E-LQE	-	-0.1780	-0.4225	-0.0176
	Zone	-0.1780	-	0.1069	0.0933
	Hops	-0.4225	0.1069	-	6.0642e-04
	Delay	-0.0176	0.0933	6.0642e-04	-

ACKNOWLEDGMENT

This publication was made possible by NPRP grant #[6 -1508 -2 -616] from the Qatar National Research Fund (a member of Qatar Foundation). The statements made herein are solely the responsibility of the authors.