Adaptive Emergency Call Service for Disaster Management

Abstract

Reliable and efficient transmission of emergency calls during a massive network failure is both an indispensable and challenging task. In this paper, we propose a novel fully 3GPP and 5G compatible emergency call protocol named 5G StandalOne Service (5G-SOS). A 5G-SOS-enabled emergency service provides potential out-of-coverage victims’ devices with a way to contact the 4G/5G core network through D2D multi-hop relaying protocol. The objective of 5G-SOS is to maintain this connection even when a large fraction of the network infrastructure is destroyed. 5G-SOS is a fully distributed protocol designed to generate zero additional control traffic and to adapt its parameters based on the local emergency call congestion. Therefore, devices behave as an ad-hoc network with the common purpose to ensure the best chances for emergency call transfer within a reasonable delay. A densely populated Traverse city of Michigan, USA, with a 15,000 population, is used to evaluate 5G-SOS under extreme emergency scenarios. The performance of 5G-SOS is shown to be significant when compared with existing protocols, namely, M-HELP and FINDER, in terms of transmission success rate, end-to-end latency, network traffic control, and energy management. 5G-SOS provides satisfactory performance (success rate of 50%) even when the number of simultaneous emergency calls is very high (5000 calls over 10 min). On average, 5G-SOS performs 24.9% better than M-HELP and 73.9% than FINDER in terms of success rate. Additionally, 5G-SOS reduces the average end-end latency of the emergency calls transfer by 20.8% compared to M-HELP and 61.7% compared to FINDER.

1. Introduction

A self-adaptive, efficient, and easy-to-access emergency call service is paramount during a large disaster. During a disaster, impacted people face the risk of not being rescued on time when the number of victims increase and the network infrastructure itself is impacted. Although it is difficult to prevent natural disasters and pandemics such as Tsunami in 2004 and COVID-19, a proper disaster management scheme allows us to mitigate their effects and improve the impact assessment and response phases in the disaster management cycle [1,2,3], as depicted in Figure 1. In this context, cellular networks play a key role in providing the easiest and fastest ways to receive emergency data and provide safety services.

Many applications and protocols [4,5] are proposed for public safety services based on cellular network technologies [6]. Since Release 11, the third-generation partnership project (3GPP) developed the specifications of new protocols and services for supporting public safety services. The evolution of such specifications with their respective 3GPP release are illustrated in Figure 2. In general, public safety services use a narrow band terrestrial trunked radio (TETRA)-based system that can only support voice services [7] and concern-specific devices. In addition, the emergency data about the victims provides crucial information for rescuing actions in the impact assessment phase. Hence, it is important to maintain connectivity among user devices, i.e., potential victims, in such a manner that all the emergency messages get collected reliably.

Furthermore, 4G/5G device-to-device (D2D) technology allows the connectivity among user devices enabling the extension of the radio coverage of gNodeBs (gNBs) during disaster scenarios. Despite the works on D2D during disaster scenarios, the real implementation of such solutions faces two major challenges. The first challenge is the cohabitation of D2D communications and the traditional uplink/downlink communications [8]. Emergency call service should be light enough and should not interrupt the normal functioning of the user phones. Secondly, the proposed emergency call protocol should manage traffic fluctuation and radio resource access in a fully distributed way, when the network infrastructure may be damaged.

Thus, a fully distributed, feasible, and adaptive emergency service is required when network infrastructure failures occur during large disaster scenarios. Hence, in this paper, an adaptive call protocol is proposed for emergency scenarios. On the whole, the main contributions of this work are summarized as follows:

• A novel 3GPP and 5G New Radio (5G-NR) compatible emergency call protocol named 5G StandalOne Service (5G-SOS) is proposed. This protocol is designed to forward emergency calls autonomously and reliably to the network infrastructure during massive network failures using multi-hop D2D relaying across the sidelink channel. This protocol generates zero additional control traffic, is fully distributed, and is adaptive to local emergency call congestion.
• The proposed 5G-SOS protocol is designed to utilize distributed learning and adapt its parameters according to the observed neighborhood emergency call congestion data. Further, it is modeled to use the prior knowledge of local network congestion limits to assign values to the protocol parameters such that the transmission reliability and efficiency are enhanced.
• Feasible algorithms are proposed for the user devices to follow the 5G-SOS protocol and function as either an emergency or a relay device at a given instance.
• The performance of the proposed adaptive protocol is shown to be significant when compared with competitive existing protocols such as M-HELP [9] and FINDER [10] in terms of transmission success rate, network traffic control, and energy management under extreme emergency scenarios.

The remainder of this paper is organized as follows, Section 2 provides an overview of other related works, while Section 3 and Section 4 explain the system model and proposed design of the multi-hop emergency calls service protocol, respectively. Section 5 provides the performance analysis and comparison with existing protocols and Section 6 concludes the paper.

2. Related Works

The following review of the literature confirms that specific initiatives are required for emergency disaster management. Multiple performance metrics, e.g., end–end latency, availability, deployability, energy consumption, stability, and security, determine the success of such solutions.

2.1. 3GPP Works on Public Safety

Two main approaches in Mission Critical services were introduced by the 3GPP group concerning proximity-based services in 4G/5G mobile networks; extending the gNBs coverage by using the D2D [11,12] and supporting the group calling communication, also referred as push to talk (PTT) service [4,13]. PTT is described in TS 22.179 of the 3GPP standard [14,15]. Although the PTT and D2D mechanisms present a way to extend the network coverage and services; these technologies are conceived for well-deployed local mobile networks. An extended networking protocol using such mechanisms is required for implementing an emergency call service under extreme situations, i.e., a high number of emergency calls, the partial failure of the network, and a large affected geographical area, to reliably forward calls to the core network.

2.2. Wireless Network Recovery

Multiple works of the literature [5,16,17] address the resilience and self-adaptation of the mobile networks to face a disaster affecting the network infrastructure using various mechanisms. In

Table 1. Existing works in the literature on wireless network recovery.

