The Communication Infrastructure for Future Emergency Systems M. Casoni1 , D. Saladino1, A. Marousis2, K. Maliatsos2, A. Karagiannis2 of Engineering "Enzo Ferrari" - University of Modena and Reggio Emilia, Italy. {daniela.saladino, maurizio.casoni}@unimore.it 2 National Technical University of Athens, Mobile Radio-Communications Laboratory, Greece {amarous, maliatsos, akarag}@mobile.ntua.gr 1 Dept.

Abstract—This paper provides an overview of a novel emergency network architecture. It is a complete suite of real-time communication technologies built to support first responders during disaster events with information services. This work investigates the system architecture, in terms of network structure and topology. More specifically, a scalable and adaptive telecommunication architecture is presented that ensures voice, video and data links of the First Responders to the command centers at all times. The provided communication services and the available technologies are described. In more detail, the structure and functionalities of the VoIP subsystem that operates above the proposed heterogeneous E-SPONDER network architecture will be presented with analysis of the requirements, supported solutions and operation modes. Finally, the paper presents the way the recommended solutions can be actually implemented. Index Terms—Emergency networks; communication services; communication technologies.

I. I NTRODUCTION An emergency network represents the telecommunication infrastructure of a public safety system, and it is used to provide communication support to all the personnel involved in the emergency and rescue operations. The employment of wireless communications to provide successful and efficient coordination of first response in emergency situations is a challenging task. One of the first key problems is the lack of interoperability among equipment devices and infrastructures of legacy systems that constitute different access and backhaul networks [1]. During crisis events, a long chain of communication points in distant locations, from operationscontrol centers to first responders on the incident area, should be established and maintained as long as possible. Moreover, in case backhaul legacy network communication collapses, the distinct aforementioned communication points should be replaced by an alternative proper communication path. The design of a modern public safety system with cutting edge emergency network architecture requires the use of state-of-the-art ICT technologies with support to a variety of applications and services. This can be translated into a search for the best set of applications and technologies that provide the most effective response to crisis events. Emerging broadband Radio Access Technologies (RAT) such as WiMAX or LTE/ HSPA/HSPA+ offer new advantages in terms of QoS The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement n◦ [242411].

for management crisis issues [2]. Lower latency and higher offered throughput enable the use of real-time applications that were formerly forbidden in emergency communications. Broadband technologies are necessary as the rescue operations are now characterized by high quality a) images/photos, b) video streaming from the incident area and c) voice service among all the communication points. This FP7 EU E-SPONDER project offers a scalable and hierarchical architecture for the involved communication nodes. Backhaul legacy networks can be exploited to the extent they are sustainable for communication in any intermediate link from Mobile Emergency Operations-control Centers (MEOC) to the groups of First Responders (FRs). On the other hand, communication via satellite is used to bridge the communication gap among long distant areas, e.g., the communication between MEOC and the Emergency Operations-control Center (EOC) that can span up to hundreds of kilomenters. More specifically, in order to support communication among the FRs an implementation of the Session Initiation Protocol (SIP) protocol is provided, able to establish and control the VoIP communication sessions. The proposed ICT network exploits diverse technology resources that perfectly match each intermediate wireless link. Intelligence is distributed at the end-points of each communication path that will be ad-hoc established in the time of crisis. Moreover, high bandwidth offered by wireless broadband technologies enables the use of certain applications that improve the management of crisis procedures. The rest of the paper is organized as follows. In Section II, we provide a description of the emergency system architecture and of the most suitable network topology, whereas Section III gives an overview of the communication services to be supported, i.e the SIP-protocol VoIP subsystem. Section IV presents the available communication technologies in order to aid the selection of the most suitable one for the suggested network, while Section 5 describes in detail the selected technologies concerning the communication among all the involved entities. Finally, Section VI discusses the conclusions. II. S YSTEM A RCHITECTURE AND N ETWORK T OPOLOGY This section describes the main features of the proposed emergency system, in terms of network topology and architecture. A generic emergency architecture is composed by: • an EOC, that works as the central command and control and manages all the emergency operations;

