HELPER: Heterogeneous Efficient Low Power Radio for Enabling Ad Hoc Emergency Public Safety Networks

TL;DR

This paper introduces HELPER, a low-power heterogeneous radio system for rapidly establishing self-sufficient ad hoc emergency networks, enhancing communication during disasters with improved routing and network longevity.

Contribution

The paper presents a novel cross-layer optimized routing algorithm and a prototype HELPER device that enables quick deployment of resilient emergency communication networks.

Findings

SEEK routing algorithm extends network lifetime by up to 53%.

HELPER network supports text messaging, live maps, and distress signals.

Prototype demonstrates feasibility of emergency communication in disaster scenarios.

Abstract

Natural and man-made disasters have been causing destruction and distress to humanity all over the world. In these scenarios, communication infrastructures are the most affected entities making emergency response operations extremely challenging. This invokes a need to equip the affected people and the emergency responders with the ability to rapidly set up and use independent means of communication. Therefore, in this work, we present a complete end-to-end solution that can connect survivors of a disaster with each other and the authorities using a completely self-sufficient ad hoc network that can be setup rapidly. Accordingly, we develop a Heterogeneous Efficient Low Power Radio (HELPER) that acts as an access point for end-users to connect using custom website application. These HELPERs then coordinate with each other to form a LoRa based ad hoc network. To this end, we propose a novel cross-layer optimized distributed energy-efficient routing (SEEK) algorithm that aims to maximize the network lifetime. The HELPER is prototyped using WiFi enabled Raspberry Pi and LoRa module that is configured to run using Li-ion batteries. We implement the required cross-layer protocol stack along with the SEEK routing algorithm. We have conducted demonstrations to establish the feasibility of exchanging of text messages over the HELPER network, live map updates, ability to send distress messages to authorities. Emergency responders can leverage this technology to remotely monitor the connectivity of the affected area and alert users of imminent dangers. SEEK algorithm was shown to outperform a greedy geographical routing algorithm implemented on HELPER testbed by up to 53 % in terms of network lifetime and up to 28 % in terms of throughput. Overall, we hope this technology will become instrumental in improving the efficiency and effectiveness of public safety activities.

Figures

Tables

Table 1. Table 1: Summary of Technology

System	Users	Standard/ Band	Design Focus	Operation/ Routing	Hardware Eval
TETRA [11]	ER	TETRA Release 1	Interoperability	Centralized	Yes
TEDS [13]	ER	TETRA Release 2	Interoperability	Centralized	Yes
APCO 25 [10]	ER	Project 25	Interoperability	Centralized	Yes
Satellite [9]	ER	C & Ku	Remote Connectivity	Centralized	Yes
Avionic [22]	ER	VHF	Remote Connectivity	Centralized	Yes
Haiti [23]	EU	WiMAX and WiFi	Connectivity	Centralized	Yes
BRCK [16]	EU	3G or LTE WiFi	Connectivity	Centralized	Yes
Gomez et al [21]	Both	LTE	Distributed LTE	Centralized and D2D	No
Nishiyama et al [14]	EU	WiFi	Smartphone Relay	OLSR and Epidemic	Yes
RRT [17]	Both	Not Specified	Reliability	RRT	No
TeamPhone [18]	Both	WiFi	Energy Efficiency	AODV and Opportunistic	Yes
WIDENS [27]	ER	Enhanced 802.11	Rapid Deployment	OLSR	No
Kanchansut et al [28]	ER	WiFi and Satellite	Efficient Broadcast	OLSR	Yes
Chandra et al [30]	ER	Zigbee	Energy Efficiency	Zigbee Mesh	Yes
Ali et al [15]	EU	LTE	Energy Harvesting	D2D	No

Table 2. Table 2: Heterogeneous wireless link parameters

Features	WiFi (802.11 b/g/n)	LoRa
Frequency Range	$2.4\mathrm{GHz}$	$915\mathrm{MHz}$
Bandwidth	$20\mathrm{MHz}-40\mathrm{MHz}$	$7.8\mathrm{kHz}-500\mathrm{kHz}$
Transmission Range	Medium	High
PHY techniques	DSSS, OFDM, MIMO-OFDM	CSS, FSK [44]

Table 3. Table 3: Neighbor Table of node i 𝑖 i

Node ID	Distance to Destination	Queue Backlog	Residual Battery Energy	Goodput
$j$	$d_{js}$	${𝚚}_j$	${𝙴}_r^j$	$G_{ij}$
$k$	$d_{ks}$	${𝚚}_k$	${𝙴}_r^k$	$G_{ik}$

Table 4. Figure 17: 6-node HELPER Network for quantitative evaluation

Parameters	Values
Payload Size	$200\mathrm{Bytes}$
Packet interval	$100\mathrm{ms}$
Physical Layer	LoRa
Bandwidth	$125\mathrm{kHz}$
$E_{ini}$	$25J$
Duration	$120\min$

Equations

$${\eta }_{ij}=\frac{{\mathrm{R}}_b^{ij}\left(1-{\mathrm{e}}_b^{ij}\right)}{{\mathtt{P}}_{ij}}=\frac{{\mathrm{G}}_{ij}}{{\mathtt{P}}_{ij}}$$

$${\mathcal{U}}_{ij}={\eta }_{ij}\left(\frac{\max \left[\Delta {\mathcal{Q}}_{ij},0\right]}{{\mathtt{q}}_i}\right)\left(\frac{d_{is}-d_{js}}{d_{is}}\right)\left(\frac{{\mathtt{E}}_r^j}{{\mathtt{E}}_0^j}\right),\forall j\in {\mathbb{NB}}_i$$

$${\mathcal{P}}_1:\text{Given}$$

$$:{\mathbb{NH}}^{\ast },{\mathbb{T}}^{\ast }$$

$$:\sum _{i\in {\mathbb{N}}_{net}}\sum _{j\in {\mathbb{NB}}_i}{\mathcal{U}}_{ij}$$

$$:$$

$${\mathrm{R}}_b^{ij}\le C_{ij},\forall i\in {\mathbb{N}}_{net},\forall j\in {\mathbb{NB}}_i$$

$${\mathrm{e}}_b^{ij}>{\mathrm{e}}_{b\ast }^{ij},\forall i\in {\mathbb{N}}_{net},\forall j\in {\mathbb{NB}}_i$$

$${\mathtt{E}}_r^i>0,\forall i\in {\mathbb{N}}_{net}$$

$${\mathtt{q}}_i\ge 0,\forall i\in {\mathbb{N}}_{net}$$

$$[j^{\ast },{\mathrm{T}}_{ij}^{\ast }]=\arg \underset{j}{\max }{\mathcal{U}}_{ij},\forall j\in {\mathbb{NB}}_i$$

$${\overline{Th}}_{net}=\frac{T{h}_{net}}{T{h}_l}$$

Full text

To prove the feasibility of the solutions, we prototype the HELPER using WiFi enabled Raspberry Pi and LoRa module that is configured to run using Li-ion batteries. We implement the required cross-layer protocol stack along with the SEEK routing algorithm and develop a website application that an end-user can avail to connect using any device such as smartphones, tablets, laptops etc. We have conducted demonstrations to establish the feasibility of exchanging of text messages over the HELPER network, live map updates, ability to send distress messages (like 9-1-1 calls) to authorities. In the context of authorities, we have shown how they can leverage this technology to remotely monitor the connectivity of the affected area, alert users of imminent dangers and share resource (water, food, first aid) availability information. We have also conducted an extensive numerical evaluation of SEEK algorithm against a greedy geographical routing algorithm using the HELPER testbed. Results showed up to $53\%$ improvement in network lifetime and up to $28\%$ improvement in throughput. Overall, we hope this technology will become instrumental in improving the efficiency and effectiveness of public safety activities.

††journal: Ad Hoc Networks

