1 Introduction

Public protection and disaster relief (PPDR) organizations play a major role in disaster preparedness and recovery, assisting the response to emergency events. Typically, first responders that include law enforcement, firefighters, emergency medical personnel, and other organizations are among the first on the scene of an emergency.

In large natural disasters, military organizations can also support the response to the disaster. PPDR organizations are increasingly reliant on network infrastructures and services (e.g., video streaming, picture download, remote database applications) to perform their operational duties. Disaster management includes a set of tasks to reduce the impact and injury to individuals, mitigate the impact of the crisis on assets, provide support to injured civilians, and accelerate the time to recover the conditions of stability before the crisis. The presence of different organizations with different communication systems in a crisis scenario often creates interoperability issues during an emergency crisis as described in [1]. In the past, PPDR organizations have used voice services to perform their duties, but data connectivity is becoming increasingly important as highlighted in [2] to support various applications including the definition of a common operational picture (COP). A complete list of PPDR applications is out of the scope of this paper and the reader can refer to [3] to identify the current and future PPDR applications, which drive the need for data connectivity. Usually, data connectivity is classified in narrowband connectivity, which is limited to a data rate in the order of tens of kbits, wideband connectivity in the order of hundreds of kbits, and broadband connectivity from 1 Mbit and above. While narrowband connectivity is currently provided by PPDR wireless communication technologies like terrestrial trunked radio (TETRA)/TETRAPOL or APCO25, wideband connectivity may be provided by next generation PPDR standards like TEDS; broadband data connectivity as provided by long term evolution (LTE) is not currently available to PPDR organizations even if it is already available to commercial users [4]. In addition, natural disasters like floods or earthquakes may impact the existing communication infrastructure (both fixed and wireless) with the consequence that wireless communications may not be available to PPDR organizations in the area of the crisis and alternative solutions must be designed and deployed. A complete overview of the wireless communication technologies used by PPDR organizations (called radio access network or RAN in the rest of this paper) is provided in [5], with an analysis of the advantages and disadvantages of each technology as per the challenges described above. While in the rest of this paper, we will use the term RAN to indicate a wireless communication technology, we will focus on TETRA, worldwide interoperability for microwave access (WiMAX), and satellite communications technologies.

The concept of software-defined radio (SDR) has been initially investigated by Mitola [6] and it has been applied in the military domain in the Joint Tactical Radio System (JTRS) project ([7]) as a potential technology to address the interoperability barriers in the military domain. The main concept was to design a communication platform that could run different waveforms implementing specific communication standards. The objective is to have a single communication platform that could interoperate with the existing wireless communication systems in the battlefield. SDR devices include field-programmable gate array (FPGA), digital signal processors (DSP), general purpose processor (GPP), programmable system-on-chip (SoC), or other application-specific programmable processors. The use of these technologies allows new wireless features and capabilities to be added to existing radio systems without requiring new hardware. The JTRS program is based on the definition of a software communication architecture (SCA) [8], which is a software framework designed to facilitate the development of software waveforms and the concept of portability of waveforms across different hardware platforms. Even if the SDR concept was defined in the military world, the PPDR domain has similar operational requirements and challenges for mitigating lack of coalition interoperability. The business models for the military and the PPDR domains can be quite different, and the business feasibility of the deployment of SDR technologies is not in the scope of this paper. For additional information on the business feasibility and related challenges of SDR technology in the military and PPDR domains, refer to [9].

The application of SDR concepts to the PPDR domain has been investigated in the FP7 EULER (EU ropean SDR for wirele ss in joint secur ity operations) project as described in [10]. Project EULER has brought together a number of European industries and academia organizations to investigate the application of SDR for large international emergency crisis, where PPDR organizations and even military organizations can participate to the disaster management operations. While [10] has provided an overall view of the main concepts of the EULER project and its architecture, this paper provides a more detailed description of the design of the demonstration system with special focus on the provision of satellite communications (e.g., BLOS link) and on the results of the integration and testing activities.