Related Work	External Architecture	Resilient Architecture	Resilient Application	Resilient Protocol	3GPP Compatible	Out-of-Coverage
UAV-Assisted Attack Prevention, Detection, and Recovery of 5G Networks [19]	x					x
Post-Disaster 4G/5G Network Rehabilitation Using Drones: Solving Battery and Backhaul Issues [20]	x					x
Integration of satellite and LTE for disaster recovery [18]	x					x
UAV-Empowered Disaster-Resilient Edge Architecture for Delay-Sensitive Communication [21]	x					x
On the Disaster Resiliency within the Context of 5G Networks: The RECODIS Experience [16]		x			x
Enabling Disaster Resilient 4G Mobile Communication Networks [23]		x			x
Terrestrial Trunked Radio-Tetra: A Global Security Tool [24]			x		x
Towards Failure Resiliency in 5G: Service Shifting [25]			x		x
Ad-hoc network recovery after severe disaster [26]				x		x
A mobile ad-hoc network multi-path routing protocol based on biological attractor selection for disaster recovery communication [27]				x		x
D2D Multihop Energy-Efficient Routing and OFDMA Resource Allocation in 5G Networks [28]				x	x
Assisted Routing Algorithm for D2D Communication in 5G Wireless Networks [29]				x	x
FINDER: A D2D based critical communications framework for disaster management in 5G [10]				x	x	x
M-HELP-Multi-Hop Emergency Call Protocol in 5G [9]				x	x	x

, the research works on recovery solutions for wireless networks are presented. The extended architecture-based approaches complicate the 3GPP compatibility in communications and add extra infrastructure costs. In this case, external or movable physical units, such as satellite [18] or unmanned air vehicles (UAV) [19,20,21,22], are deployed to rapidly work as a stand-in for damaged network facilities.

Moreover, resilient architecture-based approaches are less disruptive to the 3GPP specifications. In [23], the authors proposed to relax the dependencies between UEs, gNBs, and the core network. The objective is to provide more resilience against link disruptions by using the virtualization/redundancy of the links and functionalities. Although this approach is efficient for localized perturbations, it remains inefficient when the disaster impact is over a large geographical area. The application-based approaches try to manage the reliability and robustness issues on the service layer [24,25]. The application has to detect the communication failure and has to adapt the transfer mode accordingly (use of other wireless technology, other coding schemes, data substitution, etc.).

The resilient protocol-based approach is widely discussed for ad-hoc networks [26,27]. However, those protocols are incompatible with 5G network specifications. Some resilient-based protocols compatible with the 3GPP standard are proposed such as [28,29]. Nevertheless, most of these protocols can not be used in an out-of-coverage situation when the disaster affects the network infrastructure.

Even if dealing with disaster situations is well studied in ad-hoc network literature [30,31,32], the projection of those solutions over 4G/5G cellular standards is rarely studied and remains difficult. Furthermore, the user equipment (network nodes) is not owned by the system itself, making the protocol possibilities more regulated and constrained than in private/community networks such as MANET and VANET systems [33,34].

Meanwhile, the FINDER protocol in [10] represents one of the rare works on the massive use of D2D mechanisms to overcome large disaster situations. In FINDER, emergency calls are forwarded to working gNBs by clustering and organizing the out-of-coverage mobile devices. There is a cluster head (CH) in each cluster that is selected by the members of the cluster. The CH receives emergency calls transmitted by mobile nodes within its cluster. The CH aggregate and transmit them across the neighboring CHs to the nearest active gNB via multi-hop D2D communications. The procedure suffers from the complexity of cluster computing and the lack of resilience against cluster head failure. On the other side, the use of personal UEs to serve as cluster heads is not practical.

On top of that, M-HELP [9] is another resilient protocol designed to address large disaster scenarios using D2D. M-HELP adds zero additional control messages to the network. Further, it has been shown that M-HELP has a better performance in terms of successful transmission reliability, network congestion, and residual energy compared to FINDER. However, the robustness of M-HELP remains a challenge under scenarios with varying emergency call loads, scale of disaster, D2D transfer delays, and UE densities. Hence, a novel protocol is proposed to improve the robustness of emergency call protocols under extreme emergency scenarios using observed neighborhood network data.

3. System Model

An overview of the system model considered to design and implement an emergency call protocol named 5G-SOS is presented in this section. In this work, it is assumed that all UEs ∈ M are 4G/5G emergency service enabled. In such a network area, each UE can behave both as an emergency call initiator and as a relay. Since a disaster scenario is evaluated, it is assumed that the UEs are stationary and their location is fixed at the initial period just after the disaster.

Furthermore, two modes of emergency call transmission, D2D and classical, are utilized to forward emergency calls to the network infrastructure, as illustrated in Figure 3. In this example, three UEs (orange, blue, and red) are in an emergency and are out of coverage due to the failure of the covering gNB. The orange UE sends a broadcast D2D message that is only received by one UE and then relayed in the classic mode to the operational gNB at the top of the Figure. The emergency call of the blue UE is sent in D2D mode and is received by three UEs. The two relay devices in black transfer the emergency call to both working stations, while the red UE ignores the blue UE’s emergency call because its RSSI is worse than the blue UE. The red UE diffuses its emergency call to the blue UE, which relays it to all neighboring UEs until the emergency call reaches the working station at the bottom of the figure. The transmission redundancy allows improving the reliability of the protocol. However, the number of copies of the same message has to be controlled to prevent radio network saturation.

3.1. Informational Model

Each device $m\in M$ is characterized by the following data:

• Current battery level (residual energy), ${\mathrm{SoC}}_m\in [0,100]$;
• Coverage status by at least one gNB, ${\mathrm{Ic}}_m\in \{0,1\}$:
  The coverage status indicates if the UE has at least one direct communication link with a station $n\in N$, allowing it to communicate directly with the core network. When a UE is out of coverage, it no longer has a direct connection link with the gNBs.
• GPS localization accuracy, ${\mathrm{LocAcc}}_m\in [0.001,1]$:
  Location information is obtained using a global positioning system (GPS). It is assumed that the error in such a GPS measurement is represented by the distance between the actual position and the estimated position of m, ${\delta }_m\in [0..\infty ]$ measured in meters. Hence, ${\mathrm{LocAcc}}_m$ is modeled as (1),

  $${\mathrm{LocAcc}}_m=\frac{1}{{\delta }_m+1}{m}^{-1}.$$

  (1)