ACK Acknowledgment ACN Availability Confirmation AH Aerial HELPER AODV Ad hoc On-Demand Distance Vector AP Access Point API Application Programming Interface BE Backoff Exponent BER Bit Error Rate BI Beacon Interval CAP Contention Access Period CAD Channel Activity Detection CC Convolutional Coding CCA Clear Channel Assessment CDMA Code Division Multiple Access CFP Contention Free Period CSMA/CA Carrier Sense Multiple Access/Collision Avoidance CSMA/CD Carrier Sense Multiple Access/Collision Detection CTS Clear-to-send DMT Discrete Multi-Tones D2D Device-to-Device DoA Direction of Arrival DoD Department Of Defense ECC Error-Correction Code EMI Electromagnetic Interference ER Emergency Responder ERC Emergency Response Center EU End User FCC Federal Communications Commission FEC Forward Error Correction FEMA Federal Emergency Management Agency FSM Finite State Machine FSO Free Space Optics FOV Field Of View GPS Global Positioning System GTS Guaranteed Time Slots HTL Hop-To-Live IM/DD Intensity-Modulation Direct-Detection IoT Internet of Things ISM Industrial, Scientific and Medical ISR Intelligence, Surveillance, and Reconnaissance LOS Line of Sight LPI/LPD Lower Probability of Intercept/Lower Probability of Detection LTE Long-Term Evolution MAC Medium Access Control MANET Mobile Ad Hoc Network MH Mobile HELPER MUI Multi-User Interference NAV Network Allocation Vector NB Number of Backoffs ND Network Discovery MC-CDMA Multi-carrier Code Division Multiple Access (CDMA) NLOS non-Line Of Sight NRL Naval Research Labs OAI Optimization Assisting Information OCDMA Optical Code-Division Multiple Access OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access OLSR Optimized Link State Routing PHR PHY Header PHY Physical QoS Quality of Service RA Random Access RES Reserve Sectors RF Radio Frequency RPI Raspberry Pi RSSI Received Signal Strength Indication SH Static HELPER SNR Signal-to-Noise Ratio SWaP (Size, Weight, and Power) TDD Time Division Duplex TDMA Time Division Multiple Access TIA Telecommunication Industry Association USRP Universal Software Radio Peripheral UVC Ultraviolet Communication VHF Very High Frequency VLC Visible Light Communication V2I Vehicle to Infrastructure V2V Vehicle to Vehicle Web App Website Application WEA Wireless Emergency Alerts WiFi Wireless Fidelity WiMAX Worldwide Interoperability for Microwave Access WSN Wireless Sensor Network

1 Introduction

In the past years, several lives have been devastated by hurricanes, tsunami, floods, earthquakes, and other natural disasters. Similar natural and man-made disasters are undesirable but sometimes unavoidable [2, 3]. Even if the disasters may vary in intensity, nature, and duration of occurrences some of the challenges faced during this period are similar. In these scenarios, one of the most critical infrastructures affected is often communication networks [4, 5]. Today’s world is heavily reliant on wireless communication. This is evident from the fact that $99\%$ of the population is covered by at least 3G network in the United States [6]. Similarly, authorities like Emergency Response Center (ERC) setup by agencies like Federal Emergency Management Agency (FEMA) are heavily reliant on wireless communication for information gathering, command, and control. There are also several disaster alert system [7] that relies on wireless communication to relay the message. For example, Grillo sensor network (Mexico) is a network of seismic sensors that will sense and alert local users about the seismic activity. MyShake (U.S) is a mobile application based solution which leverages the accelerometers of smartphones to detect seismic vibrations and sent information for analysis to the Berkeley Seismological Laboratory for a final check before alerting the user. Citizen Flood Detection (U.K) network is based on sensors installed under water bridges to keep a tab on the water levels using echolocation and update the flood maps while alerting the connected users over the Internet. Clearly, wireless communication is an essential component to maintain connectivity for such alert systems, Emergency Responders as well as affected individuals when traditional infrastructures like cell towers are affected or unavailable.

Several steps have been taken to enable wireless communication between ERs in such situations [8, 9, 10, 11, 12, 13] with an objective to improve interoperability, reliability, and accessibility. In comparison, there are few solutions designed to connect the affected survivors to the ERs and the ERCs [14, 15, 16, 17, 18]. Further limited are the solutions that have been implemented and prototyped to establish feasibility [16, 18, 14]. This aspect of emergency communication is critical to enable rapid assistance, recovery and ensure the safety of the people in the affected area. Realizing this gap, Mozilla and National Science Foundation (NSF) launched Wireless Innovation for a Networked Society (WINS) challenge to enable rapid off-the-grid connectivity during the times of disaster. Motivated from the challenge, in this work, we focus on designing a solution (hardware and software) that can be deployed by civilians (in their households) and ERs (roadside or other locations) to establish an infrastructure-less network that enables communication between End Users, ERs, and ERC during the aftermath of a disaster.

There are several challenges and requirements that have to be considered to enable such technology that can be accessed by everyone in an emergency scenario. Since there is a high probability that pre-existing infrastructure like base stations, cables etc. may be partially or completely damaged during the disaster, the solution proposed for emergency communication must be self-sustained. The solution should be readily accessible to EU such that there is no learning time or contingencies for them to be connected to the network. In other words, it should be as simple as people walking into an airport terminal and connecting to a Wireless Fidelity (WiFi) Internet network within seconds. There might also be a shortage or absence of electricity during this period leading to the demand for energy efficient solution. Another critical aspect will be the ease of deployment and cost associated with the technology and the coverage it provides. Since the topology of the target area may vary from tens to thousands of $km^{2}$ based on the magnitude of the disaster, the network must be designed in a distributed manner to ensure scalability. Due to the ad hoc nature of the network, there could arise network holes which may isolate parts of the network. One way to mitigate this problem is by deploying dense networks where density is defined as the average number of neighbors for each node in the network. This can be accomplished by using a physical layer solution that provides extremely long range links while maintaining energy efficiency. Finally, an ideal solution should be portable, low cost and energy efficient such that large networks can be deployed and sustained within a short period of time.

In this paper, we develop a Heterogeneous Efficient Low Power Radio (HELPER) ad hoc network for enabling emergency wireless communication as shown in Fig. 1. The proposed end-to-end ad hoc networking solution and supporting software is capable of establishing an independent, low cost, lower power wireless network for off-the-grid users during the aftermath of a disaster. One of the objectives of this work is to restrict the cost of the proposed device as much as possible such that each household can have one in their emergency kit and easily set it up when other communication infrastructures are disrupted. These HELPERs will form a wireless ad hoc network connecting users among themselves and to a ERC. The goal is not to provide a network with the highest throughput or minimize delay rather maximize sustained connectivity through energy efficient operation and provide key services. These services will include text and voice messages within the neighborhood, the ability to share resource information (water, food, gas, electricity, and internet) and the ability to send distress messages to the ERC. On the other hand, the ad hoc network will also be used by the ERC to remotely monitor the connectivity of the affected area and send alerts regarding imminent dangers to the connected EU.

2 Related Work

The need for a robust communication system during the recovery period after a disaster is evident from the previous discussions. Accordingly, several wireless communication technologies have been developed for public safety [9, 19]. TETRA [11] is a telecommunication standard for the private mobile digital radio system that provides an interoperability standard for equipment from multiple vendors. The services provided include voice calls (individual call, group call, broadcast call) with a data rates from $2.4$ $\mathrm{kbit/s}$ to $28$ $\mathrm{kbit/s}$. TETRA Release 2, known as TETRA Enhanced Data Service (TEDS) [13] has been deployed in United Kingdom [12] consisting of $3000$ base stations providing national coverage. Similarly, in the United States, Project 25 (or APCO 25) is a standard setup for public safety communication by Telecommunication Industry Association (TIA) that ensures interoperability, spectral efficiency and is gaining acceptance worldwide for public safety application [10]. The protocol supports encrypted communication with a range of few km with data rates up to a maximum of $9.6$ $\mathrm{kbit/s}$. Additionally, there are several instances where commercial cellular wireless communication systems have been used as an emergency network. For example, Federal Communications Commission (FCC) in a white paper [20] and the authors of [21] recommends an approach for public safety broadband communications that leverage the advantages of Long-Term Evolution (LTE) technologies. All these approaches mentioned above requires fixed infrastructure, which can be significantly degraded or destroyed during the disaster rendering these services infeasible. An alternative solution that does not require pre-existing on-ground infrastructure is the use of satellite networks. The satellite network can provide access to mobile or fixed terminals using various frequency bands including C-Band and Ku Band. While the fixed terminal can achieve up to $1.5$ $\mathrm{Mbits/s}$ data rate, the mobile terminals can achieve $256$ $\mathrm{kbit/s}$ [9]. Another approach to sustaining communication when on-ground infrastructure is damaged is airborne communication using avionic communication through helicopters. The traditional avionic communication is in the Very High Frequency (VHF) band and can be used in three main configurations [22], (i) the system deployed as an aircraft repeaters, (ii) a base transceiver station on an aircraft or (iii) a complete system on an aircraft. Avionic communication is not cost-effective but is generally used after a large natural disaster in a rural area that does not currently have any alternative. Overall, these solutions are designed for ERs and cannot be cost-effectively extended to enable communication between EUs and ERs during an emergency. During the aftermath of the earthquake in Haiti, connectivity was enabled for $100$ holding centers for displaced people using Worldwide Interoperability for Microwave Access (WiMAX) and WiFi [23]. WiMAX was also used during the 2004 tsunami in Indonesia and after hurricane Katrina in the Gulf Coast in 2005 [9]. This requires setting up a centralized WiMAX system to provide connectivity to EU. Any such centralized network will limit the scalability of the network in cases where the affected area is large.