This paper is also an extension of [11], which described the preliminary concepts of the EULER project and an initial description of the integration activity. This paper provides a much more detailed view of the design of the demonstration systems and the different scenarios (line of sight and beyond line of sight) where the demonstration system was integrated and validated.

This paper is organized as follows: Section 2 provides an overview of the related work in this area, in particular in the application of SDR and satellite communications for public safety operations. Section 3 presents the overall system architecture defined in the EULER project and its applicability to emergency scenarios. Section 4 is the main part of this paper and presents the integration and testing scenarios, which were used to validate the demonstration system. The scenarios include line of sight (LOS) with TETRA, beyond LOS (BLOS) with satellite communications, the Euler waveform (EWF) testing scenario, and finally the overall integration scenario, which combines all the previous scenarios. Section 5 describes the main challenges in the design, integration and testing of the demonstration system, and future developments. Finally, Section 6 concludes the paper.

2 Related work

The purpose of this section is to identify and describe related work in the area of software-defined radio and satellite communications for PPDR. In comparison to cellular networks, which are mostly implemented by a fixed infrastructure to transport signalling, voice, and data communications, satellite communications have limited dependency on the ground infrastructure, which is related to the management of the satellites or to the deployment of a gateway or ‘hub’ connected to the internet. Satellite communications can provide a very extensive coverage over a large area. This feature makes satellite communications very useful in specific crisis scenarios, like large natural disasters (e.g., earthquake, floodings), where other fixed-communication infrastructures are degraded or destroyed [12]. In addition, satellite communications can be used to support ad hoc networks in remote areas, where there were no wireless communication infrastructure in the first place. The integration between satellite and aerospace communication segments with terrestrial backbones is a key issue not only to provide continuous data connection but also assisted localization, which is essential in emergency relief [13].

There are various examples in literature of hybrid satellite and terrestrial system architecture for emergency mobile communications. One example is described in [14], which illustrates a mobile satellite system (MSS) coupled with an extension of 802.11 based on the Hybrid Wireless Mesh Protocol (HWMP). In the paper, the mobility of the rescue teams at the disaster site is considered one of the major requirements for the emergency communication system. This requirement is addressed by providing a mobility management function based on location management and handoff management, which are implemented using Proxy Mobile IPv6 (PMIPv6). In addition, the authors describe how this architecture can support self-healing of the ad hoc networks in case of failure of the nodes or propagation errors.

Other papers suggest the use of aerial platforms in combination with satellite communications and ad hoc networks at the ground level. One example is provided in [15], where the application of aerial base stations for disaster response is presented. The aerial base station (BS) can be installed on helicopters, air balloons, or airships, and it can be used to link one or multiple ad hoc networks on the ground to the satellite communications. The authors also presented a calculation of the path loss and the traffic capacity of the overall system. An interesting work dealing with the integration of aerospace segments and 4G terrestrial networks has been proposed by Zhao et al. [16]. The use of a low-medium-altitude aerial-platform-based time-duplex LTE system (i.e., Aerial-LTE) is considered in that work in order to increase the capacity for voice users in emergency scenarios. The radio resource allocation for uplink and downlink has been modeled as a cooperative game, whose target is to provide real-time voice communications to the possible largest number of users.

The combination of SDR technology and satellite communications is described in [17]. The authors describe the results from the Satellite-Assisted Localization and Communication systems for Emergency services (SALICE) project, where a reconfigurable NAVCOM device for satellite communications based on a SDR platform has been used. The authors correctly point out the benefits of the SDR technology to address the dynamic context of an emergency crisis, because new communication links or different modulation schemes can be used depending on the operational conditions. The authors in [17] indicate the main challenges for the implementation of the platform and present the results achieved during the SALICE project. In particular, the integration of the networking architectures and the coexistence and synchronization of the different communication systems used in the project were particularly complex. These challenges are also present in the demonstration system described in this paper. The SALICE project did not use SDR technology based on SCA unlike the EULER project. Indeed, the reconfigurable SDR-based terminal able at encompassing functionalities of assisted localization and data connection restoring has been emulated by means of the GNU-radio open source platform (see [18] for additional details and results).

