# A Novel Approach to Building a Heterogeneous Emergency Response Communication System

Authors: Janez Sterle; Miha Rugelj; Urban Sedlar; Luka Koršič; Andrej Kos; Peter Zidar; Mojca Volk
Journal: International Journal of Distributed Sensor Networks
 (2015)

---

## Abstract

We present a specification and a nationwide pilot implementation of a future public safety communication system. We propose a novel approach to survivable heterogeneous emergency communication systems, merging professional and commercial off-the-shelf (COTS) equipment, communicating over state-of-the-art mobile and satellite links. We explain the architecture and functional outline of an Advanced Emergency Response Communications System (A-ERCS), which was developed and integrated with professional, commercial, and ad hoc networks to provide survivable communications services and sensor-based applications to support public safety agencies in their day-to-day operation and disaster relief missions. Further, we present the results of a real-world pilot implementation, customized for fire fighter services in Slovenia, and discuss the outcomes of performance tests, showing how the proposed solution can be applied in public safety practice and how COTS technologies can be efficiently and reliably reused in this specific domain.


---

## Body

## 1. Introduction

Earthquake in the Emilia-Romagna region in Northern Italy (2012), earthquake and tsunami in Tohoku region in Japan (2011), and September 11 attacks in the United States (2001)—those are examples of natural and man-made disasters that are part of life which can happen at any time, with little or no warning, and in unfortunate cases with devastating consequences. The ability of public safety agencies to cope with such unexpected situations with efficiency and effectiveness depends heavily on their preparedness for emergency management with appropriate communications infrastructures in place.In day-to-day operations, the emergency communications systems (ECS) set up by public safety agencies for professional use operate normally. However, in case of severe conditions, availability and appropriateness of communications services for first responders is a multidimensional challenge.Survivability of individual ECS deployments is subject to planning and resilience support as well as concrete damage in individual situations. Total autonomy, full operational control, service planning for known and preauthorized professional end-users, and targeted system planning are the four key approaches in use that separate today’s ECS from commercial and other specialized networks. There is no explicit technology or approach that could reduce professional systems’ vulnerability compared to day-to-day deployments. Hence, public safety agencies typically rely on two or more parallel professional systems with different vulnerability profiles to increase survivability of their telecommunications infrastructure, for example, a Terrestrial Trunked Radio (TETRA) system and a satellite network. This was, for instance, the case during the Tohoku earthquake incident in Japan (2011) when the affected areas suffered complete telecommunications outage and the satellite system was the only available communications infrastructure.Another challenging aspect concerns technological capacities and features available in ECS systems. In the past decades, there has been immense progress in commercial and consumer communication technologies, systems, and services that today allow for powerful high-bandwidth mobile communications with converged voice, data, video, and sensor-based services, as well as ad hoc, self-healing, and context-driven capabilities. Yet, professional systems today typically rely on narrow-bandwidth circuit-switched voice services based on technologies that are proven for their resilience and controllability but are far outdated in terms of data-centric services, mobility, and flexibility [1]. This is primarily due to the fact that high availability and system autonomy have priority over high system capacity and rich portfolio of supported functionalities and services, resulting in purpose-built systems optimized for voice communications with integrated policies for predefined chain-of-command hierarchies of the agency. However, the experience from different first responder missions in the past years has led to a conclusion that voice and data are equally important means of communication in emergency situations. In all European countries, public safety agencies have implemented individual ECS systems based on DMR, TETRA, and complementary VHF/UHF technologies. Current professional systems are optimized for voice communication with special features for public safety use including direct terminal-to-terminal communications, push-to-talk functionalities, and group service calls. TETRA has also data capabilities but they are limited with the system channel speed at 9.6 Kbps.Simultaneously in nearly all European countries there are several commercial mobile networks with High Speed Packet Access (HSPA) and, recently, Long Term Evolution (LTE) capacities, a variety of municipal and agency WiFi networks as well as fixed broadband networks (Digital Subscriber Line and Fiber to the Home), all with at least a couple of hundreds of times faster data rates; for example, in Slovenia the highest deployed mobile system data transmission rates vary between 20 Mbps on HSPA and 150 Mbps on LTE networks and support any kind of IP-based communication, including VoIP, video and data transmission, and streamed video. Also of importance and in relation to the commercial communication technologies are the emerging ad hoc setup functions and direct terminal-to-terminal capabilities (i.e., proximity services in LTE standardized with 3GPP release 12 and WiFi Direct mode). Yet, in case of a disaster, use of commercial systems is not recommended for mission-critical services [2].Another important aspect that goes against professional systems and in favor of commercial technologies is the availability and cost of the professional technology compared to commercial off-the-shelf (COTS) products for use in public commercial systems. Professional terminal equipment is costly and first responders are equipped based on agency’s custom preorders. On the other hand, handhelds, tablets, routers, and switches are low-cost COTS devices available in the nearest store.Other areas relevant to the ECS are sensor systems and Internet of Things (IoT) technologies. These have become a mainstream and mature technological field with a variety of commercially available sensor sets for situation surveillance and environment monitoring (e.g., avalanche trackers, water level sensors, heat sensors, CO and butane probes, and temperature and humidity sensors), well-being (e.g., heart-rate monitors, heat exposure sensors, location trackers, and accelerometers), and large-scale high-end solutions for smart context-aware surveillance and monitoring in modern settings, such as SmartCity, SmartEnergy, and SmartGrid. The ability of contextualized decision making and prioritization in disaster relief situations has been proven as a vital aspect preventing consequences that are inconvenient at best and disastrous at worst.This altogether calls for a new era in professional emergency communications systems capable of coping with different requirements and constraints for different scenarios, occurring in day-to-day operations and massive disaster relief interventions, allowing for coordinated cross-agency operations as well as international cooperation. This raises a number of research challenges in three major directions:(i)
Providing high-performance communications in day-to-day operations and survivable communications in extreme situations using distributed architectures and service intelligence.(ii)
Use of IoT and sensor technologies in ECS systems to provide contextualized support for on-site intervention management.(iii)
Support for advanced ECS features such as multidimensional mobility and tracking, admission control flexibility, and system scalability by means of advanced networking technologies and information-centric admission control intelligence.The following section proposes an advanced heterogeneous ECS system for emergency response communications and explains its architecture. The technologies used in the A-ERCS design are presented as well as the composition of its major components, followed by insights into pilot deployment and performance testing of the deployed system. The paper is concluded with a discussion on future technological challenges and opportunities of heterogeneous ECS systems, followed by concluding remarks.