As discussed earlier, it is essential to overcome the reliance on infrastructure and hence ad hoc networks have been identified as a preferable solution for such scalable networks [24, 25, 14, 26, 17, 27, 28, 29, 18, 15]. The great east Japan earthquake and tsunami motivated authors of [14] to develop Device-to-Device (D2D) communication capabilities between smartphones to send emergency messages in areas with affected infrastructure. Accordingly, the authors develop a prototype and conduct an experimental evaluation in Sendai city which was one among the affected areas. They used Optimized Link State Routing (OLSR) and epidemic routing protocols to achieve communication between source and destination. In [30], the authors propose a location-aware wireless mesh network to assist ER in providing medical support. Zigbee technology that operates in $2.4$ $\mathrm{GHz}$ band was used as the physical layer. An emergency and disaster relief system called Critical and Rescue Operations using Wearable Wireless sensors networks (CROW2) is proposed in [26]. The authors propose an end-to-end system that employs an Optimized Routing Approach for Critical and Emergency Networks (ORACE-Net) routing protocol. ORACE-Net accesses every end-to-end link with regards to its quality (end-to-end link quality estimation) to perform multi-path routing. CROW2 is designed specifically to offload data from the disaster area to ERC but does not provide any provisions for the EU to use the network to gather information for themselves. The authors of [17] propose to use smartphones to form an ad hoc network using a reliable routing mechanism. Reliable Routing Technique (RRT) [17] uses a broadcast based routing technique to improve reliability. Broadcasting every message to determine routes may lead to excessive and non-uniform energy consumption leading to some devices being excessively drained of energy causing network holes. In contrast, WIreless DEployable Network System (WIDENS) [27] is a European Project aimed to set up rapidly deployable emergency services. The system architecture uses a cross-layer interface to provide enhanced Medium Access Control (MAC) and physical layer interaction. It uses OLSR protocol at the network layer. OLSR is also used by [28] that aims to provide an efficient broadcast algorithm to reduce network overhead induced by the control packets. The proposed prototype in [28] uses a hybrid of satellite and WiFi connectivity to connect the ERC to the affected sites. In addition to considering energy-efficient routing, the choice of the physical layer will also be essential in determining the network lifetime and the operational feasibility in energy constrained scenarios. Therefore, the use of WiFi can be an ideal choice to connect to the EU but may not be the ideal choice to form ad hoc network that might have to span over several hundreds of $km^{2}$. The choice will always be a trade-off between energy consumption, range and data rate and hence should be made considering the requirement at hand.

Next, we look at some of the emergency ad hoc networking solutions that aim to achieve the required energy efficiency. In [29], the author emphasizes on the importance of energy efficient operation in emergency conditions and thereby designs Minimum Power Routing (MPR) protocol that chooses routes that require minimum power using Bellman-Ford algorithm which adapts to the changing channel conditions (noise and interference). While this may provide optimal energy efficiency in terms of energy consumed per bit delivered, this may not be the optimal routing strategy for maximizing the entire network’s lifetime. In other words, this may lead to some nodes being over-utilized for routing packets in the network depleting these nodes of energy causing network holes. The authors of [18] propose TeamPhone that uses smartphones to form ad hoc networks using WiFi. TeamPhone uses opportunistic routing or Ad hoc On-Demand Distance Vector (AODV) for routing and propose to employ grouping technique along with a wake-up schedule to conserve energy. This sleeping technique can be adopted by emergency ad hoc network but cannot substitute an energy efficient distributed routing algorithm. An interesting framework is proposed in [15] that enables nodes to harvest energy from an undamaged base station (source) and then act as a relay to carry the information to an area that does not have direct access to the source. The authors propose an optimal communication route for networks during an emergency to minimize end-to-end disconnection and reduce energy consumption while introducing the concept of Radio Frequency (RF)-based energy harvesting. Clustering is an ideal choice for their framework as the energy harvesting and coordinated operation is assumed between nodes but in deployments where energy harvesting is infeasible, clustering may lead to uneven consumption of energy or require frequency re-clustering procedure that will eventually lead to larger overhead. We have summarized the above discussion in Table 1.

Therefore, in this work, we develop an emergency ad hoc networking solution, HELPER Network with an objective to connect EUs of an affected community to each other and the responding authorities. The significant contributions are summarized below,

We propose an end-to-end solution that includes Website Application (Web App) that connects EU’s mobile devices to the HELPER using WiFi links. The HELPERs form an energy efficient ad hoc network using low power, long-range LoRa links to connect all EUs to each other and ERC.

• 2.

The proposed capabilities include resource information sharing, emergency distress messages to ERC, imminent danger alert from ERC to all connected EUs and the ability to send text and voice messages between EUs.

• 3.

To accomplish this, we design and implement a cross-layer protocol stack that is used by each HELPER to perform optimized routing by using information acquired from different layers.

• 4.

Additionally, we propose and implement a novel distributed energy efficient routing algorithm that aims to maximize the network lifetime.

• 5.

Finally, we prototype a portable, cost-effective and energy efficient solution to conduct proof-of-concept demonstration. We use the six-node network to conduct extensive numerical evaluations of the proposed routing algorithm.

3 Concept of Operation

3.1 Types of HELPERs

As shown in Fig. 1, we envision three types of HELPERs in the proposed network. These three HELPERs have the same capabilities in terms of wireless communication and networking but differ in the context of mobility, size, and survivability (duration of operation).

Static HELPER** (SH):** These HELPERs are reasonably portable yet considered relatively static as they are envisioned to be operated in a relatively fixed location (terrace of household, hospitals, roadside, public buildings etc.) with abundant sunlight or other energy sources. These HELPERs have the largest battery and solar panel that supports 24/7 operation. The design goal of the SH is to survive at least a day or two in the absence of sunlight and to extend for multiple days in presence of ample sunlight. The components used to prototype the proposed SH is depicted in Fig. 2. The main board used is a Raspberry Pi (RPI) 3b [31]. The choice was motivated from the low cost, size, and large open community support for RPI development. Additionally, it is enabled with WiFi (802.11 b/g/n) and will be set up to operate as an access point for EU. The WiFi link provides a comparatively lower range of coverage but is an essential choice taking into account the widespread usage of WiFi by today’s devices (smartphones, tablets, laptops etc.). This will ensure a seamless connection from a users point of view due to the abundant familiarity in accessing WiFi.

To establish networks covering larger areas, we choose LoRa [32] to set up low power, long-range links ($2$-$5\;\mathrm{km}$ in urban areas and $15\;\mathrm{km}$ in suburban areas [33]) between HELPERs. LoRa is emerging as a viable communication choice for Internet of Things (IoT) devices that strive to operate at low power yet achieve long-range. The long range of LoRa ensures dense networks because a larger number of these nodes may be deployed within the communication range. This ensures the availability of multiple routes to choose from such that energy based optimization can be performed. A Global Positioning System (GPS) receiver is also attached to the RPI. This will be used to acquire the location information to perform geographical routing and to indicate the location of the node when assistance needs to be dispatched. Lastly, we propose to use an Arduino microcontroller and power relay attached to the RPI. The Arduino and power relay can be used to put the system in a deep sleep mode to conserve energy when multiple devices are deployed in the same vicinity. Once the RPI has decided to sleep for a given duration of time, the signal is sent over to the Arduino board which in turn shuts the power relay which disables the RPI. The Arduino board uses its power management watchdog timers to keep the RPI in a low energy state for the entire sleep duration. The Arduino will then flip the power relay back on effectively restarting the RPI. This mechanism will enable energy preservation and cooperation between multiple HELPERs in the same vicinity.