An example of SDR platforms for satellite communications based on SCA is presented in [19] for the military domain. The paper describes a military satellite communication modem based on SDR and the SCA v2.2, which was specifically designed for the Skynet 5 system used by the UK and NATO armed forces. Even if the application domain is not related to PPDR, the paper addresses issues, which are also of interest to the PPDR community; in particular, support for interoperability for different wireless communication technologies and the provision of security functions (e.g., TRANSEC, INFOSEC, COMSEC).

Another more recent example of an emergency network project is the Rapid Emergency Deployment mobile Communication (REDComm) project [20]. The main target of the project is to build a communications infrastructure to support and handle communications in emergency and crisis situations, when standard communication networks are not available. REDComm is based on a flexible architecture with several mobile units which will communicate with the command center. The mobile units form a backbone wireless mesh network able to cover a large area providing an independent network for ubiquitous heterogeneous services (i.e., WiFi, GSM) and connect to emergency numbers (i.e., 112) to allow the responders to seek help.

While various papers have proposed satellite communications for PPDR or the application of SDR for satellite communications, this is the first paper (to the knowledge of the authors) which describes a demonstration system for PPDR organizations, which address interoperability barriers through an SDR platform based on SCA and supporting satellite communication.

3 System architecture

The overall architecture and the applicability to disaster management scenarios of the SDR-based network is shown in Figure 1. As described in the introduction, the underlying technology used in the EULER project is SDR, which is used to support the interoperability among conventional wireless communication technologies like TETRA, WiMAX, and satellite communications. This is achieved through a high data rate (HDR) waveform (WF) called EWF, which supports an internal LOS wireless network used to link the various conventional wireless communication technologies.

Figure 1
figure 1

Operational scenario and system architecture. This figure shows the operational scenario and the system architecture with the nodes and communication links.

Full size image

The system can be based on the following types of equipment:

  • Handheld terminals with limited processing capacity. These handheld terminals can be basic implementations of a wireless communication technology like TETRA, or they can be terminals implementing the Euler waveform even without SDR technology.

  • Vehicular terminals installed in PPDR vehicles (e.g., firefighters truck). Usually vehicular terminals have higher computing power and energy resources than the handheld terminals. They can act as a relay among various wireless technologies. In the case shown in the picture, they can act as a relay between TETRA terminals and the EULER backbone network connected by the EWF.

  • Nomadic terminals, which can be deployed in a fixed place and then moved to another place. PPDR satellite terminals are usually nomadic. Nomadic terminals can be based on a SDR platform able to connect to a satellite network on one side and to the EULER backbone network on the other side.

  • Base stations of a fixed network infrastructure to support and connect the other SDR nodes to fixed communications (e.g., fiber optics).

The PPDR organizations (e.g., remote healthcare, firefighters) can use terminals based on conventional communication technologies like TETRA and WiMAX. Note that WiMAX was the technology chosen in the project to support broadband connectivity related to the commercial domain [21]. Other alternatives are possible (e.g., WiFi or LTE). Through the base stations and conventional networks, users can connect to the fixed networks and then to the control centers like the crisis management center, PPDR head quarters (HQ), hospitals, and so on. Access to various RANs is implemented through the SDR nodes described above, while the EWFs are used to create the internal EULER wireless backbone network. The SDR base stations can be used to link the EULER wireless backbone network to a fixed IP network. The advantage of an SDR-based approach is its flexibility to support a wide range of RANs. If an SDR terminal is not initially equipped with a specific WF, it can download the WF through a data connection or through the EWF. Obviously, security aspects must be addressed to guarantee that the downloaded WF can be trusted and can be activated on the SDR terminal.

For the scope of the demonstration system, the public safety community is perceived to be TETRA based, which offers a low data rate, order of tens of kbits, and is used mainly for voice communications. Furthermore, security is a critical requirement during joint emergency operations between different PPDR organizations. The challenge is to provide seamless communications among entities equipped with different security technologies or sets of cryptographic keys.