## 2. Novel Heterogeneous Emergency Communications System Architecture

The proposed solution is an Advanced Emergency Response Communications System (A-ERCS), capable of provisioning novel mobile, sensor, and web applications and services for first responders based on transparent, context-driven, and survivable communications powered by all-IP and ad hoc connectivity modes, state-of-the-art mobile and satellite links, and support for sensor and wearable computing deployments.Its main objective is to enable survivable heterogeneous ECS using COTS principles on top of professional and commercial communication infrastructures as well as IoT technologies, thereby closing the gap between today’s ECS systems and the vision of a future information-driven Broadband Public Protection and Disaster Relief (BB PPDR) environment [2].The concept of the solution is represented in Figure1. It follows the principles of a distributed and robust overlay communication solution in portable or mobile setup installed on a tactical command level typically located on site of the intervention. During day-to-day operations and disaster relief missions, the system provides first responders with data transport and rich multimedia services, which are enabled across professional (e.g., DMR, TETRA, P25, and satellite), commercial (e.g., HSPA, LTE), and ad hoc networks (Mesh WiFi, standalone compact LTE/EPC) that are at a certain point in time available on the location of the intervention. A-ERCS core mobile node maintains transparent connectivity from the on-site location into the headquarters by setting up the connection via the best available professional, commercial, or ad hoc access network currently available on the location; if one network (e.g., TETRA) fails, the A-ERCS system transparently switches to the next best available network (e.g., LTE). State-of-the-art IPv6 features such as Network Mobility (NEMO) transparent tunneling with multiple care-of addresses, Dual Stack Mobile IPv6 (DSMIPv6) with flow mobility features, controlled multicast transmission with scope options, and ad hoc node-to-node routing capabilities based on Open Shortest Path First (OSPFv3) link-local addresses are used as a convergence layer in the form of a smart mobile network enabler that provides transparent connectivity and hence survivability of communications. Using NEMO and DSMIPv6 tunneling approach, the system is capable of integrating the best functionalities and principles of professional (system robustness), commercial (high performance and low latency), satellite, and ad hoc (high availability) backhaul communication networks into a powerful ECS solution to support first responders in their day-to-day operations as well as in extreme disaster relief missions.Figure 1
A novel heterogeneous ECS approach.


### 2.1. A-ERCS System Architecture

As depicted in Figure2, the A-ERCS system comprises the following system segments (right to left):(i)
On-site emergency infrastructure, termed A-ERCS node extension, comprising A-ERCS mobile devices for communication throughout the intervention among members of the on-site unit as well as with the Tactical Emergency Control Center (TECC); sensor systems, such as water level sensors, earthquake monitoring system, and heat sensors; and on-site communication infrastructure, such as Mesh WiFi.(ii)
Core communication node (A-ERCS node), implemented in the TECC vehicle, supporting on-site intervention coordination and communication with the Strategic Emergency Control Center (SECC) leading the entire operation from the headquarters.(iii)
An A-ERCS backhaul-supported system, constructed as a heterogeneous communication infrastructure comprising core network(s) and different professional and commercial access networks and ruggedized COTS systems in the role of a (redundant) backhaul transport infrastructure.(iv)
SECC located on distributed sites and responsible for the control and cross-communication of the entire operation on a national level (including cooperation and communication with other civil protection, rescue, or military services) as well as cross-border cooperation.Figure 2
High-level A-ERCS system overview.The integrated segments together build a converged emergency response infrastructure, capable of providing operational assistance services for the on-site first responder unit and the TECC team, as well as situational awareness and monitoring of the intervention site. An example of such integrated infrastructure and its functional elements is represented in detail in Figure3.Figure 3
A-ERCS system architecture.


### 2.2. A-ERCS Node