Next, we discuss the envisioned power supply for the prototype. We have estimated that the system requires about $1\mathrm{Wh}$ to run at a $25\%$ duty cycle. Choosing the appropriate solar panel relies on current weather conditions, amount of daily sunlight and historical weather trends for that location. In a mostly sunny area, a $3$ or $4\;\mathrm{W}$ solar panel would be sufficient for 24/7 operation yet some areas may need a $10$ to $15\;\mathrm{W}$ solar panel. The solar panel will be attached to a solar controller. This solar controller has a $24\;\mathrm{Wh}$ lead-acid battery and a high-efficiency buck converter to the load. The $24\;\mathrm{Wh}$ battery will last an entire day on a full charge. The more expensive buck converter can be used to supply power to the system because a buck converter can commonly get up to $90\%$ efficiency, whereas a simple voltage regulator would have a $59\%$ loss of power coming from $12\;\mathrm{V}$ down to $5\;\mathrm{V}$. A factor that will affect the portability of the design is the battery system designed to operate 24/7. Li-Ion Batteries are the ideal choice to ensure portability but needs a complicated charging and discharging circuit whereas Lead-acid batteries have a simpler charge-discharge circuit but tend to be on the heavier side. The prototype designer can make a studied choice based on the deployment requirements.

Mobile HELPER** (MH):** We envision two versions of MHs. The first version that is indented to go on vehicles will not require a battery as it will draw energy from the vehicle itself. This version will have the smallest form factor but will have to operate within the vehicle itself. The second version of the MH will have the same design as the SH with the exception of eliminating solar panel and using a smaller battery to ensure more portability for ER and EU. The MH will use lightweight 18650 Li-Ion batteries as a power source with a boost converter to up the voltage to the required $5\;\mathrm{V}$ input of our devices. Li-Ion batteries have a much higher energy density compared to lead-acid batteries. Since the batteries will be easily swappable, discharged batteries can be removed to recharge while other charged ones can be used in deployed nodes. As the batteries do not need to supply a load while being charged, any off-the-shelf charger can be used. There is a trade space between the battery capabilities with energy storage and max amperage draw. For the MH, two $3000\;\mathrm{mAh}$ 18650 batteries will be used to power the device. Given the $1\;\mathrm{Wh}$ load from the device and two batteries that supply around $22\;\mathrm{Wh}$, the ER devices will be operable for a total of at least $8$-$9$ hours (22 hours in ideal scenarios considering only $25\%$ duty cycle and no loss) before needing to be recharged. In this work, we prototype six MHs for our experiments which we will see in the later part of this paper.

Aerial HELPER** (AH):** When the network is set up, based on accessibility, there might be parts of the network that is disconnected due to node failure, locally disruptive channel conditions or uneven distribution of HELPERs during the setup period. We refer to these gaps in the network as network holes. The goal of an AH is to identify these isolated HELPERs and act as a temporary sink node that retrieves information. The isolated HELPER can upload the information about the users currently connected to the given HELPER and this information is carried by the AH to the ERC. The AH also indicates which locations need more HELPERs to be deployed in order to fill the network holes. The AH are the most costly and least energy efficient (taking into consideration the energy for flight) among the three types of HELPERs but is required in critical scenarios where road access might be completely cut-off. More about the different deployment scenarios are discussed in the next section. To meet the needs of the AH, we propose to use an open style drone (see Fig. 4 ) that allows for the flexibility of programming a completely autonomous drone while minimizing the cost. The Erle Robotics Drone Kit also has the added benefit that the Erle Brian [34] uses RPI. Therefore, the development toolchain is the same as the MH and the SH. Therefore, these AHs will use the battery and RPI that are inherent to the drone itself.

3.2 Deployment Scenarios

We divide the deployment scenarios into three major cases based on accessibility and available resources which are discussed in detail below.

Scenario I (Full Accessibility and resources): In the first scenario, accessibility is not restricted and the ERs have all the required resources (vehicles, drones and a large number of ERs) to set up a HELPER network. In this scenario, the SHs can be placed in a strategical manner to ensure full coverage of the affected area with minimum deployment cost. The placement of the SHs will be under direct sunlight to enable 24/7 operation. The deployment of SHs can be relatively sparse as the HELPERs can be arranged optimally to ensure full coverage and extended lifetime. The MHs and AHs will also supplement this network during the rescue operation. AH will use BEACON packets (more about BEACON packets is described in Section 4) while flying over the affected areas to determine the HELPERs that might need replacement due to depletion of battery or absence of sunlight. Overall, there is more control over deployment of HELPERs and hence easier to provide full coverage and repair disconnected parts of the network.

Scenario II (Limited Accessibility): In the second scenario, the accessibility is highly limited during the initial stages. This implies that there will be limited options (few vehicles with HELPERs during initial stages) to deploy HELPER network. Therefore, a denser deployment of SHs will be necessary to ensure maximum connectivity and network lifetime. These HELPERs may be present in the emergency kits of households, or other buildings before the disaster strikes. Additionally, a large number of supplementary SHs can be deployed via air. The role of AH will also be critical in these scenarios to determine network holes (areas without coverage or isolated HELPERs). When isolated HELPERs are determined, AH will act as a temporary sink and will fly back to the ERC with this information. This will enable ERs to have access to survivor information in isolated areas and prepare rescue efforts. The AHs will also be able to plug the detected network holes by promoting ERC to deploy HELPERs to provide complete network connectivity.

Scenario III (Limited Accessibility and resources): In the third scenario, the assumption is the lack of access and resources. There is no availability of the costlier AH. Since the proposed SH and MH is highly cost-effective, multiple HELPERs can be deployed in a dense manner such that maximum area is covered for connectivity. The dense network will operate in an ad hoc manner bolstered by the proposed routing algorithm that aims to maximize the network lifetime.

4 HELPER Design and Implementation

In this section, we discuss the overall HELPER framework consisting of the communication protocol stack, novel routing protocol and discuss the corresponding packet structure, and packet handling while determining the necessary interactions between different layers to enable a cross-layered approach to optimize the network performance.

4.1 HELPER Cross-Layer Protocol Stack

The significance of cross-layer optimization in wireless communication has been widely studied [35, 36, 37, 38, 39, 40] across various domains and optimization problems. Identifying the advantages of cross-layer optimization there has been some work recently to develop cross-layer platforms to facilitate these technologies [41, 42, 43]. Figure 5 depicts the design concept of a HELPER and how the design is currently implemented in a modular manner on the selected platform. We will discuss the design considerations for each of these layers in detail in the upcoming sections.

4.1.1 Physical Layer

As discussed earlier, HELPER is enabled using two wireless technologies WiFi (802.11 b/g/n) and LoRa which gives it the heterogeneous nature of operations. The prominent reason behind using both these well established wireless technologies are as follows, (i) WiFi is ubiquitous in today’s devices and this will ensure seamless access for EUs, (ii) LoRa is becoming a prominent communication technology enabling IoT devices that requires low power, long-range wireless links and (iii) it is extremely cost-effective to use off-the-shelf physical layer to ensure low (Size, Weight, and Power) (SWaP). The features of the physical layer are shown in Table. 2. Though we use both WiFi and LoRa as wireless technologies to enable HELPER, only LoRa can be considered as the physical layer from the point of view of the ad hoc HELPER network. WiFi can be considered as the interface between the application layer and the service layer of the HELPER’s protocol stack as shown in Fig. 5.

The HELPER network stack interfaces to the LoRa radio module using the Radio Head and BCM2835 C++ libraries. This interface is implemented in an Application Programming Interface (API) that is utilized by the MAC layer to send and receive packets over-the-air. The API also provides functionalities for reading and writing radio parameters.

4.1.2 Data-Link Layer