In addition, the demonstration system also provides a spectrum-sensing capability. The spectrum-sensing function can be used to detect wireless interference in the area, which could affect the wireless communications used by PPDR organizations in the field.

The following platforms were designed and deployed in the integration scenarios.

  • Proteus platform developed by EADS Astrium (Portsmouth, UK): various models of the Proteus platform have been created. In this specific demonstration project, the model was based on a hardware configuration composed of a FPGA XCV28000 (Xilinx, San Jose, CA, USA), ADM-XRC-2 (Alpha Data, Edinburgh, UK), a Pentium (Intel, Santa Clara, California, USA) General Purpose Processor (GPP), and 16 bits ADC/DAC by Analog Devices (Norwood, MA, USA). The software configuration was based on Linux v2.6, TAO Object Broker complemented by EADS Astrium C++ libraries for the SCA framework.

  • Thales Internet Protocol BaseBand (IPBB) platform (Paris, France): the platform was based on a hardware configuration composed by GPP PowerQuicc II Pro (Freescale, Austin, Texas, USA) and the TI C64 DSP and ADC/DAC by Analog Devices. The software configuration was based on Linux/Xenomai and e*ORB and the SCA implementation by Thales.

In the following sections, we will describe more in detail the integration and testing scenarios of the demonstration system including the following:

  1. 1.

    The LOS communication with TETRA.

  2. 2.

    The BLOS communication with satellite communications.

  3. 3.

    Integration and testing of the Euler waveform.

  4. 4.

    Overall integration scenarios.

4 Integration and testing scenarios

4.1 Line of sight communication with TETRA

This scenario is focused on the validation and testing of the internal EULER wireless backbone network and the connection to a TETRA wireless communication system for LOS communication. The integration effort was performed in two steps.In the first step, a SDR node was connected to a TETRA network to perform a voice over IP (VoIP) communication. This test aims at validating that no significant latency in the communication path can disable the establishment or disturb the communication between the endpoint of the TETRA network (a TETRA terminal) and another terminal outside of the H.323 gateway. This other terminal is represented by a VoIP softphone. The overall configuration is presented in Figure 2 where the TETRA network is composed of one TETRA BS, two TETRA terminals (subscriber station (SS)), one H.323/TETRA gateway, one Gatekeeper, and a TETRA dispatcher. The gatekeeper manages a collection of H.323 devices; it converts phone numbers to IP addresses. The Gateway provides interoperability between different networks, and it translates between the telephony protocol and IP. The dispatcher handles all TETRA voice communications, such as individual, group, and broadcast calls in either duplex or semi-duplex mode as well as emergency calls. It comes with a multitude of data applications (e.g., short messages).In this step, the SDR node (represented as SDR-A in Figure 2) was the IPBB platform. Figure 3 shows the call in execution.In the second step, the LOS HDR was demonstrated for only a single BS with a pair of WiMAX mobile stations (MSs). In some cases, mainly due to the size of the system, MS could be designated as SSs. The data rates are in the order of several MBs, the nature of which is dependent upon scenario. For the purpose of the scenario, the application of video streaming was demonstrated, which requires at least several hundred kbps, which are much higher than data rate provided by TETRA release 1, whose data rate is in the order of several tens of kbps. Figure 4 shows the setup of the test-bed, where video streaming from a video-surveillance camera was used to validate the test-bed. Validation parameters included bit error rate (BER), jitter, and latency.

Figure 2
figure 2

LOS TETRA integration scenario. This figure shows the line of sight TETRA integration scenario.

Full size image
Figure 3
figure 3

TETRA dispatcher with call ongoing. This figure shows the TETRA dispatcher with the call already set up.

Full size image
Figure 4
figure 4

Test-bed for WiMAX with video streaming. Description of the test-bed for WiMAX with video streaming.

Full size image

4.2 Design and implementation of the (BLOS)