The principal role of the A-ERCS node is to provide intelligence that is able to automatically and transparently set up, configure, and maintain connectivity with and between the available networks and systems at all times during the intervention, taking into account the fact that during the intervention one or several backhaul transport systems might fail. Internal A-ERCS node logic monitors the connectivity status of the connected interfaces (i.e., HSPA/LTE, satellite, and WiFi) and periodically measures Quality of Service (QoS) capabilities of the available network. Based on predefined policy manager rules and policy based routing functions appropriate IPv6 packet forwarding treatment can be enforced.For example, in the case of a major natural catastrophe, such as an earthquake, the A-ERCS system will try to set up connectivity between the TECC and the SECC via any available HSPA or LTE network. If the HSPA or LTE network fails, the A-ERCS node would instantly and seamlessly reestablish the connectivity via a satellite network or an ad hoc WiFi/WiMAX backhaul system that was set up to support the intervention.Furthermore, based on currently available connectivity, the A-ERCS node can prioritize services using IPv6 and LTE access network QoS capabilities according to the currently available transmission capacities and access network capabilities. For example, voice services will have first priority (i.e., LTE QoS Class Identifier (QCI) 1 with Guaranteed Bit Rate (GBR) of 100 Kbit/s and Expedited Forwarding (EF) DiffServ treatment), followed by messaging and sensor readings as second priority, and video/image transfer as third priority. Actual availability of these services is subject to available backhaul networks and the respective capacities. For example, in case of an intervention due to a massive traffic accident, the A-ERCS node can establish voice and messaging services between the TECC and SECC via a professional system and non-mission-critical video/image transfer via a commercial network HSPA/LTE. On the other hand, in case of an earthquake, the majority of commercial systems will probably fail. In this case, the A-ERCS node would establish voice and messaging service via a TETRA system, while video/image transfer service would no longer be available due to lack of capacities, unless a dedicated microwave link (e.g., ad hoc WiFi) is set up between the TECC and the SECC. In case of an aftershock and outage of the TETRA system and the microwave link, voice services would be reestablished via a satellite system while other services would no longer be available.An important aspect of the A-ERCS node operation is its ability to respond to current circumstances and to set up and configure communication services automatically and with minimum delay. This accounts for highly reliable communications and is achieved through a set of advanced self-configuration and self-organization features enabled by extended IPv6 protocol functions (i.e., A-ERCS node multihoming based on NEMO support with multiple care-of addresses, ad hoc node-to-node routing with OSPFv3 based on link-local addressing, and IPv6 Policy Routing for strict policy enforcement). Also, the A-ERCS system itself needs to provide reliable and resilient operation, requiring further self-configuration and self-healing features (i.e., network multihoming with Border Gateway Protocol (BGP) routing for multidomain connectivity). Also incorporated in the A-ERCS node are local applications (such as a push application to deliver fire routes to the first responder’s device, a vital signs monitoring application) and databases (e.g., local fire route and 3D building plans database, intervention inventory, and contact lists) and a management system.The described A-ERCS node features require a corresponding mobile and portable hardware infrastructure. Core components are a router with various heterogeneous backhaul interfaces and smart routing and policing features, a firewall function, and a system server as well as terminal equipment (e.g., user devices, monitors, printers, and faxes).


### 2.3. A-ERCS Node Extension

The A-ERCS node extension is a segment of the A-ERCS infrastructure, deployed on site where the first responder units are in operation (e.g., a Public Fire Fighter Service). In the A-ERCS context it is positioned as an extension to the infrastructure deployed in the TECC vehicle. Its role is to provide services utilizing professional voice services (e.g., TETRA) and data services (e.g., video transmission, image transmission, and other data services) using local on-site WiFi mesh and WiFi Direct connectivity or available professional or commercial networks (e.g., ad hoc links, especially in situations when the TECC is not located directly on site).In general, the implementation and operational features of the A-ERCS node extension for communication services must follow the requirements and features of the A-ERCS node. Two systems/technologies are planned, professional system for voice communication and local Mesh and Direct WiFi for non-mission-critical data and video communication. Ad hoc WiFi setup capabilities are enabled with IPv6 link-local addressing features and OSPFv3 routing functions.Part of the A-ERCS node extension is also a sensor setup based on 6LoWPAN, planned to support local TECC applications as well as sensor-based applications in other parts and units of the emergency response system as a whole, for example, for on-site video surveillance of the conditions, automated avalanche monitoring, and periodic radiation measurements of nuclear plant areas.


### 2.4. A-ERCS Strategic Emergency Control Center

In terms of communications infrastructure, the SECC represents the backend part of the A-ERCS infrastructure that is in direct communication with the A-ERCS node via the backhaul-supported systems. Its role is twofold:(i)
To assure voice communication with the assigned TECC team member in charge during an intervention according to the specified intervention procedures.(ii)
To provide (selected, adjusted, or limited) access to and connectivity with intervention support services, such as team dispatcher application and inventory, and tools for real-time collection and analytics for sensor data.To provide connectivity towards the TECC via the backhaul-supported systems, a SECC router with smart tunneling and policing functions, a SECC firewall, and L2/L3 switch are required.


### 2.5. A-ERCS Backhaul-Supported System