• Received signal strength indicator (RSSI) power that is detected, ${\mathrm{RSSI}}_m$:
  The broadcast physical layer synchronization signals (PBCH) periodically transmitted by the operational gNBs enable the UEs to establish quality indicators, including RSSI, reference signal received power (RSRP), reference signal received quality (RSRQ), signal to interference plus noise ratio (SINR) and channel quality indicator (CQI) up to 75 km from the gNB [35,36]. These measured indicators are useful in the selection of the best paths toward the nearest operational gNB.
  The RSSI indicator  [37] is measured by each UE to estimate the strongest signal received from the surrounding operational stations $g\in N$ as shown in (2). The RSSI value depends on device location and more specifically on the signal path loss [37] between the gNBs and the device. Signals’ path loss, namely $P_l(d,f)$, is varied due to the propagation parameters such as the distance between gNB and receiver UEs, height and location of UEs, transmission frequencies, terrain contours, environment.

  $$\mathrm{RSSI}=\underset{n\in N}{max}\left(\mathbb{E}\left(\sum _{rb\in RB}^{}{P}_t\left(n\right)-P_l(d,f)\right)\right),$$

  (2)

  where $P_t\left(n\right)$ is the power of the transmitted signal by a given station n. $RB$ represents the set of radio resource blocks used to transmit the physical broadcast channel (PBCH) signals. $RB$ corresponds to the set of OFDM symbols and sub-carriers on which the PBCH is transmitted. For each operational station, the user equipment (UE) computes the average received signal power [38] over all the symbols and sub-carriers, f of $RB$. Finally, the UE only considers the highest computed average.

3.2. Emergency Call Procedure

The emergency call procedure can be triggered either by human intervention or automatically (e.g., after a car accident detection). Once the call is triggered, the emergency application starts incorporating the data related to the victim, i.e., voice, text, video message, the UE id emergency call id, indicators about the emergency degree (level), RSSI indicator, and device position. If the emergency caller is within the coverage of a network gNB, then the call is directly sent to the gNB using the classical communication mode. However, if the caller is out of coverage, the call is locally diffused using the out of coverage D2D procedure.

Once a relay receives an emergency call and decides to relay it, the relay adds its identifier, position, and RSSI value to the relayed message. Then the relayed message is sent using either the traditional mode if the relay is covered by a gNB or by D2D communication if the device is out of coverage. The emergency source position and relay’s positions help the public safety center precisely localize the source of the emergency call. Further, once an emergency call is received by a given gNB, a notification is diffused to all the UEs under coverage, indicating the successful transmission of that emergency call with its specific ID. That way, redundant uplink transmissions of the same emergency call are reduced.

3.3. Outband D2D Communication

When the sender is out of coverage, the emergency call source or relay sends a control message via the physical sidelink control channel (PSCCH). The PSCCH serves, implicitly, to synchronize the sender with the potential receivers. It is used by ProSe-enabled UEs to send the sidelink control information (SCI) that informs the receivers about the data transmission parameters used during the next sidelink period: subframes and radio resource blocks [39]. More precisely, the PSCCH indicates the index of the used subframes (time), the used radio resource blocks (frequencies), the modulation and coding scheme, and the D2D group destination ID. Each UE listens continuously to the PSCCH channel to detect if another UE is transmitting in the current sidelink period. Once the PSCCH message is received, the relay node tunes to the corresponding resources in the physical sidelink shared channel (PSSCH) to receive the emergency data.

In summary, an outband D2D multi-hop model based on 4G/5G sidelink communication is considered for emergency call forwarding. This model, called the 5G-SOS protocol, is described in the following section.

4. Adaptive Multi-Hop Emergency Call Protocol: 5G-SOS

The 5G-SOS protocol aims to maximize the probability that the emergency call reaches at least one gNB with a minimum delay and with a reasonable number of exchanged messages. The 5G-SOS procedures and adaptive parameters used by an emergency device and relay device are presented in Algorithms 1–3. The notations used in the Algorithms are presented in

Table 2. Notations used in Algorithms 1–3.

Notation	Description
$\eta$	FIFO list of calls in the buffer to be relayed
$\chi$	List of calls already received and processed in the past
DATA	Emergency call
srcID	Identifier of the source device
callID	Identifier of the emergency call
callIDGenerator	Function used by each UE to generate unique call IDs
waitingCall	A call stored in $\eta$
deadline	latest time by which a waitingCall is transmitted
nbAttempts	Count that DATA was trasnmitted or relayed
relay	relay device information content in DATA

.

As detailed in Algorithm 1, when an emergency UE, E, generates an emergency call, DATA, the application layer constructs a data message, including the emergency data (rescue video, voice, or text), GPS localization, observed RSSI and a couple of value $DATA.srcID$ and $DATA.callID$. DATA.srcID corresponds to the identifier of the source of the emergency call, E. $Data.callID$ is the internal identifier given by E to the emergency call using the function callIDGenerator. $callIDGenerator$ means that whatever the two different emergency calls initiated by E are, they have different $callID$.

If the emergency phone, E, is under the coverage of a given gNB, then the emergency call is sent using the traditional 4G/5G uplink communication (PRACH and PUSCH channels). Otherwise, a D2D communication procedure is opted. First, a PSCCH message is sent announcing that emergency data will be sent during the next sidelink radio frame period. The parameters included in PSCCH inform the receivers about the subframes (TRP) and frequencies (RIV) used to transmit the emergency data over the PSSCH channel. The destination group ID of the PSSCH is set to “ANY” since it concerns all neighboring UEs.

Next, the emergency phone E counts the number of times its own call is relayed by the neighbors (see lines 10–17 of Algorithm 1). To do so, each DATA is identified by the exclusive couple of values $(\mathit{DATA}.\mathit{srcID},\mathit{DATA}.\mathit{callID})$. If the received message by the R is its own message (the same couple $(\mathit{srcID},\mathit{callID})$), then the number of relay neighbors, $N_{RS}$, is incremented. If, after a period of $T_0,N_{RS}\le R{S}_{\mathrm{threshold}}$, the DATA is resent until the maximum number of re-transmissions, $n_0$, is reached. Every attempt is considered a new emergency call by changing the DATA.callID identifier of the message.

Algorithm 1 On emergency call generation