some MEOCs, i.e. vehicles providing quick support and communications among the involved emergency entities; • groups of FRs, each one equipped with a FR Unit (FRU), that are the on field rescue operators, like policemen, firefighters, and so forth. In order to meet all the emergency needs, deep analysis of both user and services requirements of the European countries was carried out. Naturally, before defining the overall system design, our work has been to identify the topology, and therefore the required network entities and the network connections necessary for communications. More specifically, we have taken into account the “hybrid star-mesh” network topology [3], that represents the most suitable solution in terms of network management, scalability and radio coverage. Information and data exchange in the proposed platform is carried out and supported by a hierarchically organized network. The E-SPONDER communications network is based on an all-IP architecture that uses heterogeneous networks. In this light, new autonomous, standalone, interconnected subnetworks are developed, capable to reliably transfer information from the incident area to the Operation Centers. A general overview of the E-SPONDER network as a descriptive block diagram is presented in Fig. 1. The description of Fig. 1 presents the physical network and radio access technologies that implement the suggested network, and not the logical, hierarchical interconnection of the E-SPONDER entities. The physical networks provide the means to implement through logical rules the E-SPONDER hierarchical scheme. For example, EOC and FRUs can be both connected to a 4G/3G network provided by local operators, and thus a physical path between the entities exist. However, based on the E-SPONDER hierarchy, direct voice communication between EOC and FRUs is prohibited through rules associated with the operation of the VoIP/Communication Server. Nevertheless, since there is a physical interconnection of the entities, data transfer (sensor data, alarms, etc.) can be performed directly to EOC in the cases where MEOC is absent, without the need to tunnel the information through relays. It is also noted that although Fig. 1 presents the interconnection between EOC, a single MEOC and a single FR Team, EOC is able to interconnect with multiple MEOCs and each MEOC can communicate with multiple FR Teams. •

III. A PPLICATIONS

AND

S ERVICES

In any emergency system, all the involved operators have to interconnect in order to coordinate the necessary rescue operations in the best possible way. Therefore, different communication services have to be supported to provide efficient emergency operations. During a disaster event, all the involved rescue nodes (i.e., FRs, FRC, MEOC and EOC) have to be able to make voice calls, that can be provided by means of Voice over IP (VoIP) service [4], allowing the organization of all the relief activities on field. Besides VoIP service, it is useful for the EOC to receive real-time images of the incident area, provided by means of a Video over IP (VIP) application, in order to have greater awareness of the situation, all the real damages and, consequently, to take effective decisions. Both these multimedia

applications represent the main but also the most critical communication services during a disaster event. In fact, they are sensitive to delay and jitter that can undermine the perceived audio/video quality. Moreover, the FRs should also detect and monitor some parameters, like temperature, heartbeat, and so forth, by means of sensors, whose collected information have to be transmitted to the operation control centers. Naturally, there is the need to also provide generic data transfer, that allows the transmission of generic information of the incident area, like a picture on a map. Among all the provided communication services, VoIP and VIP have the higher priority and bandwidth requirements. In addition, the sensor data and file transfer services require certain bandwidth capacities, but much less than the previous ones. Therefore, they do not introduce significant band occupancy problems. As for the FR Team Area Network (TAN), the predominant services are VoIP communications and sensor data, requiring 1.2 Mbit/s [5].The links FRC - MEOC and MEOC - EOC are supposed to support VoIP, VIP, sensor data in uplink and data transfer service in downlink, where the overall bit-rate requested is around 550 kbit/s [5]. A. The SIP Protocol in the VoIP E-SPONDER Subsystem The SIP [6] protocol is a peer-to-peer protocol that perfectly matches the scalable star topology of E-SPONDER hierarchical networking with intelligence distributed to the network edge, embedded in the endpoints. SIP features are implemented in the FR terminals and within the EOC and MEOC entities. SIP services follow the fundamental IP protocol prescriptions where each intermediate node within the network is a passive entity with limited intelligence. This fact increases the scalability of the network and the granularity of solutions to implement VoIP sessions. Thus, SIP is a proper signaling protocol used to establish and control multimedia communication sessions over IP. It employs design elements similar to the HTTP request/response transaction model. Each resource of a SIP network, such as a user agent, is identified by a Uniform Resource Identifier (URI). In the case of the ESPONDER platform, an expression of a typical SIP URI may be: sip:[email protected]. The main objective of the E-SPONDER VoIP subsystem is the provision of voice communication between the hierarchally organized E-SPONDER actors under diverse conditions that may be met during a crisis. In order to achieve this goal, multiple SIP servers should be installed and coordinated in several entities of the network. In this section, a description of the VoIP subsystem architecture is made and a presentation of its operational flow is provided. In the E-SPONDER demo deployment, Asterisk SIP servers are used. The term SIP manager refers to the Asterisk Manager Interface. Let us assume the simplest E-SPONDER deployment consisted of the EOC, a MEOC and an FR team. Three SIP servers are installed on: a) the EOC communication server, b) the MEOC communication server, c) the Special Node (SN) of the FR team. The SIP servers are either in operational state or idle depending on the current circumstances. The EOC and MEOC SIP servers (the OC servers) are coordinated, while the FR SIP server is pre-configured to provide services only for a