The second scenario was focused on the integration and validation of the system to provide BLOS communication or satellite communications using the combination of two SDR platforms: Proteus and IPBB, which are shown in Figure 5.

Figure 5
figure 5

SDR node with WiMAX base station. Image of the setup with SDR node and WiMAX base station.

Full size image

The Proteus platform can be supplied with a number of WF suites implementing different communication standards and modulation schemes. The various WF suites can provide different benefits: either high capacity (about 8.5 Mbps) with a frequency division multiple access (FDMA) WF or a highly resilient signal with code division multiple access (CDMA). The design of the Proteus platform requires that either HDR or high resilience can be obtained at a single point of WF calling or a combination.

The modulation and coding (ModCod) is modified in both FDMA and CDMA modes, which are implemented in the Proteus platform on the basis of the SCA framework to support the dynamic activation and reconfiguration of WF depending on the operational context. In particular, an Astrium SCA Implementation (ASI) has been used, developed with the main objective of optimizing the performance and resilience.

As in the LOS scenario, this scenario was also divided into separated integration and testing steps.

In the first step, the Proteus platform for satellite communications was tested for its resilience against failures in the wireless link. As written before, failures can be due to wireless interferences or obstacle in the line of sight. In the integration and testing activity, the Proteus platform was tested against wireless interference.The overall test-bed scenario is described in Figure 6, where Proteus nodes operate in L-band. The main components of the test-bed are the following: •Two SDR nodes based on the Proteus platform.

Figure 6
figure 6

Test-bed with SDR nodes to evaluate the mitigation of wireless interference. Description of the test-bed to evaluate the mitigation of wireless interference.

Full size image

  • A signal generator, which is used to generate wireless interference on a link between two Proteus nodes.

  • A spectrum analyzer to measure both the interference and the actual signal.

  • A satellite communications emulator to evaluate the performance (e.g., signal attenuation and delay).

  • Frequency references were used to support the synchronization of the SDR nodes.

  • Two laptops and video-surveillance cameras, which generate the video streaming used to test the capability of the system to support video services.

The combination of interferer and a satellite communications emulator is used to make the received signal contain the following:

  • Delay (typically in the order of several hundred milliseconds)

  • Attenuation

  • Interference

  • Additive white Gaussian noise (AWGN).

In the testing scenario, two SDR nodes establish a communication link in L-band in a conducted environment through a satellite emulator, which can reproduce realistic conditions of noise or doppler effects, which are present in satellite communications. At this stage, the signal generator is switched off or it does not generate a signal. The spectrum analyzer confirms the spectrum occupancy of the link between the SDR nodes. Then, video streaming is set up between the two laptops connected to the SDR nodes based on the Proteus platform. The quality of the connection is evaluated and recorded. Then a signal generator is used to generate wireless interferences on the conducted test-bed. The resilience of the SDR nodes and the waveforms were tested against different power levels of the generated interference signal.In a second step of the integration scenario, a WiMAX base station and terminals were added to the previous test-bed configuration to validate the capability of the systems to transmit traffic from the WiMAX terminal through the satellite communication. The overall test-bed is presented in Figure 7.

Figure 7
figure 7

One WiMAX system and satellite communication integration scenario. Description of the integration scenario with WiMAX and satellite communication.

Full size image

This test-bed may represent in an effective way a reach-back mode used in military communications where there is assumed to be a single crisis and the video content is beamed back, via satellite communications, to the localised head quarters.In the third step, the Proteus SDR nodes were used to support a communication bridge between two different WiMAX systems. The test-bed scenario is provided in Figure 8. In this scenario, two WiMAX BSs, four WiMAX SSs, and two Proteus nodes were used to support a video-streaming communication between the two video-surveillance cameras connected at the WiMAX SS endpoints of the network.

Figure 8
figure 8

Two WiMAX systems and satellite communication integration scenario. Description of the integration scenario with two WiMAX systems and satellite communication.

Full size image

4.3 Euler waveform