One of the primary function of the data-link layer is negotiating the medium access. In the proposed HELPER network, just as we discussed the physical layer, we have two levels of medium access, (i) local WiFi links between HELPER and devices (phone, laptop, and tablets) of users and (ii) LoRa links between different HELPERs that form the ad hoc network. We use the standard off-the-shelf MAC protocol employed by WiFi (IEEE 802.11) to allow multiple users access to HELPERs within the local area. We have implemented a similar Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) based MAC protocol to setup multihop ad hoc network using LoRa with the intention to utilize the Channel Activity Detection (CAD) offered as a hardware feature on the RF95 LoRa. CAD is a valuable tool since LoRa uses spread spectrum transmissions. The spread spectrum is known to operate at low signal to noise ratio making traditional approaches like power detection with Received Signal Strength Indication (RSSI) unreliable. CAD helps to detect if there is ongoing transmission in the channel chosen within two symbols according to the RF95 hardware documentation. This feature can be leveraged to implement the MAC protocol for the multihop LoRa based network. Since WiFi and LoRa operate on different parts of the Industrial, Scientific and Medical (ISM) band (as shown in Table. 2) they do not interfere with each other’s operation.

Therefore, the data-link layer shown in Fig. 5 contains the control logic used by HELPERs to negotiate access to the wireless medium. It houses the Finite State Machine (FSM) used to implement the CSMA/CA like MAC protocol used by the HELPER network. As seen in Fig. 6, the traditional RTS (request-to-send), CTS (clear-to-send) handshake is used before transmitting a unicast data packet. The successful reception is followed by the receiver transmitting ACK (Acknowledgement) packet. In addition to this, a BEACON packet is broadcasted periodically by a HELPER that has not transmitted any control packet for a pre-determined duration. Each of these control packets (RTS, CTS, BEACON) carry information including, instantaneous backlogged queue length, residual energy, location and the observed goodput per neighbor, which we refer to as Optimization Assisting Information (OAI). In this manner, each HELPER gathers OAI from its neighbor and uses this updated information to perform optimized energy efficient routing (which will be discussed in detail in upcoming sections). Therefore, in implementation, the MAC layer continuously monitors the physical layer receive queue for inbound messages and handles them according to the current state of the FSM. All OAI received from the control packets are used to update the inputs to perform cross-layer optimization. Once the network layer has performed the required optimization and chosen the optimal next hop, the MAC layer negotiates the medium and forwards the data packets.

4.1.3 Network Layer

The network layer is responsible for packet queuing and routing. As shown in Fig. 5, the network layer interfaces to the service layer and data-link layer. When packets are received from the service layer or data-link layer, the network layer encapsulates/decapsulates network layer fields as needed and places packets in the appropriate queue. The network layer maintains two transmit queues: one for priority traffic and a second for best effort traffic. Each packet is sorted into one of these queues depending on application message type and other fields in the header. The energy efficient routing algorithm is used for routing unicast packets which ensure maximum network lifetime. Every broadcast packet contains a Hop-To-Live (HTL). Packets with HTL greater than zero are broadcasted by the receiving HELPER. In addition, the network layer uses shared memory to manage neighbor lists and OAI information in order to perform optimized cross-layer routing. The network layer also has access to HELPER’s current GPS location via libgps and stores it in its local OAI data which is then shared with neighboring HELPERs.

A critical aspect of the proposed HELPER network is its energy efficiency. Since the majority of energy consumption is attributed to the transmission of packets, routing becomes a significant aspect of the design. Accordingly, we define a utility function that takes into account energy efficiency, goodput and a measure of congestion (using differential backlog) to formulate an optimization problem with the objective to maximize network lifetime while maintaining reliable connectivity. Since the goal is to deploy a scalable network, we formulate a distributed version of the optimized routing algorithm such that each node can make its own routing decision based on the limited OAI gathered from its neighborhood.

System Model: To design the routing algorithm, we consider the most constrained scenario (scenario III of Section 3.2) which has restricted access and minimal resources. Accordingly, consider a dense multihop wireless ad hoc network comprising of several $N$ HELPERs (which we refer to as nodes in this section) modeled as a directed connectivity graph $\mathcal{G}(\mathbb{N}_{net},\mathbb{E})$, where $\mathbb{N}_{net}=\{H_{1},H_{2}...,H_{N}\}$ is a finite set of wireless transceiver (nodes), and $\mathfrak{L}(i,j)\in\mathbb{E}$ represents unidirectional wireless link from node $H_{i}$ to node $H_{j}$ (for simplicity, we also refer to them as node $i$ and node $j$). We assume $\mathcal{G}$ is link symmetric, i.e., if $\mathfrak{L}(i,j)\in\mathbb{E}$, then $\mathfrak{L}(j,i)\in\mathbb{E}$. Each node is assumed to have the transmission range $R$ based on the chosen transmit power $P_{t}$. As seen before, all the nodes are equipped with GPS and therefore the location (longitude/latitude) coordinates are known. The knowledge of node locations is important for a geographical/position based routing algorithms proposed in this work. In Fig. 7, the nodes within the transmission radius of $i$ will constitute its neighbors. Let us denote the set of neighboring nodes of node $i$ as $\mathbb{NB}_{i}=\{j,k\}$ and the sink (ERC) node as $s$. The location of $s$ can be predefined in every node or as in our case, this information is flooded at the time of network setup. In this formulation, we consider packets that have to be transmitted from node $i$ to sink $s$ but this can be extended to any source-destination pair.

The distance between any two nodes $i$ and $j$ is represented by $d_{ij}$. If a node $j$ exist within the transmission range of node $i$, there exists a link $\mathfrak{L}_{(}i,j)$, i.e., a wireless communication link $\mathfrak{L}_{(}i,j)$ exists when $d_{ij}\leq R$. The power consumed over $\mathfrak{L}_{(}i,j)$ or the power required by the source node ($i$) to transmit to a neighboring node ($j$) is denoted by $\mathtt{P}_{ij}$. The initial and residual battery energy at node $i$ can be denoted as $\mathtt{E}^{i}_{0}$ and $\mathtt{E}^{i}_{r}$ respectively. Every node maintains a queue that holds the outbound packets. Let $\mathtt{q}_{i}$ represent the instantaneous number of packets retained in the queue of node $i$, also called the queue backlog. The transmission bit rate and Bit Error Rate (BER) over $\mathfrak{L}_{(}i,j)$ are denoted by $\mathrm{R}_{b}^{ij}$ and $\mathrm{e}_{b}^{ij}$ respectively.

Routing Algorithm: The proposed diStributed Energy Efficient bacKpressure (SEEK) routing algorithm utilizes the geographic information of nodes, differential queue backlog, residual battery energy and transmission power levels to compute the optimal next hop. In this section, we will present a formal derivation of our utility function ($\mathcal{U}_{ij}$ with respect to $\mathfrak{L}_{(}i,j)$) and formulate the network optimization problem.

The utility function considers the following parameters associated with potential next-hop; (i) proximity to sink, (ii) differential queue backlog, (iii) residual battery energy, (iv) power required to transmit over the link and (v) the corresponding link throughput. This information is gathered from traditional control packets like RTS, CTS and BEACON packets. As discussed earlier, these packets will contain updated OAI and a PROBE field. In a realistic scenario, the real-time Signal-to-Noise Ratio (SNR) is unknown to the device. Therefore, measures derived from SNR estimated based on a radio propagation model might not be a suitable guideline for signifying transmission reliability over a link $\mathfrak{L}_{(}i,j)$. We, therefore, propose to use a PROBE field in the control packets to perform link probing [45, 46]. The PROBE field would contain a bit sequence known by the nodes in the network. Upon receipt of the control packet, each node will compute effective throughput (goodput) measure in bits per second ($\mathrm{bps}$). In our analysis, we prefer to use the term goodput to signify the effective number of bits successfully received. For example, once node $i$ receives a control packet from node $j$, it will compute the corresponding goodput measure ($\mathrm{G}_{ij}$) with respect to $\mathfrak{L}_{(}i,j)$ and transmission strategy, $\mathrm{T}_{ij}$ (which includes choice of $\mathrm{R}_{b}^{ij}$ and $\mathtt{P}_{ij}$). The energy efficiency of a given link can be expressed as a ratio between goodput and transmission power as [47],

[TABLE]