Fig. 1.

Fig. 2.

General overview of the E-SPONDER network

Data object example for the initialization of a crisis

specific FR team. The OC servers are managed by the VoIP Application Server (AS), i.e. the interface between the VoIP system and the E-SPONDER software platform. It implements the rules and decisions for the VoIP operation. Two clone AS instances are installed at both EOC and MEOC, however each moment only one AS is active while the other remains idle. The MEOC AS is defined as primary and as long as the MEOC server is accessible by the incident actors, it manages the VoIP subsystem. The AS establishes the VoIP calls and conferences among the E-SPONDER actors with the definition of proper connections and channels through the SIP manager and it is aware of the IP addresses of the involved SIP servers. In this paper, the operation under normal conditions, i.e. when all network entities are accessible, is mainly investigated. 1) Initialization Procedure: Initially the OC servers are idle and no call requests are served. The initialization of the VoIP subsystem is made with the definition of a new crisis event by the E-SPONDER platform. The E-SPONDER platform sends a new crisis event request (e.g. a PUT HTTP request) to the active AS. The request is made using an “XML-schema”/ “JSON data object”-like structure [7]. The content of the initialization object is presented in Fig. 2. The example of Fig. 2 marks the beginning of a crisis event with a unique CrisisID. The data structure contains the hierarchy of the E-SPONDER participants for the specific incident. Thus, MEOC1 operates as the mobile operation center in the area, where FR team FRT1 will be deployed. The team consists of three members, FRU1 and FRU2 under the command of FRC1. The AS server listens to the crisis event, updates its database and initializes the SIP servers according to the E-SPONDER user requirements. More specifically, the

supported call requests under the E-SPONDER context are: i) a conference call among FR team members: The FRUs are able to communicate with each other and their commanding FRC, however they are not allowed to directly talk with other users; ii) a call between the FRC and MEOC or a conference call between the MEOC and multiple FRCs. The FRCs are not allowed to directly communicate with EOC; iii) a call between the EOC and MEOC or a conference call between the EOC and multiple MEOCs. EOC cannot directly communicate with the FR team. Certain SIP client software (softphones) instances are activated with the E-SPONDER user login. The basic softphone requirements are that they should be able to register to multiple SIP servers and support auto-answer. Under normal conditions: • the EOC user registers to the EOC SIP Server; • the FRUs and the FRC register to the local FR team server, as well as to the MEOC server. As long as the MEOC server is available, all call requests from/to the FR team are served by the MEOC server; • three VoIP clients are defined at the MEOC level. The 1st user is the Incident Commander (IC) with the ability to communicate with the deployed FRCs. Thus, the IC softphone registers to the MEOC server. The (optional) 2nd user is the MEOC 2nd in command with the auxiliary role to answer calls from the FRCs when IC is unavailable (also registered to MEOC). The 3rd client registers to the EOC server. This user (called MEOC-2-EOC user), answers/initiates calls from/to the EOC. Any softphone that covers the registration and auto-answer requirement can be used. Although the SIP client is used for user registration and audio processing, the SIP servers are not allowed to serve direct requests by the softphones, but only through the E-SPONDER platform. All other calls are rejected. 2) Call Procedure: In order to initiate and establish new calls, the following procedure is performed: 1) an E-SPONDER user interface (UI) software produces a specific call request addressed to the web services hosted by the AS. The UI may be a map service application for EOC/MEOC, or a push-to-talk interface at the FRUs. The request may be made with a POST HTTP request addressed to a RESTful web service [8] of the AS;