1: Input data: my srcID, emergency data, GPS localization, RSSI, $T_0$, $R{S}_{\mathrm{threshold}}$, $I_{\mathrm{TRP}}$, RIV, MCS, $n_0$ 2: DATA.content ∈ {emergency data, localization, RSSI} Generation 3: DATA.srcID = my srcID, DATA.callID = callIDGenerator() 4: if I am out of coverage then 5:     nbAttempts=0 6:     repeat 7:         send PSCCH with $I_{\mathrm{TRP}}$, RIV, MCS 8:         send DATA by PSSCH channel 9:         start = now() 10:         while $\mathrm{now}\left(\right)-\mathrm{start}<T_0$ do 11:            if I receive PSSCH then 12:                mess = received DATA 13:                if mess.srcID == my srcID then 14:                    $N_{RS}++$ 15:                end if 16:            end if 17:         end while 18:         if $N_{RS}\ge R{S}_{\mathrm{th}}$ then 19:            EXIT 20:         end if 21:         nbAttempts++ 22:         DATA.callID = callIDGenerator() 23:     until nbAttempts $>n_0$ 24: else 25:     send DATA using ordinary link (RACH + PUSCH) 26: end if

Algorithm 2 On receiving an emergency call, DATA

1: if (!$\chi$.contains(DATA.srcID, DATA.callID)) then 2:     $\chi$.Push(DATA) 3:     if $\eta$.size() $<3$ then 4:         Compute $T_r$ 5:         DATA.deadline = $T_r$ + now () 6:         DATA.$N_{RS}=0$ 7:         $\eta$.Push(DATA) 8:     end if 9: else if∃ waitingCall $\in \eta$ such as (DATA.srcID, DATA.callID) = (waitingCall.srcID, waitingCall.callID) then 10:     waitingCall.$N_{RS}++$ 11:     if waitingCall.$N_{RS}\ge R{S}_{\mathrm{th}}$ then 12:         $\eta$.Remove(waitingCall) 13:     end if 14: end if

Algorithm 3 Every one second

1: Input data: my srcID, GPS localization, RSSI 2: for all waitingCall $\in \eta$ do 3:     if now () ≥ waitingCall.deadline and my State is “idle” then 4:         my State =“busy” 5:         if I am out of coverage then 6:            DATA.content = waitingCall.DATA.content 7:            DATA.relay.add (GPS Localization, RSSI, my srcID) 8:            DATA.srcID = waitingCall.DATA.srcID 9:            send PSCCH with $I_{\mathrm{TRP}}$, RIV, MCS 10:            send DATA on PSSCH channel 11:         else 12:            send DATA using ordinary link (RACH + PUSCH) 13:         end if 14:         $\eta$.Remove(waitingCall) 15:         myState = idle 16:     end if 17: end for

As described in Algorithm 2, once an emergency call is received, the relay device, r, studies the opportunity of forwarding it. First, r checks if the $(\mathit{DATA}.\mathit{srcID},\mathit{DATA}.\mathit{callID})$ of the received DATA is in the already received calls list, $\chi$. If it is a new emergency call, r stores the received message $DATA$ in the list of considered calls, $\eta$. $\eta$ allows managing up to three emergency calls simultaneously. Each emergency call in $\eta$ is associated with two new fields: $N_{RS}$ and $deadline$. $N_{RS}$ is initialized to 0 and stores the number of times that the message DATA is relayed by other neighbors. $deadline$ gives the limit date of the call in $\eta$. $deadline$ is computed using the maximum waiting duration, $T_r$, as shown in line 5 of Algorithm 2. If the received message is already received (line 9 of Algorithm 2), r checks if the message belongs to the being considered messages $\eta$. If so, the number of times the waiting call is relayed $waitingCall.N_{RS}$ is incremented and the call is removed from $\eta$ if this number reaches the relay threshold $R{S}_{th}$.

Every second, the relay phone r checks its $\eta$ list as explained in Algorithm 3. If the waitingCall.deadline of a being-considered call, $waitingCall$, is reached, then the call is relayed after including, in the $DATA.relay$ field, the relay’s data, such as the RSSI, GPS location, and srcID and in $DATA.content$ the content of the received call $waitingCall$. According to whether r is in-coverage or not, the DATA is transmitted using the classic or D2D mode. Moreover, only one emergency call is transmitted at a time and each device is associated with a state variable (my State) initialized to “idle”. When the device starts to transmit an emergency call, the state is turned to “busy”. During the busy state, the device continues to receive and queue emergency call requests.

4.1. 5G-SOS Adaptive Parameters

The behavior of existing protocols such as M-HELP [9] depends on constant parameters mainly used by the UEs to decide either to relay or not, the received emergency calls. In contrast, 5G-SOS parameters are designed in the proceeding sections, which can vary adaptively according to the observed network measurements.

4.1.1. Waiting Time for Relaying, $T_r$

The role of the waiting time $T_r$ is to define an order between the relay devices in a fully distributed way. A short $T_r$ means that the relay device is suitable for relaying the emergency call. When the $T_r$ is long, the device relays the call only if necessary, i.e., the neighbor relaying is not sufficient. In other words, UEs with a low $SoC$, out of coverage, low RSSI signal, or with poor localization accuracy wait longer before deciding to relay the received emergency call. Therefore, longer $T_r$ allows the UE to wait for the decisions of more suitable devices. To prevent a very long waiting time, a maximum waiting time $T_{\max }$ is introduced. In M-HELP [9], the waiting time is computed as (3):

$$\begin{array}{cc}\hfill T_r^{M-HELP}& =\min \left(T_{\max },\frac{1}{{\mathrm{LocAcc}}_r+\delta }\times \frac{1}{{\mathrm{Ic}}_r+\delta }\times \frac{{\mathrm{SoC}}_{\max }}{\min ({\mathrm{SoC}}_r,{\mathrm{SoC}}_{\max })}\right),\hfill \end{array}$$

(3)

where the coverage state, localization accuracy, and residual energy of r is given, respectively, by ${\mathrm{Ic}}_r$, ${\mathrm{LocAcc}}_r$ and $So{C}_r$. In the M-HELP protocol, $T_{\max }$ was fixed to a specific value. However, it is clear that the value of $T_{\max }$ should be adapted according to many factors such as the observed emergency call rate and the UE density. That is why the computation of the $T_r$ value is adjusted as follows:

$$\begin{array}{cc}\hfill {T_r}^{5G-SOS}& =\min (T_{\max }(n_k,n_c),\hfill \\ \hfill & \frac{{\mathrm{RSSI}}_{\mathrm{tx}}}{{\mathrm{RSSI}}_{\mathrm{r}}}\times \frac{1}{{\mathrm{LocAcc}}_r+\delta }\times \frac{1}{{\mathrm{Ic}}_r+\delta }\times \frac{{\mathrm{SoC}}_{\max }}{\min ({\mathrm{SoC}}_r,{\mathrm{SoC}}_{\max })}).\hfill \end{array}$$

(4)

The parameter $T_{\max }$ is now expressed by a modified Rosenbrock [40,41] function. Moreover, Rosenbrock function is used often as a test problem for optimization algorithms. Further, Rosenbrock function is used in this work seeing that it has a slope with the same behavior to $T_{\max }(n_c,n_k)$ given in

Table 3. Expected behavior of $T_{\max }$ with $n_c$ and $n_k$.

${\mathit{n}}_{\mathit{k}}$	${\mathit{n}}_{\mathit{c}}$	${\mathit{T}}_{\mathbf{max}}$
↓	↓	↓
↓	↑	↑
↑	↑	↓

). The Rosenbrock function given in (5) is modeled to increase the sensitivity of protocol to the real-time local factors such as the amount of emergency requests and neighborhood congestion detected in the previous minute.

$$\begin{array}{cc}\hfill T_{\max }(n_c,n_k) & =\min (\max ({(a-n_c)}^2+b\times {(n_k-{n_c}^2)}^2,0),u_b),\hfill \end{array}$$

(5)

where $n_c$ represents the total number of received emergency requests, including multiple receptions during the last minute. $n_c$ is used to measure the level of congestion in the neighboring environment in the past minute. Further, $n_k$ measures the total number of different emergency call requests received in the previous minute. In addition, a and b are two parameters that govern the shape of the Rosenbrock $T_{\max }$ function in (5).

A low number of distinct emergency calls $n_k$ with a high congestion level $n_c$ expresses a low emergency load but with many relaying opportunities for each emergency request due to the network density. In this case, a high $T_{\max }$ value allows to better select the relevant relays. However, if both $n_k$ and $n_c$ are low, the $T_{\max }$ value is decreased since there are not enough relay alternatives, i.e., a weakly dense network. Finally, when $n_k$ is high, a lower $T_{\max }$ is preferable in order to quickly handle the newly received emergency requests. Further, if the number of neighboring relaying devices is less and such devices have a low battery level, they will be assigned a relatively shorter $T_{\max }(n_c,n_k)$ by 5G-SOS based on the low neighborhood congestion.

The expected adaptive behavior of $T_{\max }$ according to $n_c$ and $n_k$ is summarized in Table 3. The curve of the original Rosenbrock function, f, is given in Figure 4. When x increases while y is fixed, $f(x,y)$ increases. However, when y is increased, while keeping x fixed, $f(x,y)$ decreases gradually.

To compute the waiting time $T_r$, r uses its coverage state ${\mathrm{Ic}}_r$, its localization accuracy ${\mathrm{LocAcc}}_r$, and its residual energy $So{C}_r$. However, (3) and (4) show that the protocol 5G-SOS introduces the use of RSSI in the computation of the waiting time parameter. The ratio between the $RSS{I}_{\mathrm{tx}}$ of the transmitter device that sent the call request, and the $RSS{I}_r$ of the r itself is computed. This ratio is higher than 1 when the transmitter of the emergency call is in better radio conditions than the receiver (farther from the gNBs). In this case, the ratio contributes to increasing the value of $T_r^{AM-HLP}$ in order to penalize the receiver in its selection for relaying the emergency call. Otherwise, when the ratio is less than 1, the receiver is in better radio conditions (closer to the gNB), and the waiting time is decreased to give priority to the receiver.

The RSSI ratio is used to improve the latency fairness between UEs. Indeed, a relay device waits less time when the request is sent by a farther device than when the request is sent by a closer device, as depicted in Figure 5. Therefore, when two requests are received at the same time, the request of the farthest device from the gNB is transmitted first, which contributes to balancing the emergency call transfer delays.

4.1.2. Relaying Threshold, $R{S}_{\mathrm{th}}$

The parameter $R{S}_{\mathrm{th}}$ is a critical parameter that determines the balance between the reliability of the communication and the fairness in transmitting distinct emergency calls. If the $R{S}_{\mathrm{th}}$ of an emergency call is high, the probability that the call reaches a gNB becomes higher. However, under a dense network and/or a high number of emergency calls, increasing the number of relay thresholds may lead to saturation of network devices in the busy state, and many interferences. Late emergency requests are penalized or rejected since the first emergency requests remain longer in the pending requests list $\eta$. In the 5G-SOS protocol, a device adjusts the value of its $R{S}_{\mathrm{th}}$ according to the real-time conditions following the expression:

$$R{S}_{\mathrm{th}}=R{S}_{\mathrm{th}}^{\max }-\mid \eta \mid .$$

(6)

4.1.3. Waiting Time for Re-Transmission, $T_0$

As seen in Algorithm 1, the source of the emergency call waits a period of time $T_0$ to check if sufficient devices have relayed emergency calls. The computation of the $T_0$ parameter follows the same behavior of $T_{max}$ since the retransmission delay has to align with the $T_{max}$ of the neighbor devices in order to prevent losing the retransmitted call in the neighborhood. Consequently, $T_0$ is modeled as (7):

$$T_0=T_{\max }(n_k,n_c).$$

(7)

4.1.4. Emergency Call List