This segment represents a heterogeneous transport infrastructure comprising existent and newly deployed professional, commercial, and alternative networks able to provide data connectivity based on IP. Its role is to provide transparent data transport infrastructure used by the A-ERCS node for connectivity between the TECC and the SECC. The A-ERCS node is in charge of prioritization, policing, routing, and establishment of connectivity via the most appropriate transport networks based on the available transport network capabilities, defined use case scenarios that correspond to the established emergency response procedures, and protocols of the first responder agency.On the side of professional systems, TETRA, P25, DMR, or VHF/UHF system can be in use today on a national level for civil protection and rescue services. Built with Professional Mobile Radio (PMR) technologies it assures high reliability and coverage. However, current network capabilities on a system level are limited to up to 9.6 Kbps per data channel typically with no direct support for IP data transfer. Currently, only voice communications and very-low-bitrate file transfer are supported. Bearing in mind that the system is narrowband, it does not correspond to the requirements of an advanced modern ECS system. Therefore, within the A-ERCS system, additional professional backhaul systems are planned for use, namely, satellite and professional LTE/EPC systems.Commercial backhaul systems are currently not used for mission-critical public protection and disaster relief purposes. For the case of Slovenia, there are currently three major mobile operators with their own network infrastructure and nationwide coverage, all supporting EDGE and HSPA+ radio network technologies, with bandwidth capabilities up to 42 Mbps on the system level. Two mobile networks also support LTE with system speeds of up to 150 Mbps.The third backhaul option for the A-ERCS system, also not in use for the time being in regular procedures, is alternative ad hoc systems. Backhaul WiMAX and Mesh WiFi systems provide an alternative to professional and commercial communication solutions, especially under unusual or even critical circumstances. An important advantage of such systems is the ability for an ad hoc setup as well as a variety of advanced features for instant network setup, configuration, and operation (such as plug-and-play capabilities, self-organizing, and mesh capabilities).


### 2.6. A-ERCS Pilot

The described A-ERCS system has been implemented as a BB PPDR pilot test bed integrated with fixed, mobile, and satellite networks provided by the Slovenian national operator Telekom Slovenije.In EDGE, HSPA, and LTE networks, a dedicated private Access Point Name (APN) service was set up with QoS options. Three separated levels of user and node authentication and authorization functions (e.g., Evolved Packet System Authentication Key Agreement (EPS AKA) with extended user and terminal authentication, end-to-end IPSec and TLS encryption functions and application security) and dedicated APN integrated with Multiprotocol Label Switching Virtual Private Network (MPLS VPN) were used for securing and virtualizing national mobile network capabilities for first responders use. National MPLS network was used for connecting control and data plane capabilities of private virtual mobile network through L2 MPLS VPN domain to the SECC, connecting A-ERCS mobile nodes, users, and sensors with the services placed strategically. Tight integration between the SECC system control (e.g., LDAP and RADIUS enforcement servers) and the national mobile network provides full access and service control (e.g., node and user terminal authentication and remote provisioning) over A-ERCS mobile nodes and users.For the case of extreme disaster relief operations, broadband satellite connectivity provided by Telekom Slovenije is utilized, capable of transporting A-ERCS node services and strategically located services over IPSec and TLS-secured IPv6 tunneling, with data speed of up to 4 Mbps.From the implementation perspective, as represented in Figure4(a), Cisco ruggedized mobile router with LTE, HSPA, EDGE, Ethernet, and serial interfaces and smart tunneling, routing, policing, and security features was selected as a platform for the deployment of the A-ERCS mobile node capabilities. Router internal system logic (i.e., Embedded Event Manager and IP SLA) was used for the implementation of the A-ERCS backhaul system discovery function and as intelligent service routing engine capable of selecting the appropriate backhaul tunneling link for active services on site of the intervention. Debian operating system with prestandard implementation of DSMIPv6TLS tunneling capabilities from Nokia Networks [3] and industrial computer with integrated LTE, HSPA, EDGE, WiFi, and Ethernet connectivity were used for implementation of an advanced sensor gateway functioning as the A-ERCS mobile node extension, with GPS, temperature, humidity, and video surveillance capabilities.Figure 4
Pilot A-ERCS system deployment. (a) Left shows A-ERCS portable node implementation and right triage and tracking application. (b) Intervention management software.
(a)
(b)In addition, to support BB PPDR system trial execution and testing, IoT-driven tactical intervention management software of the 6inACTION system was used (Figure4(b)), incorporating central web-based intervention management dashboard customized for site monitoring, surveillance, and sensor analytics. User access control of the management system enables customizable views for strategic, command, and operational levels, with real-time tracking and monitoring capabilities of units, users, devices, and sensors.Lastly, a smart phone triage and tracking mobile application was used to pilot BB PPDR end-user devices (Figure4(a)). The application is also part of the 6inACTION system and is available for Android and iOS mobile terminals with capabilities of real-time unit tracking and smart triage reporting. Hardened water, shock, and dust proof enclosures were used to protect commercially available smart phones and tablets in extreme conditions.Finally, from the business perspective, the “Company Owned, Company Operated” (CoCo) model was considered for implementation, that is, a BB PPDR service delivered by a third party as described in the CEPT ECC requirements for future European Broadband Public Protection and Disaster Relief system services [2].


### 2.7. A-ERCS Performance Testing