where $\mathcal{\eta}_{ij}$ gives the measure of number of bits successfully transmitted over $\mathfrak{L}_{(}i,j)$ per Joule of transmission energy. Another key factor that needs to be considered in routing is the differential queue backlog ($\Delta\mathcal{Q}_{ij}=\mathtt{q}_{i}-\mathtt{q}_{j}$) with respect to the source node ($i$) and next-hop ($j$) [48, 49, 50]. The queue backlog at the destination node is considered to be zero. Considering the queue backlog is necessary to mitigate congestion in the network and traditional backpressure algorithms has been shown to be throughput optimal [48]. Since achieving maximum throughput is not the sole objective of HELPER network, differential backlog is just one parameter in our utility function. The effective progress made by a packet can be represented as $d_{is}-d_{js}$. Choosing nodes that provide larger progress implies fewer hops to the sink node which in turn could lead to smaller energy consumption. Finally, to ensure uniform depletion of energy per node, we need to consider the $\mathtt{E}^{j}_{r}$ of potential next hops [51]. Therefore, we define our utility function as follows,

[TABLE]

$\eta_{ij}$ aims to improve the energy efficiency of the network. It is also interesting to note that the maximum value of $\mathcal{U}_{ij}=\mathcal{\eta}_{ij}$ when each of the three normalized terms is $1$. This implies that each of the other terms penalizes the utility function based on the instantaneous value. For example, a small differential backlog ($\mathtt{q}_{i}-\mathtt{q}_{j}<\mathtt{q}_{i}$) will dampen the value of $\mathcal{U}_{ij}$. Both $d_{is}-d_{js}$ and $\mathtt{E}^{j}_{r}$ will have similar effects on $\mathcal{U}_{ij}$.

The objective of the network is to maximize the summation of $\mathcal{U}_{ij}$ for all possible links $\mathfrak{L}_{(}i,j)$ in order to maximize the overall energy efficiency of the network. This, in turn, will ensure reliable communication while maximizing the network lifetime (which is defined as the time when the first node in the network depletes its energy leading to a network hole). The optimization problem is subject to residual battery energy, queue backlog, bit error rate, and capacity constraints. This is formulated as Problem $\mathcal{P}_{1}$ shown below,

[TABLE]

where the objective is to find the set of next-hop and transmission strategy for all nodes in the network which can be represented as $\mathbb{NH}^{*}=[\mathrm{NH}_{i}^{*}]$ and $\mathbb{T}^{*}=[\mathrm{T}_{ij}^{*}]$ respectively, $\forall i\in\mathbb{N}\;j\in\mathbb{NB}_{i}$. In the above optimization problem $\mathcal{P}_{1}$, $\mathbb{G}=[\mathrm{G}_{ij}]$, $\mathbb{E}_{r}=[\mathtt{E}^{i}_{r}]$ and $\mathbb{Q}=[\mathtt{q}_{i}],\;\forall i\in\mathbb{N}_{net},\;\forall j\in\mathbb{NB}_{i}$ denote the set of goodput measure, residual battery energy and queue backlogs respectively. The constraint 2 restricts the total amount of data rate in link $(i,j)$ to be lower than or equal to the physical link capacity. Constraints 3 impose that any transmission should guarantee the required BER. Finally, constraints 4 and 5 ensure the residual energy and queue backlog of each node will not have negative values. It can be seen that for solving the above optimization problem, nodes would require global knowledge of the network. Since the centralized optimization method is not a scalable solution, it motivates the need for a scalable distributed solution. We propose SEEK which will operate in a distributed fashion and enable each node to find the next-hop based on the local information available to them. Each node with a packet to transmit chooses an optimal next-hop and transmission parameters such that it maximizes its own local utility function. The probability of channel access will be controlled by utility based random backoff. This can be considered as a divide-and-conquer approach to solving the optimization problem in a distributed manner. Accordingly, every source node ($i$) will aim to maximize the utility function $\mathcal{U}_{ij}$ and select the optimal next-hop and transmission strategy as follows,

[TABLE]

Each node will maintain a neighbor table with node parameters of its neighbors and will update the table as needed based on information from the control packets. Considering the scenario in Fig. 7, the source node $i$ will listen to control packets and maintain a neighbor table as in table 3.

The ERC (sink) collects and disseminates vital information like availability of resources, drop-off locations, emergency updates for EU among others. ERC needs to strategically flood this information in the network to enable all HELPERs to obtain the updated information. This implies the requirement to implement one of the energy efficient flooding technique that has been widely studied in literature [52, 53].

4.1.4 Service Layer

The Service Layer provides a common interface between HELPER applications and the lower layers of the protocol stack. This layer communicates to HELPER applications using local sockets and the Network Layer via direct function calls. Messages received from applications are translated from HELPER Send format to HELPER Packet format (shown in Fig. 8) and are passed to the network layer. Messages received from the network layer are translated from HELPER Packet structure to HELPER Receive format and are then passed to the application. In the implementation, the Service Layer uses an MQTT messaging socket to communicate with the Web Application and messages are encoded using JSON. The Paho MQTT CPP and Rapid JSON libraries are used to implement the messaging to the application. The implementation is such that more application message types and message handling can be added in the future to expand the capabilities of the HELPER network.

4.1.5 Application Server

Users can join the HELPER network by connecting to a HELPER node via a WiFi or LAN connection. The HELPER nodes are configured to act as a WiFi access point, allowing users to connect their smartphones, laptops, tablets, etc. to the network. A wired connection to a HELPER node is also possible and is utilized by the ERC. Each node runs a web server that hosts the web applications. Once connected to a HELPER node, a user can launch a web application. Currently, two web applications are developed, one of EU and the other for ERC. These are discussed in detail in Section 4.4 and Section 4.5.

The web server interfaces to the HELPER network stack to send and receive data across the network. This interface is implemented using MQTT sockets. The web server and service layer both connect to the MQTT broker and setup two publish-subscribe channels. One channel is for sending messages from the web server to the HELPER stack and the other is for sending messages from the HELPER stack to the web server. The data sent on these MQTT sockets are in the Helper Send and Helper Receive formats of Fig. 8 and are encoded with JSON.

4.2 HELPER Packet Handling

The HELPER network consists mainly of two kinds of HELPERs; (i) HELPERs that are deployed in households, hospitals, and other building that residents (survivors of disaster) connect to and usually have limited power supply and (ii) HELPER that forms ERC and usually has an unlimited power supply. Accordingly, messages can be classified as EU messages and ERC messages. We describe each message types used by HELPER below,

4.2.1 End-User Messages

Emergency HELP Messages: A HELP message is used to indicate that an individual is in need of immediate assistance. This is similar to or a substitute for a 9-1-1 call when cell phone and other services are disrupted or inaccessible. All HELP messages are handled by HELPER in two ways. First, the HELP message is send destined for the ERC with maximum HTL. Additionally, at the service layers, these HELP messages are also broadcasted with a predefined HTL (currently set to $2$). The intention of broadcasting the HELP message with HTL$=2$ is to find a first responder who may be in the vicinity of the individual in distress to provide faster response rather than waiting for ERC to react. The HTL is limited to avoid excessive energy consumption and mitigate problems of congestion. Overall, the HELP message will enable users to alert authorities of their location, need, and situation when all other communication infrastructures are down.

Local Messages: Every user connected to a HELPER is able to chat with each other using Local Chat messages. These messages are exchanged using WiFi itself and do not have to use the LoRa on Physical Layer. These links can achieve high data rates and in future support video chatting as long as HELPER is plugged in and does not have energy constraints. Therefore, everyone in the range of a single HELPER can use local messaging to remain connected to each other. These messages are handled by the service layers itself and are not passed to the lower layers of the HELPER protocol stack.

Neighborhood Messages: A neighborhood message is a chat message that is transmitted to all immediate neighboring HELPERs. In the network layer, this is a broadcast message with an HTL of $1$. This message is intended to enable communication between the community in the close neighborhood (within  $2\;\mathrm{km}$ radius). These messages will be used by the community members to help each other and mark themselves safe even if they are not connected to the same HELPERs. The design is flexible enough such that the broadcast can be extended beyond immediate neighbors by setting appropriate HTL.

Resource Messages: A resource message is sent by a user to indicate that a resource (food, water, gas, medicine, internet, etc.) is available in proximity to the local HELPER. This message is transmitted to the ERC with an HTL set to maximum. The Responder Station aggregates these messages, approves them and transmits periodic HELPER resource update messages to let all the HELPERs in the network get the updated Map.