The 5G-SOS protocol-enabled device uses two kinds of lists to store the history of received emergency calls in the buffer. In the $\chi$ list, the device stores the identifiers of received calls represented by the couple $(srcID,callID)$, while the data of the emergency are not stored. To prevent the excessive increase of this list, the emergency calls are removed from the list after a given period (30 min). In the second list, $\eta$, the device stores the pending received emergency calls. A call is removed from $\eta$ when the $T_r$ expires and the call is relayed by the device, or when the call is sufficiently relayed by neighboring devices. The size of $\eta$ is limited to three calls. If the limit size is reached, new emergency calls are ignored as presented in Algorithm 2. The use of $\eta$ is a new feature of the 5G-SOS protocol. In the M-HELP protocol, only one emergency call is processed by the device at a given time. All emergency calls received during the transmission of a previous emergency request or during the pending period before relaying a previous emergency call are ignored.

In order to investigate the performance of our protocol, we evaluated and compared 5G-SOS with the existing M-HELP [9] and FINDER [10] protocols under extreme emergency scenarios. Thereby, the 5G-SOS testing environment, evaluation parameters, and performance analysis are presented in the next section.

5. Simulation Results

5.1. Test Environment

The performance of the proposed 5G-SOS is assessed in AnyLogic^® software. An emergency scenario in the Transverse city in Michigan, USA, with a number of devices varying between 5000 to 15,000 and 7 working gNBs covering an area of $16.2\times 21{\mathrm{km}}^2$ is considered. This scenario is illustrated in Figure 6.

5.1.1. Propagation Pathloss Model and RSSI

In 4G/5G networks, operational gNBs periodically broadcast control signals, PBCH, over predefined resource blocks. The RSSI of such signals is computed using (2), where $P_l(d,f)$ represents the path loss of the signal due to environmental factors, i.e., buildings, mountains, etc. To compute the $P_l(d,f)$ in (2), the Cost231 propagation model for semi-urban areas, given in [42], is used. $P_l(d,f)$ of a signal transmitted by a working gNB varies according to the signal transmission frequency of the working gNB, f, and the distance between the working gNB and receiver UE, d, as given in (8). Further, $h_g$ and $h_m$ represent, respectively, the height of the gNB and receiver UE. $C_m$ is a correction offset associated with the semi-urban environment. For the simulations, f is set to 885 MHz. $P_l(d,f)$ varies according to the used frequency, f, and the distance between a functioning gNB and a receiver UE, d, is modeled using (8) and (9). Further, the measured values of RSSI are handled in Watts.

$$\begin{array}{cc}\hfill P_l(d,f)& =46.3+33.9{log}_{10}\left(f\right)-13.82{log}_{10}\left(h_g\right)-a\left(h_m\right)\hfill \\ & +(44.9-6.55{log}_{10}\left(h_m\right))\times {log}_{10}\left(d\right)+C_m,\hfill \end{array}$$

(8)

with:

$$a\left(h_m\right)=3.2\times log{\left(11.75h_m\right)}^2-4.97.$$

(9)

5.1.2. Neighbor Realying Threshold: $R{S}_{\mathrm{th}}$

The maximum threshold for neighbor relaying, $R{S}_{\mathrm{th}}^{\max }$, is set to a constant and $\mid \eta \mid$ denoted the number of pending call requests in the UE buffer. The latter is used to estimate the number of different emergency calls being relayed in the neighboring area. Further, the maximum limit for $\mid \eta \mid$ is assumed to be a constant. Hence, when the value of $\mid \eta \mid$ changes from a minimum to maximum, the $R{S}_{\mathrm{th}}$ adapts its value according to (6). In comparison, the value of $R{S}_{\mathrm{th}}$ is fixed in the M-HELP protocol.

5.1.3. Rosenbrock Parameters

The values of $a,b$ parameters in the Rosenbrock function are empirically fixed for the three ranges of $n_c$ as shown in

Table 4. Adaptive $T_{\max }$ model parameters.

${\mathit{n}}_{\mathit{c}}$ Limits	a	b
$0\le n_c\le 10$	1	0.5
$10\le n_c\le 200$	1	0.2
$200\le n_c$	1	0.1

. Figure 7 shows the impact of the $n_c$ and $n_k$ factors on the value of $T_{\max }$.

5.1.4. Limits of $n_c$

The limits of $n_c$ are determined by applying M-HELP in each individual device in the network devices. Further, the $n_c$ observed under 100 random replications are collected. The minimum and maximum limits of $n_c$ for different device density values such as 100, 1000, and 4000 are gathered and used as $n_c$ limits to be observed by an UE given in Table 4.

5.1.5. Evaluation Criteria

The following metrics are considered to assess the protocol performance.

• Success rate represents the ratio between the number of emergency calls received successfully by at least one gNB/eNB and the total number of emergency calls given by (10).

  $$\mathrm{Success}\mathrm{rate}=\frac{\mathrm{number}\mathrm{of}\mathrm{successfully}\mathrm{received}\mathrm{emergency}\mathrm{calls}}{\mathrm{number}\mathrm{of}\mathrm{emergency}\mathrm{calls}}$$

  (10)
• End–End Latency (EEL) is the average delay between emergency call generation and its first successful reception by a gNB. EEL is measured in seconds and includes all the delays caused by processing, buffering, temporizing, and transmission times given by (11).

  $$\mathit{EEL}=t_{{\mathrm{call}}_{\mathrm{reception}}}-t_{{\mathrm{call}}_{\mathrm{generation}}}$$

  (11)
• Number of messages per node, $\varphi$, represents the average number of relayed emergency messages per device given by (12).

  $$\varphi =\frac{\mathrm{total}\mathrm{number}\mathrm{of}\mathrm{relayed}\mathrm{messages}}{\mathrm{total}\mathrm{number}\mathrm{of}\mathrm{network}\mathrm{nodes}}$$

  (12)
• Energy consumption per node, $\beta$, measures the average energy consumption per device as given by (13). This includes the energy consumed for the transmission and reception of emergency calls.

  $$\beta =\frac{\mathrm{total}\mathrm{energy}\mathrm{consumption}\mathrm{of}\mathrm{total}\mathrm{nodes}}{\mathrm{total}\mathrm{number}\mathrm{of}\mathrm{network}\mathrm{nodes}}$$

  (13)

5.2. Performance Analysis