The final set of integration tests focused on the interoperability of Euler waveforms installed on different SDR platforms or the same SDR platforms (see Figure 9). The integration tests were executed on various test-bed configurations where 1. A baseband connection links the SDR nodes, the physical (PHY) layer is emulated, and the MAC layer is fully implemented.

Figure 9
figure 9

Euler waveform integration scenario. Integration scenario of the Euler waveform.

Full size image
  1. 2.

    A baseband connection links the SDR nodes, the PHY layer is fully implemented, and the MAC layer is emulated.

  2. 3.

    A baseband connection links the SDR nodes and both the PHY and MAC layers are fully implemented.

  3. 4.

    A radio-frequency connection links the SDR nodes where the PHY layer is fully implemented.

  4. 5.

    A radio-frequency connection links the SDR nodes where both the PHY and MAC layers are fully implemented.

This phase of the integration and testing of the demonstration system was the most challenging in the entire project. The scenarios 1, 2, and 3 were successfully executed without major issues and the network was able to support high data rate communication. In the scenarios 4 and 5 where the radio-frequency connection was used, synchronization between different types of SDR platforms hosting the EWFs has been achieved despite produced signal integrity degradation, which caused high bit error rates. As a consequence, it was difficult to achieve high data rate in all the user cases. As described in Section 5, the integration and synchronization of high speed rate communications (as provided by EWF) among different SDR platforms is the most challenging task in the realization of a final vision of a fully interoperable SDR-based network to support field PPDR operations. In addition, the integration tests were executed in the short time frame provided by the project time plan.

4.4 Network management services

The demonstration system is equipped with network management capabilities based on Simple Network Management Protocol (SNMP). A management information base (MIB) database was defined for the network and the various test case scenarios. The network management system was evaluated on a test-bed based on the combination of the WiMaX-based scenario and a service network with application servers, communication server, and monitoring servers. The overall setup is described in Figure 10 where the service-specific MIB elements and the platform/OS-specific MIB elements are highlighted.

Figure 10
figure 10

Network management services. Design of the network management services.

Full size image

4.5 Final integration

The final integration step was to integrate all the previous subsystems, test-beds, and application/services (including network management) to support the vision of a full interoperable network as presented in Section 3.The overall integration scenario is presented in Figure 11, where the EWF links are with the baseband configuration. It can be described as a composition of subsystems or main functional blocks interconnected by mean of network segments, wired or wireless, and having EWF backbone as the core network. The following EULER components have been identified and previously integrated before the final validation activity:

Figure 11
figure 11

Global infrastructure integration. Complete system integration scenario.

Full size image

  • Service network: includes all HW and SW elements providing both basic and specialized services/applications to the entire network.

  • EWF backbone: includes the set of SDRs porting EWF (BS and SS) which provides high data rate communication link and allowing subscriber stations to access the service network.

  • TETRA subsystem: This functional block is composed of an independent professional radio network operating with TETRA.

  • WiMAX subsystem: This functional block is composed of two independent WiMAX commerical off-the-shelf (COTS)-based networks, providing both high-speed data and voice access.

  • Satellite Communications (SATCOM) subsystem: This subsystem provides a SATCOM bridge through advanced SDRs to an external network of equipments, such as normal monitoring PCs and/or additional WiMAX COTS. This network benefits from the SATCOM link in order to provide external access and monitoring tools from a long distance area (like a headquarter) in order to allow full control of communication networks deployed on operational sites.

As for the EULER global integration scenario, ‘basic services’ are understood as all the services needed for network setup and operations, like global DHCP and DNS services needed to make all the terminals able to connect to the network in a seamless way. Once the appropriate network configuration has been designed and implemented in network nodes like routers and gateways, these equipments/applications were capable in propagating information about these basic services or relay these services themselves as they became part of the network. ‘Specialized services’ are intended to be added value services for back-end or front-end applications. A communication service able to provide centralized VoIP/video/messaging functionalities to users and/or groups of users was a mandatory building block for emergency communications; even HTTP services providing web pages or caching media content to be streamed on demand have been put in place for the validation of the scenario. The service network is also hosting a centralized management and monitoring service, at both network and application level. A web-based management console provides a user interface for network management in which information about network nodes equipped with SNMP agents can be shown. For ease of deployment, in EULER context, a virtual test lab has been made available by using a set of virtual machines (VMs) and virtual network interconnections, hosted by a single server.One deployment example of the global integration scenario is described in Figure 12, hosting specific applications and services, with the following VMs: •A VM running a CentOS operating system featuring ‘Application Server’ (EULER Server) hosting DHCP, DNS, HTTP, Samba, e-mail, and SSH services.