2) the AS performs the necessary checks. The set of functions of the application that performs the checks is called the control engine: i) all the specified users should be registered to a SIP server monitored by the AS, ii) based on the defined E-SPONDER hierarchy, it is checked whether the specific call is allowed or not, iii) the existence of a call with the same ID is checked. If an active call already exists, the call will be modified according to the request, else a new call will be initiated; 3) the AS requests from the SIP server the initiation of a new conference call among the participants. Even when only two participants are included in the request, a two-member conference call will be initiated. Thus a call modification request will require simple addition/deletion of members to the conference; 4) the SIP server accepts the request made by the AS and initiates a conference call with all the participants; 5) Since the SIP clients are set to an auto-answer mode, the call is accepted by the available users. If, for any reason, some participants are unavailable, the SIP manager will broadcast events containing this information; 6) the AS listens to the SIP events, determines the call status (successful, partially successful, failed) and publishes this information to other E-SPONDER applications. A schematic of the conference call establishment procedure between two peers is presented in Fig. 3a. Blue lines indicate the action sequence for a successful call and red lines the actions when failure occurs (rejected by the control engine/ unavailable participant). The termination of an existing call is performed using a DELETE request for an active call ID. FRUs have no right to reject/terminate a call from the FRC. 3) VoIP Subsystem Rules at the End-User: In this paragraph, the call procedure is examined as a flow diagram taking into account the E-SPONDER end-user requirements. A dialplan is needed to determine the actions when e.g. the FRC has an active call with MEOC and must also communicate with the FR team. In Fig. 3b, the flow diagram for all possible scenarios and outcomes, when MEOC initiates a call is presented. It is assumed that MEOC POST requests are published through a “click to call” functionality on a map service application. Similar flow diagrams are formed for the calls initiated from EOC or the FRC. Traversing the flow chart of Fig.4, all possible scenarios and outcomes can be met: •

•

•

MEOC IC selects FRCs to initiate a conference call. If all FRCs are occupied then the request goes to an ‘on hold’ state (sound message or alert to the occupied parties). If all or some FRCs are available, then a call is established. If some FRC(s) request to leave the conference call, the MEOC IC allows this action; it is noted that during a call between FRC and MEOC, if an FRC chooses to speak with the team, then the voice session with the MEOC IC falls to an ‘on hold’ state. After the termination of the FR team call, the MEOC IC call becomes active again; MEOC is always available for FRC(s) communication. This is done with the use of the dedicated VoIP softphone for MEOC-2-EOC connection to serve EOC-related VoIP