Performance tests of the A-ERCS were performed using HSPA, LTE, satellite, and L2 MPLS VPN backhaul networks. Using a professional measurement system qMON [4], the pilot setup was tested against the following QoS metrics [5]:(i)
RTT (round-trip times) (ms).(ii)
Web resource response and download times (ms).(iii)
Download speed (kbps).(iv)
Upload speed (kbps).Below we present reference results for three static A-ERCS mobile nodes connected to different backhaul-supported systems (i.e., HSPA, LTE, and satellite); all nodes and backhaul systems were functioning in best-effort mode in a densely populated urban location. HSPA and LTE connectivity were limited to 5 MHz radio channel bandwidth in FDD mode even though the LTE network supports radio channel with the size up to 20 MHz. Such usage is foreseen as one of the options for future BB PPDR deployments [2]. Tests were performed in the period between December 2013 and January 2014; during that time, more than 3000 continuous measurements of the selected QoS metrics were taken for each node.Figure5 summarizes system response time measurements between SECC location and A-ERCS nodes tunneling IPv4 (in blue) and IPv6 (in green) services over LTE, HSPA, and satellite backhaul systems. As expected, the presented CDF and histogram graphs reflect superiority of the LTE technology in terms of low data plane system latency (less than 50 ms RTT) and fast idle-to-active activation times.Figure 5
System response time [ms] measured between strategic location and A-ERCS mobile nodes (CDF (line) and histogram (bar) graph).A-ERCS system response time over HSPA backhaul is close to HSPA system capabilities with round-trip times shorter than 100 ms in more than 97% of tests.RTT longer than 100 ms are due to the HSPA network system setting, responsible for aggressively pushing mobile terminals into the idle mode for the reason of smartphone battery saving. Thus, the HSPA mobile interface needs additional time for reactivation of radio resources.High expected round-trip-time delay over satellite connection (above 600 ms) could be attributed primarily to the distance of the communication satellites in the geostationary orbit (35786 km above the equator); with such distances the finite speed of electromagnetic wave propagation itself accounts for 239 ms.A-ERCS system services response time was measured by emulating user activity at each of the A-ERCS mobile nodes. Software agents were used to emulate user interactions with the web-based tactical intervention management dashboard and triage and tracking application. Two use cases were verified emulating first respondent intervention activities: photo download speed in the triage application and tactical dashboard web site download time, the latter reflecting response time for HTTP-based tactical intervention management dashboard applications.As depicted in Figure6(a), in terms of interactive HTTP-based services, the best performance was achieved on the LTE backhaul with the response time below 500 ms in 99% of the measurements. HSPA system reached response times below 2 s in 86% of measurements. Due to the described drawbacks of geostationary satellite communications, A-ERCS node on satellite backhaul had the poorest performance with response times below 6 s in 93% of measurements for IPv4 and 67% of measurements for IPv6.Figure 6
(a) Tactical dashboard WEB download time [ms], and (b) Triage Application Photo download speed [kbps] (CDF (line) and histogram (bar) graph).
(a)
(b)Similar results were obtained in the case of the triage and tracking application photo download speeds with LTE as leading and satellite as the worst performing technology (Figure6(b)).The above results show two important findings. Firstly, IPv4 and IPv6 technologies in the fixed backhaul-supported systems are very mature, but providing a solution integrating fixed and mobile backhaul-supported systems with IPv6 in a compact A-ERCS node presents a significant challenge. Secondly, the cause of performance impact on IPv6 connectivity can be linked to using nonnative tunneling techniques within the ruggedized mobile router. Confirming these findings, some efforts have already been dedicated to resolving the availability of mobile network equipment with integrated 3G and 4G interfaces with dual stack IPv4/IPv6 EPS bearer and PDP context support. In the long run, the solution to this challenge is the use of LTE in the ruggedized mobile router with native IPv6 support.


## 2.1. A-ERCS System Architecture

As depicted in Figure2, the A-ERCS system comprises the following system segments (right to left):(i)
On-site emergency infrastructure, termed A-ERCS node extension, comprising A-ERCS mobile devices for communication throughout the intervention among members of the on-site unit as well as with the Tactical Emergency Control Center (TECC); sensor systems, such as water level sensors, earthquake monitoring system, and heat sensors; and on-site communication infrastructure, such as Mesh WiFi.(ii)
Core communication node (A-ERCS node), implemented in the TECC vehicle, supporting on-site intervention coordination and communication with the Strategic Emergency Control Center (SECC) leading the entire operation from the headquarters.(iii)
An A-ERCS backhaul-supported system, constructed as a heterogeneous communication infrastructure comprising core network(s) and different professional and commercial access networks and ruggedized COTS systems in the role of a (redundant) backhaul transport infrastructure.(iv)
SECC located on distributed sites and responsible for the control and cross-communication of the entire operation on a national level (including cooperation and communication with other civil protection, rescue, or military services) as well as cross-border cooperation.Figure 2
High-level A-ERCS system overview.The integrated segments together build a converged emergency response infrastructure, capable of providing operational assistance services for the on-site first responder unit and the TECC team, as well as situational awareness and monitoring of the intervention site. An example of such integrated infrastructure and its functional elements is represented in detail in Figure3.Figure 3
A-ERCS system architecture.


## 2.2. A-ERCS Node