Figure 12
figure 12

Integration scenario with virtual machines. Description of the integration scenario with virtual machines and application servers.

Full size image

  • A VM running a Linux OS operating system featuring ‘Communication Server’, embedded with a SoftPBX for VoIP calls establishment, instant messaging (XMPP), and multimedia software (video).

  • A VM running a Linux OS operating system featuring a ‘Monitoring Server’, embedded with a centralized network monitoring service and its web console.

  • A PC running a Windows OS, able to display network status on a synoptic table through the web console of the monitoring server; the same PC, once equipped with a SW capable of VoIP calls, instant messaging and video communication was designed to act as a ‘Dispatch Centre’.

  • A network router to interconnect service network elements with the EULER backbone.

The following types of traffic and services were used to validate this scenario:

  • Network services: DHCP and DNS

  • Network tools (ping, traceroute, ARP)

  • Web browsing

  • SIP/H.323 audio communication

  • Video communication, video streaming, and multimedia web services

  • XMPP instant messaging and message dispatching

  • Network management system for configuration and monitoring of nodes and systems in the scenario.An integrated communication service for VoIP, video and call management, together with multimedia components has been developed and provided for the demonstration under the form of a server featuring Asterisk functionalities (limited to IP operations, no POTS, CAPI, or other trunks) mixed with messaging and dial plan configuration capabilities. VoIP/video/IM applications, each having addressing schemes/dial plans associated to them, can be provided under the form of SW installed on different laptops/desktop PC, each one finding place into the different segments of the EULER integrated network. In this integration phase, the EULER project has not tested the gateway to public switched telephone network (PSTN) systems to perform direct call to emergency numbers like the European 112 because the integration system was mostly VOIP based. Nevertheless, as seen in Figure 3, the TETRA gateway can also be used as a gateway to PSTN networks by selecting the related option in the gateway configuration screen.

For the video-streaming service, the integration activities did not include an evaluation of the performance of the system in terms of jitter or latency. The tests were considered passed when the video quality in term of quality of experience (QoE) was considered satisfactory and when the recorded delay was less than 500 ms on the SATCOM scenario.

In addition, various client applications were configured on the client terminal to evaluate the performance of the network:

  • Voice over IP application

  • SIP traffic with Ekiga, SJPhone, and X-Lite

  • Red 5 Flash™EULER Webphone

  • H.323 direct video call as options/plugin for application

  • Instant messaging

  • Multi-Generator (MGEN) which is developed by the US Naval Research Laboratory and provides the ability to perform IP network performance tests and measurements using User Datagram Protocol (UDP) and TCP IP traffic.

  • Video-streaming application

  • Email application

  • JPerf performance management tool.Below, we provide some examples of the execution of the tests and the related performance. Figure 13 shows the test using the JPerf performance management tool between two SDR nodes implemented on different SDR platforms.In Figure 14, the snapshot of the MGEN tool execution and the related command to send the traffic are presented. A MGEN server sends UDP packets from the TETRA gateway. The packets pass through IPBB SDR platform and an IP service. Then a MGEN client receives the UDP packets (sent by the server) on a Windows host. The purpose of the test is to check that, with a data rate to around 1 Mbit/s, all the packets are received by the IP service and the MGEN client. In one of the tests, a command is executed to send 1250 bytes for 100 times per second and this command is executed for 200 times.

Figure 13
figure 13

JPerf test. Results from the JPerf test.