In this section, the performance of 5G-SOS is studied and compared with M-HELP [9] and FINDER [10] under multiple disaster configurations while 75% of the gNBs in the network area are out of operation. The emergency calls are randomly generated in a uniform distribution, over an emergency occurring time interval (ETI) of 30 min. Further, the performance is assessed by considering that all nodes are stationary. Moreover, for the network protocols considered in this work, if the network nodes do not form a connected graph, emergency calls cannot reach the gNBs during a single emergency call initiation. Hence, the D2D link connection range is set in order to maintain such a connected network. Furthermore, the number of UEs (NoU) and number of emergency calls (NEC) satisfy the condition, NEC < NoU. The provided results are all averaged over 100 random executions, which differ by the source devices at which the emergency occurs and emergency arrival times.

Table 5. Traverse city area emergency simulation parameters.

Parameter	Value
Total network area	16.2 × $21{\mathrm{km}}^2$
Amount of working gNBs	7
Total UE spread	RAND (16.2,21)
Initial $T_{\max }$	120 s
Initial $T_0$	120 s
UE’s GPS localization accuracy	RAND (0.001,1)
Initial UE’s SoC	RAND (0,100) J
BS/gNB Link distance (d)	1.5 km
D2D link connection range	1.5 km
Data transfer delay by D2D mode, $T_{\mathrm{d}2\mathrm{d}}$	10 s
Data transfer delay by classical PUSCH mode	1 s
Maximum limit for $R{S}_{\mathrm{th}}$, $R{S}_{\mathrm{th}}^{\max }$	5
Upper bound of waiting time, $u_b$	120 s
Upper limit of re-transmissions, $n_0$	4
Maximum number of messages in $\eta$	3
Transmit power of gNB, ($P_g$)	300.0 dBm
Signal transmission frequency of gNBs (f)	885 MHz
BS/gNB antenna effective height ($h_g$)	100 m
UE antenna effective height ($h_m$)	1.5 m
Constant offset of Cost231 Hata model ($C_m$)	0 dB
Number of UEs, NoU	variable
Number of emergency calls, NEC	variable
Emergency calls occurring interval, ETI	variable
Energy to transmit	0.08 mJ [10]
Energy to receive	0.05 mJ [10]
Total Simulation running time	30 min

summarizes the parameters used in the simulation scenarios. The emergency data transfer takes $T_{d2d}$ seconds. During the emergency call transmission (D2D transmission or ordinary transmission) the UE cannot transmit other emergency requests.

5.2.1. Scenarios and Tests

Extreme emergency scenarios are considered to assess the performance of 5G-SOS. In particular, success rate, $EEL$, $\varphi$, and $\beta$ metrics under extreme emergency call duration, device density, data size, and emergency call number are studied.

5.2.2. Impact of Emergency Call Duration

The impact of ETI on success rate and EEL is observed in Figure 8 and Figure 9. It is observed that when the emergency call arrivals are spread over a longer ETI, the amount of successful transmissions increases. As the relay nodes become overcharged due to a shorter ETI value, the probability that a node ignores an incoming request, due to the buffer saturation, increases. In contrast, when the ETI is longer, the number of idle relay nodes available to cater to each relay request is higher.

Further, it is seen that with the increment in ETI, the success rate and EEL of 5G-SOS is significantly improved compared to M-HELP and FINDER. The adaptive parameters in 5G-SOS enhance the responsiveness to a large number of emergency calls occurring in a shorter ETI. The parameters, $R{S}_{\mathrm{th}}$ and $T_{\max }$, are adaptive in 5G-SOS compared to M-HELP, where such parameters are fixed to a specific value. The reason for the success rate being lower in the FINDER protocol is due to devices relaying the data only to the cluster head (CH). The CH aggregates the received data and sends them to nearby CHs. Such an aggregation results in a high traffic concentration on CHs and reduces the success rate. Moreover, under each protocol, the EEL increases against the duration of ETI. As the emergency calls occur over a shorter ETI, the amount of idle relay nodes is low. Further, since relay nodes do not buffer the simultaneously received calls in M-HELP, only a few calls are successfully transferred to the gNB. Hence, initially the corresponding latency in M-HELP is low. The EEL in 5G-SOS is initially higher than M-HELP since the success rate of calls is higher and hence the corresponding latency increased. As the adaptive parameters in 5G-SOS allow the quick transferring of calls, the amount of waiting at the relays decreases and hence results in a lower EEL compared to both M-HELP and FINDER. In FINDER, the delay in allocating a cluster head and communicating calls via multiple cluster heads causes the increment in EEL, when the amount of successful calls increases.

5.2.3. Impact of Device Density

In Figure 10 and Figure 11, we study the impact of the network density on the emergency call transfer under a fixed number of emergency calls and fixed emergency time interval. As observed in Figure 10, the success rate increases with the increment in the number of UEs since it increases the availability of more idle nodes under all the protocols considered. A higher number of idle nodes increases the probability of serving a large number of emergency calls compared to a low device density network. As in the previous section, initially the EEL in 5G-SOS increases compared to M-HELP, since a higher latency is consumed to achieve a higher success rate under the constraints of increasing local congestion. It is reflected in Figure 9 where the EEL increased against the number of UEs due to the increment in the local congestion and thus the waiting times $T_r$ in 5G-SOS. The increment in local congestion increases $T_{\max }$ and causes a saturation in buffers, which result in lower relaying efficiency. However, the adaptive nature in 5G-SOS parameters allow faster relaying of calls compared to M-HELP and FINDER. It is observed that increasing the number of devices plays a positive role in the improvement of the success rate of 5G-SOS, M-HELP, and FINDER. The use of 5G-SOS significantly reduces the EEL compared to M-HELP and FINDER, since 5G-SOS uses the local congestion data, RSSI, and buffering to increase the relaying efficiency in an adaptive manner.

5.2.4. Impact of Emergency Data Size

The emergency data size depends on the type of data such as text, audio, video. The emergency data size increases respectively with text, audio, and video data types. Moreover, the emergency call data size is completely correlated with the transmission duration of the emergency call (D2D or classic mode). Hence, the impact of emergency data size on the performance of 5G-SOS is observed in Figure 12 and Figure 13, where emergency calls occur within a fixed ETI. As shown in Section 5.2.4, when the data quality is low, the success rate is higher compared to transferring high quality data. Hence, it is noted that the proposed 5G-SOS is mostly suitable for a low quality data transfer, which would be convenient during disaster situations. As the duration for emergency call transfer increases, the number of busy nodes, processing other emergency calls, increases. This leads to a lower relaying efficiency and thus a drop in the overall number of successful transmissions. As expected, the latency increases in 5G-SOS. M-HELP and FINDER increase the data transfer time since the data type directly impacts the delay at each relay. Further, only one emergency request could be transmitted at a time which correspond to the delay before relaying.