The principal role of the A-ERCS node is to provide intelligence that is able to automatically and transparently set up, configure, and maintain connectivity with and between the available networks and systems at all times during the intervention, taking into account the fact that during the intervention one or several backhaul transport systems might fail. Internal A-ERCS node logic monitors the connectivity status of the connected interfaces (i.e., HSPA/LTE, satellite, and WiFi) and periodically measures Quality of Service (QoS) capabilities of the available network. Based on predefined policy manager rules and policy based routing functions appropriate IPv6 packet forwarding treatment can be enforced.For example, in the case of a major natural catastrophe, such as an earthquake, the A-ERCS system will try to set up connectivity between the TECC and the SECC via any available HSPA or LTE network. If the HSPA or LTE network fails, the A-ERCS node would instantly and seamlessly reestablish the connectivity via a satellite network or an ad hoc WiFi/WiMAX backhaul system that was set up to support the intervention.Furthermore, based on currently available connectivity, the A-ERCS node can prioritize services using IPv6 and LTE access network QoS capabilities according to the currently available transmission capacities and access network capabilities. For example, voice services will have first priority (i.e., LTE QoS Class Identifier (QCI) 1 with Guaranteed Bit Rate (GBR) of 100 Kbit/s and Expedited Forwarding (EF) DiffServ treatment), followed by messaging and sensor readings as second priority, and video/image transfer as third priority. Actual availability of these services is subject to available backhaul networks and the respective capacities. For example, in case of an intervention due to a massive traffic accident, the A-ERCS node can establish voice and messaging services between the TECC and SECC via a professional system and non-mission-critical video/image transfer via a commercial network HSPA/LTE. On the other hand, in case of an earthquake, the majority of commercial systems will probably fail. In this case, the A-ERCS node would establish voice and messaging service via a TETRA system, while video/image transfer service would no longer be available due to lack of capacities, unless a dedicated microwave link (e.g., ad hoc WiFi) is set up between the TECC and the SECC. In case of an aftershock and outage of the TETRA system and the microwave link, voice services would be reestablished via a satellite system while other services would no longer be available.An important aspect of the A-ERCS node operation is its ability to respond to current circumstances and to set up and configure communication services automatically and with minimum delay. This accounts for highly reliable communications and is achieved through a set of advanced self-configuration and self-organization features enabled by extended IPv6 protocol functions (i.e., A-ERCS node multihoming based on NEMO support with multiple care-of addresses, ad hoc node-to-node routing with OSPFv3 based on link-local addressing, and IPv6 Policy Routing for strict policy enforcement). Also, the A-ERCS system itself needs to provide reliable and resilient operation, requiring further self-configuration and self-healing features (i.e., network multihoming with Border Gateway Protocol (BGP) routing for multidomain connectivity). Also incorporated in the A-ERCS node are local applications (such as a push application to deliver fire routes to the first responder’s device, a vital signs monitoring application) and databases (e.g., local fire route and 3D building plans database, intervention inventory, and contact lists) and a management system.The described A-ERCS node features require a corresponding mobile and portable hardware infrastructure. Core components are a router with various heterogeneous backhaul interfaces and smart routing and policing features, a firewall function, and a system server as well as terminal equipment (e.g., user devices, monitors, printers, and faxes).


## 2.3. A-ERCS Node Extension

The A-ERCS node extension is a segment of the A-ERCS infrastructure, deployed on site where the first responder units are in operation (e.g., a Public Fire Fighter Service). In the A-ERCS context it is positioned as an extension to the infrastructure deployed in the TECC vehicle. Its role is to provide services utilizing professional voice services (e.g., TETRA) and data services (e.g., video transmission, image transmission, and other data services) using local on-site WiFi mesh and WiFi Direct connectivity or available professional or commercial networks (e.g., ad hoc links, especially in situations when the TECC is not located directly on site).In general, the implementation and operational features of the A-ERCS node extension for communication services must follow the requirements and features of the A-ERCS node. Two systems/technologies are planned, professional system for voice communication and local Mesh and Direct WiFi for non-mission-critical data and video communication. Ad hoc WiFi setup capabilities are enabled with IPv6 link-local addressing features and OSPFv3 routing functions.Part of the A-ERCS node extension is also a sensor setup based on 6LoWPAN, planned to support local TECC applications as well as sensor-based applications in other parts and units of the emergency response system as a whole, for example, for on-site video surveillance of the conditions, automated avalanche monitoring, and periodic radiation measurements of nuclear plant areas.


## 2.4. A-ERCS Strategic Emergency Control Center

In terms of communications infrastructure, the SECC represents the backend part of the A-ERCS infrastructure that is in direct communication with the A-ERCS node via the backhaul-supported systems. Its role is twofold:(i)
To assure voice communication with the assigned TECC team member in charge during an intervention according to the specified intervention procedures.(ii)
To provide (selected, adjusted, or limited) access to and connectivity with intervention support services, such as team dispatcher application and inventory, and tools for real-time collection and analytics for sensor data.To provide connectivity towards the TECC via the backhaul-supported systems, a SECC router with smart tunneling and policing functions, a SECC firewall, and L2/L3 switch are required.


## 2.5. A-ERCS Backhaul-Supported System

This segment represents a heterogeneous transport infrastructure comprising existent and newly deployed professional, commercial, and alternative networks able to provide data connectivity based on IP. Its role is to provide transparent data transport infrastructure used by the A-ERCS node for connectivity between the TECC and the SECC. The A-ERCS node is in charge of prioritization, policing, routing, and establishment of connectivity via the most appropriate transport networks based on the available transport network capabilities, defined use case scenarios that correspond to the established emergency response procedures, and protocols of the first responder agency.On the side of professional systems, TETRA, P25, DMR, or VHF/UHF system can be in use today on a national level for civil protection and rescue services. Built with Professional Mobile Radio (PMR) technologies it assures high reliability and coverage. However, current network capabilities on a system level are limited to up to 9.6 Kbps per data channel typically with no direct support for IP data transfer. Currently, only voice communications and very-low-bitrate file transfer are supported. Bearing in mind that the system is narrowband, it does not correspond to the requirements of an advanced modern ECS system. Therefore, within the A-ERCS system, additional professional backhaul systems are planned for use, namely, satellite and professional LTE/EPC systems.Commercial backhaul systems are currently not used for mission-critical public protection and disaster relief purposes. For the case of Slovenia, there are currently three major mobile operators with their own network infrastructure and nationwide coverage, all supporting EDGE and HSPA+ radio network technologies, with bandwidth capabilities up to 42 Mbps on the system level. Two mobile networks also support LTE with system speeds of up to 150 Mbps.The third backhaul option for the A-ERCS system, also not in use for the time being in regular procedures, is alternative ad hoc systems. Backhaul WiMAX and Mesh WiFi systems provide an alternative to professional and commercial communication solutions, especially under unusual or even critical circumstances. An important advantage of such systems is the ability for an ad hoc setup as well as a variety of advanced features for instant network setup, configuration, and operation (such as plug-and-play capabilities, self-organizing, and mesh capabilities).