Full size image
Figure 14
figure 14

MGEN tool screenshots and command. MGEN tool screenshots and commands.

Full size image

In other words, the achieved bit rate is 1 Mbit/s, and the entire test lasts 2 s. The video-streaming application was also based on a data rate of 1 Mbit/s.

5 Lessons learnt, identified challenges, and future developments

The design and integration of a demonstration system provides a really challenging framework to experiment new approaches on software development, inteoperability, and integration of SDR and conventional wireless communication technologies. Splitting the waveform design and development on independent modules and defining interfaces between demonstration systems in close collaboration has proven to be a feasible and working approach.

For developing separately EWF MAC, SEC, and PHY, defining accurately the MAC-PHY and MAC-SEC APIs and the processing behavior of each component are key factors for a successful integration later on.

The usage of a simulation environment preliminary to a waveform integration paves the way to target integration. In fact, simulation tools really help to hammer down misunderstandings and issues reducing integration risks. It is true that the differences of the simulation environment and the real operating environment need adjustment but the simulation environment step allows breaking down the overall integration in two levels: a) the initial integration to check the functional behavior and the interfacing between software components developed independently and b) target integration with real-time constraints. The positive experience of this approach can be reused as a working scheme to support the design of new SDR waveform developments.

6 Conclusions

The challenge in EULER was to design high data rate wireless networks suitable to integrate and make interoperable different communication technologies used in PPDR scenarios. In this specific project, an extension of the WiMAX standard has been used as a basis to define a waveform, which is installed in various SDR platforms and which can be used to support high data rate mobile ad hoc networks. A demonstration system has been built, integrated, and tested to validate its feasibility in various integration scenarios, which included support to conventional wireless communication standards like TETRA, WiMAX, or satellite communications provided by different companies. Others wireless communication technologies can be added and integrated in the scenario in the future. The scenarios included support both for LOS and BLOS communication through satellite communications. This latest scenario is particularly useful in disaster scenarios, because it can work independently of the conventional cellular infrastructure, which can be degraded or destroyed as a consequence of the natural disaster.

The EULER demonstration was a concrete illustration of deployment and interoperability of heterogeneous networks, although these networks weren’t designed initially to communicate with each other and come from different partners. The usage of SDR technology, matched to a common EWF, allows reusing the benefits of each network (e.g., group calls, data rate) and enlarging the connectivity between end-users. It’s an example of an interesting mean to extend services and respond to the customers in the public sector who are expected to be able to improve communications by using various services such as video surveillance and multimedia data transmission. Important benefits can be exploited from the approach described in this paper. The reuse of pre-existing networks is essential. The flexibility of networks can be an important advantage to support safety public interventions and the enlargement of communication infrastructures by the stakeholders involved in the operations of disaster response. Each participant of PPDR organizations has the possibility to use its own system of communications. But the need to cooperate together is a necessity. The deployment of the infrastructure can be progressive and depends on priorities, rules, and actions in parallel which confirm a need of flexibility in the systems of communication.

Technically speaking, it’s translated by a mix of heterogeneous communication standards but also by networks which have to be merged to offer the best and suitable QoS for the end-users. In this sense, the demonstration has shown a perfect feasibility and the potential of SDR technologies from different companies.

The integration scenarios were mostly successful, and the most significant problems arose from a lack of synchronization among different SDR platforms at the RF physical level. In this context, further work is needed to increase the robustness of the EWF SDR-based network against wireless propagation errors or lack of synchronization.

Further developments should include the support for LTE and satellite communications in various bands apart from L-band used in the demonstration system.

The SDR platforms have to be flexible and allow dynamicity in the PPDR operational scenarios, because resources can be dynamically allocated depending on the context. This is a very desirable feature in disaster management because PPDR officers in the field must face unexpected events and traffic demands, which are difficult to predict a priori. A useful exercise would be to deploy these technologies in real field scenarios. In this sense, this activity has already started because SDR-based technologies by some of the leading companies involved in the project are already used by PPDR organizations.