4.2.2 Emergency Response Center Messages

Network Discovery Message: A Network Discovery (ND) message is used at network initialization. The ERC broadcasts this ND message to its immediate neighbors. All HELPERs that receive this message use an efficient flooding technique to broadcast ND messages to other HELPERs. As the deployed HELPERs receive a ND, they reply with a HELPER Update Message containing their information (Node ID, location etc.). These are unicast messages to the ERC with a maximum HTL. In this manner, the ERC performs network discovery to map all the nodes that are actively deployed in an affected area.

HELPER ALERT Message: Similar to the Wireless Emergency Alerts (WEA) that is used over the cellular network, the ALERT message is intended to inform every connected user about an imminent threat like high winds, rising water level, flash flood, fires etc. This message is also distributed using an efficient flooding technique. Every user connected to a HELPER sees a message labeled from ERC and hence are aware of the steps to take to remain safe during the upcoming situation. This will be highly beneficial in situations where the cellular network is not operable due to infrastructural damage.

Resource Update Message: Once the ERC receives a resource message from EU connected to any of the HELPERs in the network, it has to first approve the resource update. Upon approval, the ERC floods the resource update message to the entire network using an efficient flooding technique. In this manner, every HELPER in the network receives updated resource information for users to access.

4.3 Applications

As discussed, to provide a complete end-to-end solution, we have developed two applications one for EU to connect to the HELPER network using their mobile devices and the second for ERC to remotely monitor the network and provide assistance and alerts to the EU. In this section, we describe the functionalities that have been enabled through these applications.

4.4 End-User Application

Every user connected to a HELPER via WiFi will be prompted to access the services of HELPER network by logging in to the Web App shown in Fig. 9. As you can see, the login page consists of the location of the HELPER (marked using a black marker) that the user is currently connected. The final version of the App will also have a short message describing the network and utilities to encourage people to use the HELPER network. Next, we describe features availed by the Web App for the connected EU to use.

Text and Voice Messaging: The primary goal of the HELPER Network is to keep individuals in the affected community connected. Therefore, an intuitive chatbox is developed for EUs to interact with and help each other and ERC. As shown in Fig. 9, there are three kinds of messages that can be sent/received by a user (as indicated by the 3 tabs or options in the pop-up menu).

The local messages are exchanged between users connected to the same HELPER. These messages go directly over WiFi and do not need to interact with the LoRa physical layer. These links can achieve high throughput since it is not bottle-necked by the lower data-rates of LoRa. In the future, video call and higher throughput applications can be enabled based on the availability of energy in the affected area. 2. 2.

Next, the message sent using Neighbor tab are broadcasted to $h$-hop neighbors (where $h$ is predetermined by the operator). The choice of $h$ would be a trade-off between energy consumption and range of connectivity. In this case, a message sent by a user to the neighbors is received by all users connected to all the HELPERs (black and blue markers) within $h$ hops from the source node. 3. 3.

Finally, and most importantly, the Emergency tab is used to send distress messages directly to the ERC to seek help during distress. These messages will be carried over a multi-hop path to the ERC and inform the ERC of the location where help is required. This serves as an alternative to 9-1-1 calls when the degradation of infrastructure renders traditional 9-1-1 calls infeasible. Similarly, ERC can broadcast ALERT messages so that each user is alerted to situations like high winds, rising water level, flash floods etc. The All tab displays all the above messages in one place.

Live Map Updates: A regional map with live updates on the availability of resources like gas stations, operational hospitals, food and water gas station, internet access, electricity etc are accessible to the connected users. The ERC will collect information about the availability of resources using HELPERs deployed in hospitals, stores, gas stations, households etc. Periodically, this information is flooded by the ERC in the ad hoc network to update the map at each HELPER. The periodicity of this flooding can be controlled by the ERC based on the update information and status of the network. This information sharing is accomplished as follows,

A connected user (ER or EU) who has information about available resources to share with rest of the users, drags and drops the corresponding resource on the known location on their local map.

• 2.

This action triggers a packet that is directed towards the nearest ERC. This packet is routed using the proposed SEEK algorithm towards ERC.

• 3.

Upon reception of the packet, a message containing the information about the type of resource and its location shows up on the ERC Application. Once the operator verifies this information, it is flooded to the rest of the HELPER network. The method of verification will be controlled by the agencies. This can be based on trusted nodes, the number of similar requests or physical verification using an on-field ER.

It can be argued that the above three-step process may incur a delay in disseminating information as compared to the information being flooded by the source HELPER itself without going through the ERC. While this may be true, authorizing any node to update resource information may lead to the propagation of misinformation, duplicate information, and overall larger energy consumption.

4.5 Emergency Response Center Dashboard

As shown in Fig. 5, at the ERC, a HELPER is connected to a PC using an Ethernet cable. ERC Dashboard with some critical features have been developed with the following capabilities,

Remote Monitoring: A ND phase can be initiated by using the Network Discovery Message button on the ERC Dashboard. Accordingly, the ERC broadcasts ND packet to its immediate neighbors. All HELPERs that receive this message use an efficient flooding technique to broadcast ND packet to other HELPERs. As HELPERs receive a ND packet, they reply with a HELPER Update packet. The HELPERs deployed in the field use this unicast HELPER Update packet during ND phase to reply to the ND packet with their information (Node ID, location etc.). The operator can perform this remote monitoring intermittently to ensure all the HELPERs in the network are active. If some of the HELPERs do not show up during these intermittent monitoring phases, the operator will be aware of the lack of connectivity in those areas and can deploy more nodes or take other corrective actions to keep the network fully connected.

Critical Alert Message: Similar to the Wireless Emergency Alerts (WEA) that is used over the cellular network, the ALERT message is intended to inform every connected user about an imminent threat like high winds, rising water level, flash flood, fires etc. This message will also be distributed using an efficient flooding technique. Every user connected to a HELPER sees a message labeled from ERC and hence are aware of the steps to take to remain safe during the upcoming situation. This will be highly beneficial in situations where cellular network is not operable due to damage and a large number of individuals need to be informed about imminent dangers.

5 Evaluation

In this section, we discuss the HELPER prototype that was developed to establish proof of concept and conduct some initial development.

5.1 Operational Proof-of-Concept

In this section, we have focused on developing the prototype for MH as shown in Fig. 11. We decided to prototype the MH because of its portability, cost and because it can be used to demonstrate the envisioned operation of the entire HELPER network. This concept can be easily extended when more SH and/or AH are added to the HELPER network. The proof-of-concept demonstrations conducted by us were recorded using mobile screen recorders and compiled in the form of a video [54]. In this section, we use parts of the video to discuss the experiments and functionalities it intended to display. Accordingly, we have developed six HELPERs (see Fig. 11), five of which are deployed with given location value as shown in Fig. 12 (white markers) for EU to connect using their mobile devices. The sixth one is connected to a PC and acts as the ERC which is indicated as a building in Fig. 12. We had four EUs connected to the network through three of the deployed HELPERs. As you can see two users (Jithin and Nick) are connected to the same HELPER. The Web App with the chatbox corresponding to each connected users are displayed at the edges of Fig. 12.

First, we tested the operation of the local messaging using the HELPER where two users were connected. Several text messages were exchanged between Nick and Jithin, as you can see in Fig. 14 connected to the same HELPER. As mentioned earlier, these messages are exchanged over WiFi and do not need to use LoRa. Since these are local messages, the other two users (Andrew and Anu) connected to their respective HELPERs will not receive these messages. Next, Jithin switches his chat option from local to neighbor which implies all users connected to HELPERs within $h$ hop will receive his messages. In this deployment $h=1$, which implies one-hop neighbors will receive chat messages. Accordingly, the text message sent by Jithin is received by the other three users even if they are not connected to the same HELPER as Jithin. This part of the demonstration proves how HELPER can be used to keep community members connected by exchanging text messages with each other. The EU is completely abstracted from the ad hoc networking operation that happens in the background. To the EU, they are just sending messages to two different groups, one local group, and other more extended community groups.