5.2.5. Impact of the Percentage of the Number of Emergency Calls (NEC) over the Total Number of UEs (NoU)

First, it is observed, in Figure 14, that the success rate of 5G-SOS is nearly 100% when the number of emergency calls are less than 5% of the total devices. Further, when the percentage of NEC over NoU approaches 80%, i.e., almost all nodes generate an emergency call, around 37.4% of calls are relayed successfully against only 29.5% in M-HELP and 8.7% in FINDER. Moreover, when 5000 emergency calls occur within an ETI of 600 s (10 min), more than 50% of calls reache the core network, as observed in Figure 8.

Figure 15 presents the EEL under varying NEC over NoU ratios. It is noted that 5G-SOS adapts the $T_{\max }$ parameter according to the $n_k$ and $n_c$ factors, as discussed in Section 4. Hence, when the ratio between the number NEC and NoU reaches 80%, the EEL is further reduced by adapting parameters such as $T_{\max }$, $R{S}_{\mathrm{th}}$, to serve large amounts of emergency calls. Overall, we observe that the 5G-SOS protocol presents a reduced latency over M-HELP and FINDER.

Additionally, as seen in Figure 16, 5G-SOS provides a slightly higher average number of messages per node than M-HELP. The amount of emergency call requests served by 5G-SOS is higher than M-HELP due to buffering multiple calls. Hence, the average number of messages per node has increased against M-HELP. Furthermore, compared to FINDER, 5G-SOS and M-HELP adopt a massively distributed approach where there is no weight on a particular device to relay the emergency call to the gNB. Since the relay devices listen to the transmissions of the same emergency data before transmitting the emergency data on their own, less traffic is generated in the network. Furthermore, the stronger relay devices transfer the message before any other relay device in the neighborhood.

In terms of residual energy, FINDER has a higher energy consumption compared to 5G-SOS and M-HELP, as seen in Figure 17. Furthermore, CHs in FINDER consume higher energy than cluster member devices. Moreover, 5G-SOS consumes a higher energy compared to M-HELP. The 5G-SOS buffers the multiple simultaneous calls received while M-HELP ignores such calls. The computation of the waiting time $T_r$ in (4) offers a dynamic and distributed way to select the stronger relay devices and limit the maximum $T_r$ based on congestion detected in the local neighborhood; this avoids high data congestion at a particular relay device, disperses the traffic among the network devices, and conserves the energy of the intermediate relay devices. Furthermore, the use of the $R{S}_{\mathrm{th}}$ parameter prevents overloading the network with multiple copies of the same requests in a dense environment. Moreover, the lightness of the protocol adding less weight on the relay devices and utilizing the stronger devices to transmit emergency data are the major contributions of 5G-SOS and M-HELP compared to FINDER. All in all, 5G-SOS and M-HELP have improved performance compared to FINDER in terms of transmission success rate, EEL, energy consumption, and network congestion control.

The overall summary of the performance of 5G-SOS over M-HELP and FINDER is given in

Table 6. Summary of performance analysis.

Parameter	Gain in 5G-SOS vs. M-HELP	Gain in 5G-SOS vs. FINDER	Comparison
Success rate	$24.9\%$	$73.90\%$	$\mathrm{Success}{\mathrm{rate}}_{5G-SOS}$>$\mathrm{Success}{\mathrm{rate}}_{M-HELP}$
			>$\mathrm{Success}{\mathrm{rate}}_{FINDER}$
$EEL$	$-20.80\%$	$-61.70\%$	$EE{L}_{5G-SOS}$<$EE{L}_{M-HELP}$<$EE{L}_{FINDER}$
$\varphi$	$29.10\%$	$-79.20\%$	${\varphi }_{M-HELP}$<${\varphi }_{5G-SOS}$<${\varphi }_{FINDER}$
$\beta$	$6.20\%$	$-81.30\%$	${\beta }_{M-HELP}$<${\beta }_{5G-SOS}$<${\beta }_{FINDER}$

. The average improvement by 5G-SOS over all the scenarios considered is approximately 24.9% than M-HELP and 73.9% than FINDER in terms of success rate. Further, the reduction in average end–end latency is 20.8% compared to M-HELP and 61.7% compared to FINDER. Moreover, 5G-SOS enabled a reduction in the average energy consumption by 79.2% compared to FINDER. In contrast, 5G-SOS has a higher energy consumption than M-HELP by around 29.1%. On top of that, the average messages per node in 5G-SOS is lower than FINDER by around 81.3%, but higher than M-HELP by 6.2%.

6. Conclusions

Simulation results using 5G-SOS over Traverse city of Michigan, USA, with a 15,000 population, demonstrated that 5G-SOS succeeds in transfering more than 80% of the emergency calls when the victims represent <5% of the devices. Further, it was observed that 5G-SOS provided a higher success rate, higher average residual energy per node, and lower average number of sent messages per node than FINDER. Moreover, 5G-SOS enhanced M-HELP performance in terms of success rate and end–end latency. In addition, 5G-SOS provided satisfactory performance (success rate of 50%) even when the number of simultaneous emergency calls became very high (5000 calls over 10 min). On average, 5G-SOS performed 24.9% better than M-HELP and 73.9% than FINDER in terms of success rate. Additionally, 5G-SOS reduced the average end–end latency of the emergency calls transfer by 20.8% compared to M-HELP and 61.7% compared to FINDER. The 5G-SOS protocol is characterized by adaptive behavior that uses locally available data provided by sidelink (from neighbors) and downlink (from gNBs) signals. This adaptation allowed adjusting the expected performance of the service (latency and success rate) to the current charge of the network. Limitations of 5G-SOS are having a higher energy consumption than M-HELP by around 29.1% and slightly higher average messages per node than M-HELP by 6.2%. Thereby, designing energy-efficient mechanisms for 5G-SOS-enabled emergency devices is an interesting extension to this work.