sessions. Generally, due to the required hierarchy, MEOC ICs should also communicate with the EOC Commander. This is achieved with call forwarding to the IC headset through the Audio/Video distribution system; • if during an active call, another FRC attempts to initiate a call with MEOC, the auxiliary VoIP softphone operated by the MEOC 2nd in command handles the call; • if, during an active call, the MEOC IC requests to add another FRC, the user is added to the conference. IV. S UITABLE C OMMUNICATION T ECHNOLOGIES The proposed architecture is composed of three network segments, namely i) EOC-MEOC, ii) MEOC-FRs teams and iii) the FRs TAN. Since security and reliability represent critical features for the communication between EOC and MEOC and the distance between them could span from few to several hundreds of kilometers as the MEOC has to be easily transferable and deployable in great distances from the EOC, an ideal solution is the use of a satellite bidirectional link which is capable to provide connectivity even if terrestrial telecommunication infrastructure (e.g., 3/4G) is unavailable or destroyed. The specific link has been implemented based on TCP Noordwijk transport protocol able to operate efficiently through this kind of communication channels. The optimal implementation for the MEOC-FR teams communication links is based on a Broadband Mobile Wireless (BMW) platform. There are several candidate Radio Access Technologies (RATs). Both Long Term Evolution (LTE) and High Speed Packet Access (HSPA) lack in terms of commercial maturity and ability to obtain a transmission license, due to the fact that the allocated frequencies to LTE have already been assigned to mobile operators and there is no sufficient spectrum to deploy ad-hoc networks without causing mutual interference. IEEE 802.16e WiMAX exhibits no major drawbacks; nevertheless, a relative scarcity of WiMAX enabled smartphones in the European market has been detected. Furthermore, the lack of highly deployed networks in EU area facilitates the license-obtaining procedure for WiMAX based communication networks from local authorities. V. Q UALIFIED I MPLEMENTATION A. Satellite Segment: the EOC to MEOC Communication Path The required data rate between each FRC and MEOC is 1.5Mbit/s and for a typical number of 3 TANs, the MEOC to EOC data rate exceeds 4.5Mbit/s. Based on these specifications, the selection for the MEOC-EOC data transmission path is the employment of a satellite link operating either in classical Ku-band or in the newly commercialized Kaband (26.5-40GHz). Predicting future bandwidth requirements for support of more TANs with higher data rate per FR, the selected satellite band is the Ka-band that enables the instant accommodation of more bandwidth. Furthermore, due to lower wavelength the antenna dimensions are noticeably smaller enabling easier installation on the MEOC roof. The weak point of this setup is the higher signal absorption by rain/ice. This drawback is bypassed with the selection of the appropriate terminal equipment with DVB-RCS and powerful coding and also with the use of higher EIRP than the required by the calculated link-budget.

Fig. 3.

a) The conference call establishment procedure

b) Dialplan scenarios and outcomes of VoIP calls initiated by the MEOC

B. Implementation of Incident Area Network (IAN) and TANs for FRs Communications In the E-SPONDER network abstraction, EOC supports multiple MEOCs – Incident Area Networks (IAN), which subsequently support multiple FR Teams – TANs. As described in Section 4.1 regarding the possible candidate technologies for IAN implementation, while both 4G technologies (LTE and WiMAX) can support the E-SPONDER requirements, only WiMAX can provide efficient and inexpensive operation in crisis situations when commercial communications are not available or congested (currently the cost for an ad-hoc standalone LTE network is extremely high). Mobile WiMAX [9], [10] also outperforms the latest HSPA releases in cost effective configurations. It can be configured as a Base Station (BS) with multiple sectors or dual carriers per sector for increased capacity and it can provide full coverage of the incident mounted on the MEOC vehicle roof. Mobility management is included to support FR Teams as they move across the WiMAX sections. Multiple Input Multiple Output (MIMO) transmission is provided either in Tx/Rx diversity or in spatial Multiplexing mode. The setup offers high QoS, scalability, and adjustable bandwidth. Moreover, it is compact, resilient, inherently secure, stand alone, fast deployable and cost effective. The objective of the common general architecture is to provide modular and flexible deployments that support customizable mobile operation. FR Team (TANs) connectivity uses a hybrid technique in order to be most flexible and convenient. In the presence of MEOC, the TAN is logically defined in the Application Layer. In this case, the coverage area is unified and the FRs are served by the WiMAX network, respecting at the same time the hierarchical structure of the operations. In the absence of MEOC, each TAN is physically defined by WiFi Access Points (APs) installed on the FR team SNs. The SNs serve a double purpose: They interconnect the members of each team, but also provide extended functionality (e.g. the FR team SIP server) for provision of advanced communication