## 2.6. A-ERCS Pilot

The described A-ERCS system has been implemented as a BB PPDR pilot test bed integrated with fixed, mobile, and satellite networks provided by the Slovenian national operator Telekom Slovenije.In EDGE, HSPA, and LTE networks, a dedicated private Access Point Name (APN) service was set up with QoS options. Three separated levels of user and node authentication and authorization functions (e.g., Evolved Packet System Authentication Key Agreement (EPS AKA) with extended user and terminal authentication, end-to-end IPSec and TLS encryption functions and application security) and dedicated APN integrated with Multiprotocol Label Switching Virtual Private Network (MPLS VPN) were used for securing and virtualizing national mobile network capabilities for first responders use. National MPLS network was used for connecting control and data plane capabilities of private virtual mobile network through L2 MPLS VPN domain to the SECC, connecting A-ERCS mobile nodes, users, and sensors with the services placed strategically. Tight integration between the SECC system control (e.g., LDAP and RADIUS enforcement servers) and the national mobile network provides full access and service control (e.g., node and user terminal authentication and remote provisioning) over A-ERCS mobile nodes and users.For the case of extreme disaster relief operations, broadband satellite connectivity provided by Telekom Slovenije is utilized, capable of transporting A-ERCS node services and strategically located services over IPSec and TLS-secured IPv6 tunneling, with data speed of up to 4 Mbps.From the implementation perspective, as represented in Figure4(a), Cisco ruggedized mobile router with LTE, HSPA, EDGE, Ethernet, and serial interfaces and smart tunneling, routing, policing, and security features was selected as a platform for the deployment of the A-ERCS mobile node capabilities. Router internal system logic (i.e., Embedded Event Manager and IP SLA) was used for the implementation of the A-ERCS backhaul system discovery function and as intelligent service routing engine capable of selecting the appropriate backhaul tunneling link for active services on site of the intervention. Debian operating system with prestandard implementation of DSMIPv6TLS tunneling capabilities from Nokia Networks [3] and industrial computer with integrated LTE, HSPA, EDGE, WiFi, and Ethernet connectivity were used for implementation of an advanced sensor gateway functioning as the A-ERCS mobile node extension, with GPS, temperature, humidity, and video surveillance capabilities.Figure 4
Pilot A-ERCS system deployment. (a) Left shows A-ERCS portable node implementation and right triage and tracking application. (b) Intervention management software.
(a)
(b)In addition, to support BB PPDR system trial execution and testing, IoT-driven tactical intervention management software of the 6inACTION system was used (Figure4(b)), incorporating central web-based intervention management dashboard customized for site monitoring, surveillance, and sensor analytics. User access control of the management system enables customizable views for strategic, command, and operational levels, with real-time tracking and monitoring capabilities of units, users, devices, and sensors.Lastly, a smart phone triage and tracking mobile application was used to pilot BB PPDR end-user devices (Figure4(a)). The application is also part of the 6inACTION system and is available for Android and iOS mobile terminals with capabilities of real-time unit tracking and smart triage reporting. Hardened water, shock, and dust proof enclosures were used to protect commercially available smart phones and tablets in extreme conditions.Finally, from the business perspective, the “Company Owned, Company Operated” (CoCo) model was considered for implementation, that is, a BB PPDR service delivered by a third party as described in the CEPT ECC requirements for future European Broadband Public Protection and Disaster Relief system services [2].


## 2.7. A-ERCS Performance Testing