As mentioned before, ERC has the ability to flood the HELPER network with ALERT messages to inform connected EU of imminent dangers. In this case, the ERC sends an ALERT message regarding the high winds. In Fig. 16, it can be seen that three users connected to different HELPERs have received the “HIGH WIND” alert message transmitted by ERC. The packet was dropped for one user since we do not have a transport layer currently implemented that ensures end-to-end reliability. During this period of demonstration, multiple users have shared the availability of resources like a gas station, water, and food etc. These packets are first sent directly to ERC and upon approval, the information is flooded in the network. Accordingly, the connected users are able to see the location of the resource on their local map in their Web App as shown in Fig. 16.

The final part of the demonstration was to evaluate how distress messages can be sent directly to the ERC. In this case, Jithin realized Nick needs medical attention and uses the “help” option to send a message. This message is sent directly to ERC and nearby HELPERS simultaneously just in case there is ER or others in the vicinity who can provide assistance as compared to the ERC itself. Accordingly, the connected users see the HELPER which Jithin is connected to turn red indicating distress at that location. This will enable community members to reach out to the nearest ER and provide the required assistance. This location information is also available at the ERC which instantly dispatch help to the given location. Overall, this service acts as the replacement for 9-1-1 calls when traditional infrastructures like cell towers or the internet are unavailable. We hope this technology will enable low cost, efficient public safety system. We also provide the demonstration [55] from the point of view of an ERC.

5.2 Testbed Evaluation

In the previous section, we have established the feasibility of the proposed HELPER network. Here, we try to perform an extensive evaluation of the underlying SEEK algorithm and analyze various aspects of its operation in a unicast setting. To accomplish this, we set up the six HELPER prototypes in a grid topology as shown in Fig. 17. We compare the proposed algorithm against the shortest path routing algorithm. We implement this shortest path routing using a greedy geographical forwarding technique. In this algorithm, nodes that have a packet to forward elects the node closest to the destination as the next hop. This can also be seen as a greedy distributed version of MPR used in [29] discussed earlier in Section 2 with the assumption that paths with the smallest number of hops may indeed be the path with minimum energy consumption. Both protocols have similar complexity. In other words, all the possible next hops are considered by both. Greedy algorithm calculates the forward progress of each next-hop and SEEK calculates the utility function for each next-hop. Both then chooses the neighbor providing highest value. In terms of complexity for a given number of transmission strategies, the complexity of both the algorithms are $O(\mathbb{|NB|})$.

The parameters used in the evaluation are depicted in Table 4. As discussed earlier, LoRa consumes extremely low power. This means that for a realistic battery to drain completely, we may have to run the evaluation over multiple days. To save time and yet without loss of rigor, we use a virtual energy level to evaluate the HELPER network so that we can see the network behavior in experiments lasting less than 120 min. Each node is assumed to start at a total energy of $25\;\mathrm{J}$ and is depleted as each packet (control or data) is transmitted.

In the first experiment, $F$ is set as the destination (would represent ERC in a real-life scenario) and HELPER $A$ and $B$ are the source nodes. As shown in Table 4, packets are generated at the source node at a constant rate and it has to choose appropriate routes to reach the destination. The first metric we evaluate is the minimum residual energy ($E_{r}^{min}$) among all HELPERs in the network. In other words, at any given time instant $t$, we plot the residual energy value of the HELPER that has consumed the highest energy. The second metric under evaluation is the normalized throughput of the network calculated with respect to observed point-to-point link throughput ($Th_{l}$) and can be referred to as,

[TABLE]

First, let’s look at the initial $14$ minutes of the experiments. As you can see in Fig. 19, the $E_{r}^{min}$ in both cases are the same since SEEK operates similarly to the greedy algorithm in this stage even after gathering information from immediate neighbors. This is because at the beginning most of the possible next hops have similar parameters including backlog length and residual energy. Additionally, it can be seen from Fig. 19 that during the same period, the greedy algorithm seems to marginally outperform SEEK. This can be attributed to the overhead involved in SEEK to compute the optimal next hop from the gathered information. This marginal superiority is short-lived as SEEK starts learning about the environment and begins to exploit spatial diversity to choose multiple paths to the destination. This provides HELPER network with two advantages, (i) the energy consumption is evenly spread between nodes and (ii) higher throughput is achieved. Accordingly, from Fig. 19, it is evident that the death of the first node in the aggressive greedy algorithm happens much earlier than the death of the first node in SEEK. This provides a proof-of-concept that SEEK can be applied to maximize the network lifetime in a distributed manner.

Next, to extend the experiments further, we evaluate the performance of SEEK while increasing the number of sessions in the network to $4$. This is to evaluate if SEEK can adapt to multiple traffic partners in the network which is expected behavior in a large distributed network. These sessions include $A\rightarrow F$, $B\rightarrow C$, $C\rightarrow E$ and $F\rightarrow A$ and are chosen to ensure no source in a session has it’s destination via direct link (i.e. destination is not the source’s immediate neighbor). Each source in the session is set up to generate packets at a constant rate as mentioned in Table 4. Both residual energy of each node and packets received are constantly monitored. We first analyze the network lifetime which is defined as the duration of operation until the first node in the network dies. This is important for such emergency networks as the death of a node would imply unconnected users. Figure 21 shows how SEEK outperforms the greedy algorithm regardless of the number of sessions. The experiments show an improvement of up to $53\%$ in terms of network lifetime. One interesting finding is that the network lifetime seemed to increase with the increase in sessions which might be counter-intuitive at first sight. Further evaluation using Fig. 21 will reveal that the small network is saturated even with two sessions in the network as portrayed by the throughput decline. This implies that more collision may occur at the MAC layer leading to a larger backoff and lower throughput as the number of sessions increase. In a saturated network, the overall throughput even while operating for a longer period of time is better for SEEK compared to the greedy algorithm. To further substantiate the importance of network lifetime, we plot the percentage increase in packets delivered by SEEK as compared to the greedy algorithm in Fig 23. This keeps increasing as the number of sessions in the network grows which can be related to delivering critical information from survivors to the ERC during the aftermath of the disaster.

Finally, we look at the average delay per packets as the number of sessions in the network increases. To accomplish this, we set each session to transmit 100 packets while keeping the rest of the setting similar to the earlier experiment. As expected, the delay per packet of both the schemes increases as the number of sessions in the network increases due to congestion. The more critical observation from Fig. 23 is that the delay incurred by packets serviced using SEEK is up to $40\%$ less than greedy algorithm especially when the traffic increases (3 sessions). This is because SEEK is able to use multiple paths to distribute traffic spatially among nodes to reduce congestion at the bottleneck nodes. This is further substantiated by the fact that the advantage in terms of lower delay diminishes as the network saturates (4 sessions) since all the nodes are involved in either case (greedy and SEEK) leaving no extra nodes for SEEK to distribute traffic load.

Overall, the experiments showed how nodes in SEEK share information among each other using the control packets which is then used to perform cross-layer optimization to choose optimal routes that ensure all nodes share the load of the traffic to maximize the network lifetime. We expect the improvement in the performance to be significantly higher on a larger network consisting of hundreds of nodes. Here, we have prototyped HELPER and set up a small yet effective testbed with a limited number of nodes to perform extensive testing. The results provide proof-of-concept that the proposed HELPER network can be deployed in near future to enable off-the-grid connectivity.

6 Conclusion

In this work, we have proposed, prototyped and established the proof-of-concept of a complete end-to-end solution to enhance and enable public safety communication systems. The proposed HELPER uses heterogeneous wireless communication techniques; (i) WiFi which enables EU to connect to the HELPER like any WiFi access point thereby ensuring easy and widespread adoption, and (ii) LoRa, that provides extremely low power, long range wireless link to implement the ad hoc operation. The HELPER network is used to set a completely self-sustained network that does not require the support of any traditional communication infrastructure like cell towers or satellite. The HELPER network is designed to serve a dual purpose; (i) enable affected individuals to stay connected and maintain situational awareness, and (ii) equip authorities to remotely monitor the situation, provide assistance and warnings in an efficient manner.

The proposed solution provides connected EU with live map updates to share the location of known resources. It enables text messages between community members and equips EU with an alternative to traditional 9-1-1 like emergency calls. Similarly, it provides ERC with the capability to monitor the network connectivity, manage resource sharing information and send out ALERT messages to connected users. Additionally, numerical evaluations using HELPER testbed showed up to $53\%$ improvement in network lifetime and up to $28\%$ improvement in network throughput as compared to a greedy scheme that routes using shortest path. All these demonstrated capabilities will enhance the state-of-the-art public safety response system.