services. SN operation enables both the realization of alternative routes and also ensures FR team communication in the absence of MEOC or BS coverage. In addition, it provides data processing resources for maximized network efficiency. The SN is implemented using inexpensive, small-sized singleboard computers. These devices (e.g. Raspberry Pi, [11]) are commonly used for Machine-to-Machine communications. 1) The Ad-hoc Mobile Broadband IAN: During a major crisis, the existing commercial communication infrastructure may be disabled or unavailable. Moreover, the existing infrastructure may not be able to support the E-SPONDER network traffic requirements because of limited resources or increased bandwidth demand by other users. Additionally, in case of an isolated, remote area, no coverage for wideband data services may exist. Therefore, the E-SPONDER platform should provide the network resources with the deployment of an ad-hoc BWM network installed in each MEOC providing coverage to the FR teams operating in the incident area. The network end-points are the user terminal equipment, i.e. mobile units – smart phones that in the one end communicate with the Personal Area Network (PAN) (e.g. body sensors, cameras, etc.) and in the other end they communicate with the MEOC BS. The BS is the actual end-point of the network infrastructure and it is able to detect terminals, implement all the protocol functions that will establish the radio link with the terminal (e.g. modulation, coding), exploit the radio channel resources and provide access to the network. If no large-scale ad-hoc deployment (MEOC) is present or the coverage is limited, TAN is implemented by a WiFi AP. In mobile high-speed data networks with cellular deployment, each BS is connected and controlled by a serving unit (Access Service Network Gateway (ASN-GW)) that provides advanced control, higher-level functions and also works as the gateway to the network (or other heterogeneous networks). Depending on the operational requirements, this entity may include features like data forwarding, location management,

Radio Resource Management (RRM), mobility management, handover control, RRM relaying, Authentication, Authorization and Accounting (AAA), Quality of Service control, admission control etc. These gateways are managed by the integrated E-SPONDER Core Service Network. Under the E-SPONDER context, each MEOC is equipped with one or more BSs (omnidirectional or sectoral coverage). These BSs are managed by an ASN-GW entity installed at each MEOC. This is necessary in order to create an adhoc, autonomous network with no dependence on a core network.Thus, the core network of the radio access network is kept minimal. However, the minimal core network functionalities should be also available directly to the MEOC, since it should be able to provide radio access even if the EOC is unavailable. The FR teams should be seamlessly served by the MEOC BS while user mobility should be supported by proper handover functions. However, due to the E-SPONDER hierarchy, each FR team is affiliated with a specific MEOC and thus seamless inter-MEOC handovers are not allowed. Based on the aforementioned analysis, the MEOC ad-hoc, broadband radio solution is based on the deployment of a small-scale WiMAX network. In order to implement a fully functional small-scale WiMAX network, the installation of the following network is required: (i) one (for omnidirectional coverage) or more (for sectorial coverage) BSs are installed at the MEOC, (ii) one ASN-GW that monitors the BSs, (iii) a communication server where the compact WiMAX core network is activated with the RADIUS AAA server [12] for secure and efficient connections and the Network Management System software for the configuration of the BSs and the ASNGW. The designed solution for base station and ASN-GW equipment that fits the E-SPONDER platform requirements covering all possible scenarios is the following: • two single-sector 2x2 all outdoor BSs at 2.5 GHz with all the needed IEEE 802.16e Wave 2 radio and modem equipment (carrier from 2485 to 2695 MHz with a 125kHz step); 5 and 10 MHz bandwidth profiles are supported. GPS with on-board synchronization unit is integrated; all modulation profiles (QPSK, 16-64 QAM) and MIMO techniques are supported in adaptive selection mode; Very low Rx sensitivity is achieved (−97 dBm @ 10 MHz); It is accompanied with sectoral Antennas with 15 dBi gain; • a pico ASN GW that supports up to 500 subcarriers. It is complied with the R4 and R6 WiMAX interfaces and it supports all the required authentication, IP allocation and accounting features. The ASN-GW enables the control of the available bandwidth for each subscriber and allows dynamic change of bandwidth based on the user demands. It provides application awareness since it can differentiate the service profiles based on the used applications that are used by each user (such as P2P, video, voice etc.); • Network Management System (NMS) installed at the MEOC server, to configure and monitor BSs and the ASN-GW. The NMS provides real time monitoring tools, performance tools, fault management services; • the modular and scalar FreeRADIUS server to provide AAA services. It fully supports RFC 2865 and 2866, EAP