Performance tests of the A-ERCS were performed using HSPA, LTE, satellite, and L2 MPLS VPN backhaul networks. Using a professional measurement system qMON [4], the pilot setup was tested against the following QoS metrics [5]:(i)
RTT (round-trip times) (ms).(ii)
Web resource response and download times (ms).(iii)
Download speed (kbps).(iv)
Upload speed (kbps).Below we present reference results for three static A-ERCS mobile nodes connected to different backhaul-supported systems (i.e., HSPA, LTE, and satellite); all nodes and backhaul systems were functioning in best-effort mode in a densely populated urban location. HSPA and LTE connectivity were limited to 5 MHz radio channel bandwidth in FDD mode even though the LTE network supports radio channel with the size up to 20 MHz. Such usage is foreseen as one of the options for future BB PPDR deployments [2]. Tests were performed in the period between December 2013 and January 2014; during that time, more than 3000 continuous measurements of the selected QoS metrics were taken for each node.Figure5 summarizes system response time measurements between SECC location and A-ERCS nodes tunneling IPv4 (in blue) and IPv6 (in green) services over LTE, HSPA, and satellite backhaul systems. As expected, the presented CDF and histogram graphs reflect superiority of the LTE technology in terms of low data plane system latency (less than 50 ms RTT) and fast idle-to-active activation times.Figure 5
System response time [ms] measured between strategic location and A-ERCS mobile nodes (CDF (line) and histogram (bar) graph).A-ERCS system response time over HSPA backhaul is close to HSPA system capabilities with round-trip times shorter than 100 ms in more than 97% of tests.RTT longer than 100 ms are due to the HSPA network system setting, responsible for aggressively pushing mobile terminals into the idle mode for the reason of smartphone battery saving. Thus, the HSPA mobile interface needs additional time for reactivation of radio resources.High expected round-trip-time delay over satellite connection (above 600 ms) could be attributed primarily to the distance of the communication satellites in the geostationary orbit (35786 km above the equator); with such distances the finite speed of electromagnetic wave propagation itself accounts for 239 ms.A-ERCS system services response time was measured by emulating user activity at each of the A-ERCS mobile nodes. Software agents were used to emulate user interactions with the web-based tactical intervention management dashboard and triage and tracking application. Two use cases were verified emulating first respondent intervention activities: photo download speed in the triage application and tactical dashboard web site download time, the latter reflecting response time for HTTP-based tactical intervention management dashboard applications.As depicted in Figure6(a), in terms of interactive HTTP-based services, the best performance was achieved on the LTE backhaul with the response time below 500 ms in 99% of the measurements. HSPA system reached response times below 2 s in 86% of measurements. Due to the described drawbacks of geostationary satellite communications, A-ERCS node on satellite backhaul had the poorest performance with response times below 6 s in 93% of measurements for IPv4 and 67% of measurements for IPv6.Figure 6
(a) Tactical dashboard WEB download time [ms], and (b) Triage Application Photo download speed [kbps] (CDF (line) and histogram (bar) graph).
(a)
(b)Similar results were obtained in the case of the triage and tracking application photo download speeds with LTE as leading and satellite as the worst performing technology (Figure6(b)).The above results show two important findings. Firstly, IPv4 and IPv6 technologies in the fixed backhaul-supported systems are very mature, but providing a solution integrating fixed and mobile backhaul-supported systems with IPv6 in a compact A-ERCS node presents a significant challenge. Secondly, the cause of performance impact on IPv6 connectivity can be linked to using nonnative tunneling techniques within the ruggedized mobile router. Confirming these findings, some efforts have already been dedicated to resolving the availability of mobile network equipment with integrated 3G and 4G interfaces with dual stack IPv4/IPv6 EPS bearer and PDP context support. In the long run, the solution to this challenge is the use of LTE in the ruggedized mobile router with native IPv6 support.


## 3. Future Heterogeneous ECS Challenges

The core challenge identified in the currently deployed distributed A-ERCS system is the inability to assure unified view and strict service, control, and data plane consistency across the system as a whole due to the distributed design spanning several heterogeneous communications networks. Service, control, and data planes are decentralized and limited to the domain of each individual network (e.g., A-ERCS system and LTE, HSPA, satellite, and MPLS VPN backhaul). Hence, it is hard to assure strict service prioritization and preemption capabilities in such a decentralized and heterogeneous ECS system.This calls for integration of Software Defined Network (SDN) technologies into the A-ERCS. The targeted technical requirements for future upgrades are advanced communication survivability using SDN driven tunneling with bundling capabilities for virtual channel establishment, allowing for transparent communication establishment over one or several available networks represented as a single virtual channel. Context-driven routing with traffic engineering and dynamic QoS support is needed, as well as dynamic cross-network domain admission control and service preemption support. Very high availability with near-real-time rerouting capabilities is also required, allowing for (almost) instant fallback scenarios in case of extreme conditions causing failure of individual networks. Another technical requirement for future heterogeneous ECS is information-driven user, service and network prioritization based on network and service contexts (e.g., current capacity, QoS parameters, and satellite link delays and priority of commercial networks for streamed video and professional networks for voice communications), and energy efficiency [6].


## 4. Conclusions and Future Work

After a discussion on the communication and service requirements of the BB PPDR domain to adopt advanced and heterogeneous COTS communication technologies, this paper proposes a novel emergency response system architecture that enables survivable and transparent communication capabilities under extreme circumstances by efficiently utilizing existing professional, commercial, and other alternative networks combined with transparent context-driven tunneling mechanisms, advanced networking technologies, and sensor-based services. As presented, a real-world pilot BB PPDR test bed was implemented in Slovenia, with a core mobile node installed in a first responder tactical command vehicle and integrated with commercial EDGE/HSPA/LTE and satellite networks of a national provider. Transparent private mobile network virtualization with IPv6 support and QoS capabilities was enabled, and IoT-based sensor setup was integrated to cater for strategic intervention management services. Next, the paper presents the results of performance tests of the proposed system, demonstrating maturity of IPv6 technologies for PPDR environments and arguing in favor of migration towards LTE technologies for efficient fixed-mobile backhaul networks integration. Finally, upcoming challenges in BB PPDR are discussed, highlighting the potential of SDN technologies to provide enhanced availability, survivability, and transparent backhaul virtualization, as well as contextualized prioritization and preemption support, as required in PPDR day-to-day and disaster relief operations.



---

*Source: 685253-2015-10-04.xml*