(-TLS, -SIM, -TTLS, -MD5) and it is compatible with many known RADIUS and EAP clients. 2) The Ad-hoc TAN: The connectivity within the FRs teams is based on a hybrid architecture to provide flexible and adaptable coverage of all possible scenarios. Specifically, in the presence of MEOC, the TAN is logically defined in the application layer and all the corresponding parameters are determined centrally by the MOEC base station. The FRs are served by the WiMAX network that at the same time controls the hierarchical E-SPONDER structure. In the absence of MEOC, each TAN is physically defined by a local AP in the proximity of each FR team. Specifically, in the extreme case of limited coverage or MEOC absence, a credit cardsized SN is activated in order to facilitate the TAN network connection operating either as a WiFi AP or as a WiMAXWiFi bridge. Additionally, the SN is able to support a light SIP server enabling the voice communications among the FR team members in the absence of the MOEC or infrastructure availability. Furthermore, the SN unit has enough storage to back up the measurement data until the main network becomes operational and enough processing power in order to perform initial data processing of the sensor data (e.g. compress data and reduce the throughput requirements). The SN is carried by the FRC and it is characterized by its low power consumption. Such low cost commercial devices are the beagleBone, the pcDuino, the raspberry-pi [11], etc. VI. C ONCLUSIONS This work aimed at providing an emergency ICT infrastructure able to provide secure and reliable communication to first responders during any crisis event. The most suitable network topology and architecture have been identified and the necessary communication services for efficient responder coordination have been defined (the SIP protocol implementation is described). Finally, in this work we have provided the real implementation of ad-hoc communication networks. R EFERENCES [1] H. Miller, R. Granato, J. Feuerstein, and L. Ruffino, “Toward interoperable first response,” IT Professional, vol. 7, no. 1, pp. 13–20, 2005. [2] F. Yu, H. Tang, and V. Leung, “Qos provisioning in public safety radio and commercial cellular integrated networks for first responders and critical infrastructures,” in Performance, Computing, and Communications Conference, 2007. IPCCC 2007. IEEE International, April 2007, pp. 570–575. [3] M. Casoni, D. Saladino, A. Karagiannis, D. Komnakos, S. Sagkriotis, J. Wagner, N. Joram, and F. Ellinger, “An ad-hoc emergency network for crisis events,” in Future Network and Mobile Summit (FutureNetworkSummit), 2013. IEEE, 2013, pp. 1–12. [4] B. Goode, “Voice over internet protocol (VoIP),” Proceedings of the IEEE, vol. 90, no. 9, pp. 1495–1517, 2002. [5] A. Paganelli, D. Saladino, and M. Casoni, “QoS Performance Evaluation of Multimedia Services in Emergency Networks,” in Wireless Communications and Mobile Computing Conference (IWCMC), 2012 8th International, aug. 2012, pp. 933–938. [6] A. Johnston, SIP: understanding the session initiation protocol. Artech House, 2009. [7] “Json: The fat-free alternative to xml, 2011.” [8] L. Richardson and S. Ruby, RESTful web services. O’Reilly, 2008. [9] “Network working group stage 2 specification rel. 1.1., published by the wimax forum.” [10] “Network working group stage 3 specification rel. 1.1., published by the wimax forum.” [11] “The raspberry pi foundation.” [12] “C. rigney et al. remote dial-in user service (radius), ietf rfc 2865, june 2000.”