Sister Project

Report on Trials and Demonstrations
The current document provides an overview of available testbed configurations and satellite demonstrations and trials activities that have been conducted or are under execution as part of EU, ESA and National R&D programmes also including in-house R&D activities that are of interest to ISI. The document aims to provide a consolidated picture in the area of Satellite Communication Systems and Services and also to identify the areas where satellite demonstrations and trials activities need to be further conducted in order to actively promote and secure the commercial future satcom. This effort comes as a continuation of the ASMS-TF Report on Trials and Demonstrations that was released at the beginning of 2006.
December 2010
EXECUTIVE SUMMARY
The current document provides an overview of available testbed configurations and satellite demonstrations and trials activities that have been conducted or are under execution as part of EU, ESA and National R&D programmes also including in-house R&D activities that are of interest to ISI. The document aims to provide a consolidated picture in the area of Satellite Communication Systems and Services and also to identify the areas where satellite demonstrations and trials activities need to be further conducted in order to actively promote and secure the commercial future satcom. The current version of the ISI Trials and Demonstrations Report has been edited in the form of a living document. It includes a number of EU, ESA, National and In-House (by ISI members) funded R&D projects giving emphasis on the respective demonstrator part of Satcom. Specifically, the current version (v4.0) contains 18 project contributions supported by the following funding schemes: EC FP7 ICT project (1) EC FP6 IST projects (8) EC FP7 SECURITY project (1) EC FP6 SPACE projects (2) ESA ARTES projects (1) National funded projects (3) In-House R&D projects (2) The EGGS activity, performed as part of the EC FP6 IST project SATNEX, aimed at evaluating the performance of adequate protocol architectures, suited to transport data over interplanetary networks, by addressing most of the design challenges that may arise in this harsh Satcom environment. To this end, a distributed networking testbed, composed of remote emulation platforms, has been used, in order to develop a thorough analysis of all the aspects that require to be considered from the implementation point of view. The MULTESEM activity, performed as part of the EC FP6 IST project SATNEX, aimed at the design and set up of an effective tool to comparatively evaluate the proposed solutions in the Transport Protocols domain (TCP Hybla, TCP-Westwood, accelerators or PEPs, Delay/Disruptive Tolerant Networking (DTN), etc) in a controlled testing environment. The R&D project DVB-RCS Simulator/ Emulator undertaken in-house by the Univ. of Rome, Tor Vergata aims at the design and development of a powerful DVB-RCS simulator and emulator. Specifically, a DVB-RCS simulation platform was built on the satellite network extensions of the Network Simulator NS-2. The FT3 VoIP over Satcom activity, performed as part of the EC FP6 IST project SATNEX, aimed at studying the performances of VoIP protocols (SIP and H323) over a real satellite network. The developed testbed is made by two parts: the satellite network and the VoIP software. The VOTOS activity, performed as part of the EC FP6 IST project SATNEX, focused on the various congestion control protocol over satellite. The main issue was the analysis of the behavior of congestion control protocols over satellite networks, with particular attention to those systems that adopt the most recent Demand Assignment Multiple Access (DAMA) schemes, such as Skyplex Data, Amerhis, BGAN, etc. The WICHMO activity, performed as part of the EC FP6 IST project SATNEX, focused on wireless channel modelling issues. The scenario addressed consists of a hybrid network comprising a GEO satellite link and a wireless terrestrial link (Wi-Fi). As part of this activity, a testbed was developed
Page 1
in order to perform two main experiments: Indoor WiFi on Hybrid Network; and Outdoor Model for WiFi Packet Loss. The WISECOM project was co-funded by the EC under the FP6 IST Programme. It studied, developed, and validated by live trials candidate rapidly deployable lightweight communications infrastructures for emergency conditions (after a natural or industrial hazard). The system integrates terrestrial mobile radio networks - comprising GSM, UMTS, WiFi, and optionally WiMax and TETRA - over satellite, using Inmarsat BGAN and DVB-RCS systems, uses lightweight and rapidly deployable technologies, and incorporates location-based services. The infrastructure is intended to cover immediate needs in the first hours and days after a disaster event, as well as medium to longer term needs, during the recovery and rebuilding phase following an emergency. The SFEDONA project is co-funded by ESA, as part of ARTES 3/4 Telecom Products Programme. It deals with the design, development, validation and demonstration of a complete fire detection and alerting application which makes use of state-of-the-art technologies in fire detection (based on terrestrial optical cameras and environmental sensors), data fusion, satellite and wireless communications as well as modern IT technologies. The NETADDED project is an Integrated Project co-funded by the European Commission as part of the Aeronautics and Space priority of the Sixth Framework Programme (FP6). It has consolidated a 13 participant Consortium as active player in bridging the Digital Divide in INCO countries. The NETADDED project objectives are two-fold: (i) Development objective: to support education & health development in Africa & Asia; and (ii) Technical objective: to provide a sustainable technical solution adapted to the specific environment. The SISTER project is an Integrated Project co-funded by the European Commission under Framework Programme 6 (FP6). The SISTER project brings together major players from the ITS, space and services industries in a consortium consisting of 20 partners. The project promotes the integration of satellite and terrestrial communications with GALILEO to enable mass market takeup by road transport applications. It addresses the ITS and SATCOM markets by better understanding the needs of both. The TANGO project is an Integrated Project co-funded by the European Commission as part of the IST priority of the Sixth Framework Programme (FP6). It focuses on the use of satellite communications to serve the needs of the whole GMES community by addressing key environment and security applications in domains such as marine services and emergency response including risk & crisis management and humanitarian aid. The objectives of TANGO are to develop, integrate, demonstrate and promote new satellite telecom services dedicated to GMES requirements. The R&D project Satellite-WiFi Handover Simulation undertaken in-house by the Univ. of Rome, Tor Vergata aims at the development of an NS-2 based simulator in order to simulate the handovers between DVB-RCS satellite and WiFi networks. The Cross-Layer IPsec activity, performed as part of the EC FP6 IST project SATNEX, deals with network security issues and particularly focuses on the definition of a Cross Layer-IPsec Authentication Header protocol. The EMERSAT project, funded by the Italian Space Agency (ASI), deals with satellite solutions for applications and communications services to national institutional agencies dedicated to security and emergency management. The main contribution of the presented work to this project is the emulation of heterogeneous satellite-terrestrial networks to support emergency based on the use of the Satellite Tool Kit (STK) and the integration of other simulation/emulation tools. The INTERSECTION project is a Collaborative Project co-funded by the European Commission in the context of FP7 ICT area and, particularly, under the "Secure, Dependable and Trusted
Page 2
Infrastructures" sub-programme area. The main contribution of the presented work to this project is the design of an intrusion system based on a satellite network architecture dealing with attacks exploiting PEP vulnerability. The MOVISAT project is a Spanish R&D project funded by the Spanish Ministry of Industry, Trade and Tourism, through the Plan avanz@ programme, and aiming at the study of the hybrid satellite-terrestrial technologies. It considers mainly DVB-SH and ETSI-SDR standards and its main objectives include: study of network and devices related technological aspects; new business cases; regulatory aspects (at national and EU level); adoption and contribution to standards; definition of new applications; development of testbeds and validation tests of standards. The SALICE project is an Italian national R&D project, which aims at identifying the system architecture and the solutions that can be adopted in the future integrated reconfigurable NAV/COM systems and analyzing their feasibility in realistic emergency scenarios. In particular, the integration between self-organizing space segments (satellite, HAPs) and terrestrial segments (UMTS, TETRA) in a single network infrastructure is investigated in order to provide telecommunication facilities for an efficient emergency situation management. Reconfigurable SDR based terminals having NAV/COM capabilities are also addressed. The E-SPONDER project is a large-scale IP project funded under the FP7 in the call SEC2009.4.2.1: First Response of the future. It started on July 2010 and has duration of 48 months. It addresses among others satellite communications, which play a vital part. Particularly, satellite provides the backbone communications that facilitate the availability of local awareness (from the operation theatres) to any given and remotely-located EOC (emergency operation centre). As such, satellite communications are of paramount importance and play a vital role within the ESPONDER project.
Page 3
List of Contributing Projects
# 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Project Acronym SATNEX JA2410 EGGS ACTIVITY SATNEX JA2410 FT5 MULTESEM DVB-RCS Simulator/ Emulator SATNEX JA2410 FT3 VoIP over Satcom SATNEX JA2410 FT4 VOTOS SATNEX JA2410 FT1 WICHMO WISECOM SFEDONA NETADDED SISTER TANGO Satellite-WiFi Handover Simulation SATNEX JA2240 Cross-Layer IPsec EMERSAT INTERSECTION
Supported by EC FP6 IST EC FP6 IST In-house R&D EC FP6 IST EC FP6 IST EC FP6 IST EC FP6 IST ESA ARTES EC FP6 SPACE EC FP6 SPACE EC FP6 IST In-house R&D EC FP6 IST ASI (Italy) EC FP7 ICT Spanish Ministry of Industry, Trade and Tourism
URL www.satnex.org www.satnex.org
www.satnex.org www.satnex.org www.satnex.org www.wisecom-fp6.eu telecom.esa.int www.netadded-project.eu www.sister-project.org www.teladnetgo.eu
www.satnex.org www.asi.it/en/activity/telecommunications/emersat_ http://www.intersection-project.eu
16
MOVISAT
http://www.movisat-pse.info/
Page 4
17
SALICE
Italian Ministry of University and Research EC FP7 SECURITY
http://lenst.det.unifi.it/salice/
18
E-SPONDER
http://www.e-sponder.eu
Page 5
Acknowledgements
The editors would like to thank the European Commission for their support through the FP7 ICT Support Action sISI (Support action to Integral Satcom Initiative) - Grant Agreement No.: 215134. Also, the editors would like to thank all contributing authors: AZNAR-ABIAN Veronica (EADS Astrium) BARKER Trevor (Avanti Communications) BELLI Francesco (Univ. of Rome, Tor Vergata) BERIOLI Matteo (DLR) BOUTRY Philippe (EADS Astrium) CAINI Carlo (Univ. of Bologna) CAMAS Antonio (Rose Vision) CASONI Maurizio (University of Modena and Reggio Emilia) DE COLA Tomaso (DLR) DEFEVER Sophie (EADS Astrium) DEL RE Enrico (University of Florence) FERRO Erina (CNR-ISTI) LUGLIO Michele (Univ. of Rome, Tor Vergata) MULERO CHAVES Javier (DLR) PANTAZIS Spiros (Space Hellas) POTORT Francesco (CNR-ISTI) ROSETI Cesare (Univ. of Rome, Tor Vergata) SAVONE Gianluca (Univ. of Rome, Tor Vergata) THOMASSON Laurent (EADS Astrium) TJADER Mats (Avanti Communications) ZAMPOGNARO Francesco (Univ. of Rome, Tor Vergata) ZAPATA MARGEL Mara (EADS Astrium)
Konstantinos LIOLIS, ed. (Space Hellas) Ilias ANDRIKOPOULOS, ed. (Space Hellas)
Page 6
Table of Contents
1. 2. Introduction ......................................................................................................................... 14 Project SATNEX JA2410 EGGS ...................................................................................... 15 2.1 2.2 2.3 2.4 3. 3.1 3.2 3.3 3.4 4. 4.1 4.2 4.3 4.4 5. 5.1 5.2 5.3 5.4 6. 6.1 6.2 6.3 6.4 7. 7.1 7.2 7.3 7.4 8. 8.1 Overview ....................................................................................................................... 15 Testbed Description....................................................................................................... 16 Trials and Demonstrations ............................................................................................. 17 Results .......................................................................................................................... 19 Overview ....................................................................................................................... 20 Testbed Description....................................................................................................... 20 Trials and Demonstrations ............................................................................................. 22 Results .......................................................................................................................... 25 Overview ....................................................................................................................... 26 Testbed Description....................................................................................................... 27 Trials and Demonstrations ............................................................................................. 30 Results .......................................................................................................................... 31 Overview ....................................................................................................................... 34 Testbed Description....................................................................................................... 34 Trials and Demonstrations ............................................................................................. 36 Results .......................................................................................................................... 39 Overview ....................................................................................................................... 41 Testbed Description....................................................................................................... 41 Trials and Demonstrations ............................................................................................. 42 Results .......................................................................................................................... 44 Overview ....................................................................................................................... 45 Testbed Description....................................................................................................... 46 Trials and Demonstrations ............................................................................................. 46 Results .......................................................................................................................... 49 Overview ....................................................................................................................... 50
Project SATNEX JA2410 FT5 MULTESEM...................................................................... 20
Project DVB-RCS Simulator/Emulator ............................................................................ 26
Project SATNEX JA2410 FT3 VoIP over Satcom ........................................................... 34
Project SATNEX JA2410 FT4 VOTOS ............................................................................. 41
Project SATNEX JA2410 FT1 WICHMO .......................................................................... 45
Project WISECOM ............................................................................................................ 50
Page 7
8.2 8.3 8.4 9. 9.1 9.2 9.3 10. 10.1 10.2 10.3 10.4 11. 11.1 11.2 11.3 11.4 12. 12.1 12.2 13. 13.1 13.2 13.3 13.4 14. 14.1 14.2 14.3 14.4 15. 15.1 15.2 16. 16.1
Testbed Description....................................................................................................... 50 Trials and Demonstrations ............................................................................................. 51 Results .......................................................................................................................... 61 Overview ....................................................................................................................... 63 Testbed Description....................................................................................................... 64 Trials and Demonstrations Results ................................................................................ 66 Project NETADDED ...................................................................................................... 75 Overview ....................................................................................................................... 75 Testbed Description....................................................................................................... 75 Trials and Demonstrations ............................................................................................. 77 Results .......................................................................................................................... 84 Project SISTER ............................................................................................................. 85 Overview ....................................................................................................................... 85 Testbed Description....................................................................................................... 86 Trials and Demonstrations ............................................................................................. 88 Results .......................................................................................................................... 94 Project TANGO ............................................................................................................. 95 Overview ....................................................................................................................... 95 Trials and Demonstrations ............................................................................................. 96 Project Satellite-WiFi Handover Simulation ............................................................. 111 Overview ..................................................................................................................... 111 Testbed Description..................................................................................................... 112 Trials and Demonstrations ........................................................................................... 113 Results ........................................................................................................................ 114 Project SATNEX JA2240 - Cross-Layer IPsec .......................................................... 118 Overview ..................................................................................................................... 118 Testbed Description..................................................................................................... 119 Trials and Demonstrations ........................................................................................... 120 Results ........................................................................................................................ 121 Project EMERSAT - Emulation of heterogeneous networks for emergency .......... 123 Overview ..................................................................................................................... 123 Testbed Description..................................................................................................... 123 Project INTERSECTION- Satellite Network Protection ............................................ 125 Overview ..................................................................................................................... 125
Project SFEDONA ............................................................................................................ 63
Page 8
16.2 16.3 16.4 17. 17.1 17.2 17.3 17.4 18. 18.1 18.2 18.3 18.4 19. 19.1 19.2 20. 21.
Testbed Description..................................................................................................... 126 Trials and Demonstrations ........................................................................................... 128 Results ........................................................................................................................ 130 Project MOVISAT ....................................................................................................... 132 Overview ..................................................................................................................... 132 Testbed Description..................................................................................................... 132 Trials and Demonstrations ........................................................................................... 136 Results ........................................................................................................................ 150 Project SALICE .......................................................................................................... 151 Overview ..................................................................................................................... 151 Testbed Description..................................................................................................... 153 Trials and Demonstrations ........................................................................................... 158 Results ........................................................................................................................ 162 Project E-SPONDER .................................................................................................. 163 Overview ..................................................................................................................... 163 Testbed Description..................................................................................................... 163 Framework for Future Work on Trials and Demonstrations ....................................... 165 Conclusions ................................................................................................................... 169
Page 9
List of Figures
Figure 1: Diagram sequence for the four investigated scenarios. .................................................. 18 Figure 2: Congestion window diagram over TCP segments. ......................................................... 18 Figure 3: Received datagrams vs. time for the DTN/TCP trial. ...................................................... 19 Figure 4: Testbed physical layout. ................................................................................................. 21 Figure 5: Example of analysis: segments sent, cwnd and ssthresh curves. Hybla, CNIT Skyplex channel, no background traffic. .............................................................................................. 23 Figure 6: Short time goodput for PEPsal (a), Hybla (b), Sack (c), BIC (d), Vegas (e), Westwood+ (f) and Westwood (g) during the connection lifetime; a UDP spike perturbation starts at 60 s lasting 10 s. Averaged results. ............................................................................................... 24 Figure 7: Average time requested by some of the tested TCP variants to recover from the UDP perturbation............................................................................................................................ 25 Figure 8: DVB-RCS Reference scenario ....................................................................................... 26 Figure 9: Simulator architecture .................................................................................................... 28 Figure 10: Conceptual Emulator Architecture ................................................................................ 29 Figure 11: Real Emulator Layout ................................................................................................... 30 Figure 12: Sequence Number of a TCP transfer ........................................................................... 32 Figure 13: RTT samples -VBDC.................................................................................................... 32 Figure 14: Throughput evaluation - RBDC .................................................................................... 33 Figure 15: CNIT satellite network architecture. .............................................................................. 35 Figure 16: VoIP testbed architecture. ............................................................................................ 35 Figure 17: VoIP: bandwidth occupancy, G.711u codec. ................................................................ 36 Figure 18: Bandwidth Probability Density Function of H.263 Video Codec. ................................... 38 Figure 19: Jitter levels of GSM Audio Codec. ................................................................................ 38 Figure 20: Jitter levels of H.263 Video Codec. .............................................................................. 39 Figure 21: VOTOS testbed overview. ............................................................................................ 42 Figure 22: Performance of different TCP flavours over the Skyplex platform. ................................ 42 Figure 23: Start-up behaviour of Linux TCP over the Skyplex platform. ........................................ 44 Figure 24: The hybrid network experimental scenario ................................................................... 45 Figure 25: Indoor terrestrial segment. Tx in room 66, Rx in rooms 73 and 71. .............................. 46 Figure 26: Fitting several frame loss models with the measured traces. ........................................ 47 Figure 27: Path loss model. .......................................................................................................... 48 Figure 28: Signal reception model. ................................................................................................ 49 Figure 29: System Architecture ..................................................................................................... 50 Figure 30: The BGAN WAT Hardware .......................................................................................... 51 Figure 31: DVB-RCS WAT (simulating the green tent area). ......................................................... 53
Page 10
Figure 32: WiMAX client in the Rescue Team Car. ....................................................................... 54 Figure 33: Arrival of the chief emergency physician and other rescue forces (red cross and fire brigades) at the simulated disaster area. ............................................................................... 56 Figure 34: Red Cross staff is unfolding the equipment for the treatment area. As the weather was good, the green tents were not deployed. .............................................................................. 56 Figure 35: Deployment of the WISECOM Access Terminal (WAT) close to the victims area by two rescue force staff members. ................................................................................................... 57 Figure 36: Installation of the local Location Based Service (LBS) Control Centre in the red tend. 57 Figure 37: Assessment of the victim status by the emergency physician. ..................................... 58 Figure 38: Comparison of the cardboard tag on the left and of the electronic tag on the right. Note that the electronic tag includes the GPS position of the patient, accurate time stamp, and is transferred instantaneously to the Control Centre(s). ............................................................. 59 Figure 39: Once the specified victim (red triangle) has been found, the ambulance team updates the status of the victim to in transit and the triangle turns into a dot. This information is updated simultaneously on all PDAs and in the Control Centers. ........................................... 60 Figure 40: Patient being carried out of the explosion area to the collection area. .......................... 61 Figure 41: Victims are being treated at the collection area to be prepared for transportation to the hospital. A second triage is performed at this stage. .............................................................. 61 Figure 42: Burnt area extracted in Greece by Envisat MERIS FR ................................................. 63 Figure 43: SFEDONA System Architecture ................................................................................... 65 Figure 44: SFEDONA DVB-RCS Satcom Network Architecture .................................................... 66 Figure 45: Deployment of RCU and RDCU#1 sub-systems co-located at End User site ............... 68 Figure 46: Deployment of RDCU#3 sub-system at End User site.................................................. 69 Figure 47: Deployment of RDCU#3 metallic enclosure boxes at End User site ............................. 69 Figure 48: Deployment of ZigBee environmental sensor in the forest area of End User site ......... 69 Figure 49: Initiation of artificial smoke event with the use of smoke producers. ............................. 70 Figure 50: Users console GUI indicating users notification on fire/smoke alarm. In particular, flashing icon of detected fire event as well as RDCU vision sensor image data over the respective area under alarm are depicted. ............................................................................. 72 Figure 51: Users console GUI indicating users notification on fire/smoke alarm. In particular, panoramic camera stream over the respective area under alarm is depicted, where the artificial smoke source is clearly visible. ................................................................................. 73 Figure 52: Users console GUI indicating fire propagation prediction simulation. ........................... 73 Figure 53: NETADDED validation sites ......................................................................................... 76 Figure 54: NETADDED application domains ................................................................................. 76 Figure 55: Transportable terminal and its foldable solar charger ................................................... 78 Figure 56: Validation of the transportable solution in real operational conditions ........................... 78 Figure 57: ELU (Easy Line Up) user guide interface ..................................................................... 79 Figure 58: ELU test topology ......................................................................................................... 79
Page 11
Figure 59: Remote control system ................................................................................................ 80 Figure 60: Remote control hardware solution ................................................................................ 80 Figure 61: Wireless sensor prototype ............................................................................................ 81 Figure 62: SLOT test topology in Allier (France) ........................................................................... 81 Figure 63: Satellite network monitoring tool................................................................................... 82 Figure 64: Performance comparison of videoconferencing tools ................................................... 83 Figure 65: SISTER Architecture .................................................................................................... 87 Figure 66: SISTER Satellite Transceiver and Integrated Antenna. ................................................ 88 Figure 67: SISTER eCall concept. ................................................................................................ 90 Figure 68: Inside the SISTER test vehicle .................................................................................... 92 Figure 69: Demonstration route in Noordwijk ............................................................................... 93 Figure 70: The list of TANGO demonstrations ............................................................................... 96 Figure 71: Some pictures of the Cahors demonstration................................................................. 97 Figure 72: Overview of Satellite Telecommunication solutions role and use in the demonstration. 98 Figure 73: Fire Brigade team of SDIS 46 in preparation for the demonstration run........................ 99 Figure 74: Use of CTSP to select satellite solutions adapted to crisis management needs ........... 99 Figure 75: Overview of different transportable stations: MOBIDICK, RECOVER, TRACKS in the aerodrome of Cahors/Lalbenque.......................................................................................... 100 Figure 76: Use of Satellite for communications and GMES dissemination .................................. 100 Figure 77: Vessel Detection System ........................................................................................... 101 Figure 78: The Astra2 connect antenna ...................................................................................... 102 Figure 79: The company Louis Dreyfus Armateurs allowed two vessels to be volunteers to be tracked by LRIT ................................................................................................................... 103 Figure 80: Vessel traffic displayed by CLS combining AIS and LRIT ........................................... 104 Figure 81: Ship detection Radarsat image ............................................................................... 104 Figure 82: Detection of pollution Envisat Image ....................................................................... 104 Figure 83: First scenario map...................................................................................................... 106 Figure 84: Second scenario map ................................................................................................ 106 Figure 85: Photo in Vietnam ........................................................................................................ 107 Figure 86: Deployment of ELISEO .............................................................................................. 108 Figure 87: Display of Geographical Information System (GIS) .................................................... 109 Figure 88: Local command centre ............................................................................................... 110 Figure 89: Display of Geographical Information System (GIS) .................................................... 110 Figure 90: Mobile environment .................................................................................................... 113 Figure 91: TCP standard behavior .............................................................................................. 115 Figure 92: Instantaneous throughput from WiFi to Satellite link ................................................... 116
Page 12
Figure 93: Instantaneous throughput from Satellite to WiFi link ................................................... 117 Figure 94: Cross-Layer (CL) protocol stack and related services ................................................ 119 Figure 95: Testbed description .................................................................................................... 120 Figure 96: Partial authentication using CL-IPsec in transport mode ............................................ 121 Figure 97: Video Packet Loss rate with IPsec and CL-IPsec ....................................................... 121 Figure 98: Frame of video streaming test with MPEG-2 and BER=10-5 ....................................... 122 Figure 99:Threat exploiting PEP-related vulnerability .................................................................. 126 Figure 100:IDS for PEP-related vulnerability ............................................................................... 128 Figure 101: Testbed configuration ............................................................................................... 129 Figure 102: Track of the SYN detector records ......................................................................... 130 Figure 103: Tracks of the TCP traffic analyzer records ............................................................. 131 Figure 104: Mode DVB-SH-A ...................................................................................................... 133 Figure 105 : Mode DVB-SH-B ..................................................................................................... 134 Figure 106: Laboratory Setup - Test-bed .................................................................................... 135 Figure 107: Block diagram, DVB-SH A mode .............................................................................. 135 Figure 108: diagram, DVB-SH B mode ....................................................................................... 136 Figure 109: SALICE Baseline Scenario....................................................................................... 152 Figure 110: N-Gene Block Diagram ............................................................................................ 155 Figure 111: Universal Software Radio Peripheral (USRP) ........................................................... 157 Figure 112: Integration of NAV/COM Systems in SALICE Terminal ........................................... 158 Figure 113: SALICE Demonstrator .............................................................................................. 159 Figure 114: Compatibility Test: Testbed Scheme ........................................................................ 160 Figure 115: Synchronization Test: Testbed Scheme ................................................................... 161 Figure 116: Emergency Network Architecture ............................................................................. 164 Figure 117: Logical schema of the proposed MEOC testbed ...................................................... 164
List of Tables
Table 1: MOS rating with different codecs and UDP interfering traffic. .......................................... 36 Table 2: VoIP QoS parameters. .................................................................................................... 39 Table 3: FWI values calculated for different meteorological conditions.......................................... 71 Table 4: Main outcomes on transportable terminal usage in Burkina Faso .................................... 77 Table 5: Possible Synergies among the Listed Projects .............................................................. 165 Table 6: Possible Future Demonstration Scenarios across Relevant Segments ......................... 167
Page 13
1.
INTRODUCTION
The current document provides an overview of available testbed configurations and satellite demonstrations and trials activities that have been conducted or are under execution as part of EU, ESA and National R&D programmes also including in-house R&D activities that are of interest to ISI. The document aims to provide a consolidated picture in the area of Satellite Communication Systems and Services and also to identify the areas where satellite demonstrations and trials activities need to be further conducted in order to actively promote and secure the commercial future satcom. This effort comes as a continuation of the ASMS-TF Report on Trials and Demonstrations that was released at the beginning of 2006. The current version of the ISI Trials and Demonstrations Report has been edited in the form of a living document, disseminated to the ISI Community and is also available for download from the ISI website (http://www.isi-initiative.eu.org/). The work presented in this report has been conducted as part of the FP7 ICT Support Action sISI (Support action to Integral Satcom Initiative) - Grant Agreement No.: 215134.
Page 14
2.
PROJECT SATNEX JA2410 EGGS
2.1 Overview
SatNEx (Satellite Network of Excellence) and its extension SatNEx II are two Network of Excellence (NoEs) funded by EC within FP6 program. In this framework, a particular attention is devoted here to the activities performed within WorkPackage (WP) 2400, titled Research Trials, Tools, and Testbeds. In short, the goal of this workpackage is to promote and organise collaborative cooperations among SatNEx-II partners, aimed at investigating different SatCom domains by means of research tools properly designed for the scope and through the ideation of effective test beds suitable for the sake of the experimentation. Some details about the Joint Activity (JA) 2410, titled Access, Network and Transport Layer Trials belonging to this WP are given here. In particular the EGGS activity, satellitE networkinG in challenginG environments is focus on. Remote measurement operations, habitat, and environmental control tasks in interplanetary scenarios give raise to challenging issues, in particular in the design of communication protocols. Many peculiarities characterise interplanetary networks: large propagation delay, multi-path fading, solar wind, and other hostile radiofrequency conditions that impact on the channel performance. Additionally, because of celestial motion, the line of sight is not always available. The results are channel disconnections (expected or not), and high bit error rates (ranging from 10-3 to 10-2). For these reasons TCP/IP is not the best candidate. Alternative solutions are Delay Tolerant Network (DTN) and protocol architectures proposed by the Consultative Committee for Space Data Systems (CCSDS protocols), or customized flavours of TCP. Given such a wide choice of possibilities, implementing each single protocol is not tractable; especially if we consider that some of these proposals are still under development, hence permanently evolving. Testing over real testbeds belongs to the future. An experimental tool, which makes possible to use protocols already implemented, without the costs and complexity of real testbeds is thus strongly needed. In particular, the EGGS experiment is aimed at evaluating the performance of adequate protocol architectures, suited to transport data over interplanetary networks, by addressing most of the design challenges that may arise in this harsh environment. To this end, a distributed testbed, composed of remote emulation platforms, has been used, in order to develop a thorough analysis of all the aspects that require to be considered from the implementation point of view. In more detail, attention was mainly paid to the networking issues, by pointing out the advantages offered by the design of such a prototype. The overall scenario is composed of: An Earth station responsible for collecting data originated by a remote sensor network; A sensor network located on a remote planet surface;
A satellite orbiting around the remote planet, serving as relay point between the planet and the Earth. The presence of different satellite links together with the sensor network makes the use of a single platform impractical. The integration of different emulation tools is strongly required in order, on the one hand, to distribute the whole network complexity among several components and, on the other hand, to control the granularity aimed at characterising the peculiarities of each network portion. It is possible to individuate two kinds of links: A proximity link, established from/to the remote planet and the satellite orbiting around; A long-haul link, providing the data communication over the deep space path.
Page 15
Besides, the necessity to dedicate specific tools for each considered interplanetary link (proximity and long-haul) was motivated by the very different characteristics in terms of delay, bandwidth and packet loss patterns.
2.2 Testbed Description

The integrated testbed is characterized by a long-haul satellite link emulator (called ACE), a sensor testbed (SENS), and a proximity satellite link emulator (DUMMYNET). In more detail, ACE was located by the University of Genoa, SENS by ISTI-CNR institute and DUMMYNET was available at GET/ENST (Groupe des Ecoles de Tlcommunications Ecole Nationale Suprieure des Tlcommunications) premises in Toulouse. The tools were virtually integrated by means of 2 IP tunnels set between SENS and ACE, and between ACE and DUMMYNET respectively. Different tools are used for the long-haul and proximity links because the requirements inferred by the environments are not the same. The long-haul link. Concerning ACE, its basic aim is to emulate a network environment composed of a set of Earth stations that communicate through a satellite link. Its extension towards interplanetary communications is straightforward. It can emulate the data communication among an Earth station, responsible for gathering data arriving from the remote sensor network, and a satellite platform orbiting around the remote planet. Under this view, it is possible to think of these terminal agents as PCs connected to each other by means of an emulated satellite link, working as follows. The whole system is composed of three devices, hosting a Linux O. S., whose role is to perform the basic functionalities of data forwarding and to fully characterise the transmission channel. For this purpose, the emulation task is performed at the data link layer, in order to take into account frame formats, channel coding schemes and proper physical layer characteristics, such as propagation delay, channel bandwidth availability and statistical behaviour of the satellite link (e.g., in terms of bit error ratios and channel modelling). The proximity link. As far as the proximity link emulation is concerned, it takes the Dummynet Free BSD kernel extension as reference. It allows tuning the propagation delay, the bandwidth availability and the link reliability (e.g., random, uniform loss of packets) through the application of proper schemes and policies implemented at the IP layer. The sensor network. The sensor testbed consists of a set of Micaz motes from Crossbow Inc.. They are equipped with an 8 MHz microcontroller, an IEEE 802.15.4 compliant radio and transducers to sample light, temperature, acceleration, magnetism and audio. The embedded software implements a distributed database management system where relational algebra operators, including selection, projections and joins can be carried out on the nodes and interconnected via data stream channels. Users draw the layout of a query graphically and interactively via a GUI application. The query layout concisely represents all data sampling, data processing and data transfer activities to fulfil on each of the network nodes. The GUI interacts with the remote sink via a TCP connection for both sending commands and receiving sensor data. The experimentation core is based on running queries with a variable number of sampling nodes (during the initial tests, it ranges from one to three) and applying different sampling rates (from 100 ms to 2000 ms). The measurements, which typically involve light variations, are properly processed by the sensor network and encoded to allow their transmission to the sink node, which, in turn, relays them to the GUI. The three components (ACE, DUMMYNET and SENS) described before are located at different premises (Genoa, Toulouse and Pisa). In order to link the three sites, a VPN topology is established with the advantage to make the use of a private addressing plan possible. The drawback of this distributed approach is the natural delay introduced by the Internet: it has to be taken into account. A Perl script repeatedly measuring the RTT helps to adjust the delay as needed.
Page 16
2.3 Trials and Demonstrations

Two scenarios are considered: (a) full-TCP and (b) DTN/TCP. In the former, the sensor network GUI is located on the Earth and a TCP connection is established with the sensor network sink. The TCP connection therefore goes over the long-haul link with the expected limitations of TCP. In the DTN/TCP scenario, the sensor network is connected to the orbiter via a TCP connection (proximity link). A DTN/TCP proxy in the orbiter translates sensor data sent from the sink into DTN bundles and forwards them via UDP to the Earth. The DTN/TCP proxy is written in Perl. The DTN stack is the reference implementation available from the DTN Research Group. The sampling rate of the sensor network for the DTN scenario is set to 10 measures per second while it is twice that value for the full-TCP scenario. A measure is approximately 25 bytes. The current implementation of the DTN stack has difficulties to sustain high rates and issues a threading runtime error. Finally, all network links are constrained to a throughput of 64 Kbit/s. The propagation delay for the long haul link ranges from 125 ms to 200 s. The proximity link has a propagation delay of 40 s. Measures are collected in the Earth station (i.e., in Genoa), being tcpdump used to record traffic traces. Currently, bit errors are not taken into account in the experiment, although they can be generated by the two link emulators if needed. The full-TCP scenario. As far as the full TCP scenario is concerned, particular attention has been paid to the impact of large latencies on the transmission protocol. To better understand this aspect, and hence to assess the operation of the proposed emulation platform, different propagation delays have been considered for the long haul link (250 ms, 1280 ms, 10 s, 50 s and 200 s). We first tested the behaviour of TCP when the largest propagation delay (200 s) is set. This trial showed, as expected, the unfeasibility of using TCP protocols over very long networks, due to the TCP timers and related algorithms tuned to the more common terrestrial path delays. To tackle these problems, TCP parameters have been tuned accordingly to the environment peculiarities. Trials with delays equal to 250 ms, 1280 ms, 10 s and 50 s have been successfully completed, while the case of 200 s still experienced some hazards, because of the limits of the TCP back-off algorithm triggered during timeout expirations. Figure 1 and Figure 2 (Geo and Moon configurations refer to delays of 250 ms and 1280 ms respectively) show the behaviour of instantaneous packet transmissions and congestion window over the elapsed time and the TCP segment number, respectively. These graphs confirm that the long haul link propagation delay impacts the dynamics of data transfer changes. In particular, Figure 1 demonstrates that for a 250 ms delay, the transmission of TCP segments follows a quasilinear law. On the other hand, as delay increases, the time interval required to transmit the same amount of data gets larger. In particular, it is possible to see that for delays of 1280 ms and 10 s, an initial phase where the number of transmitted segments over time keeps low, because of the slow-start phase. Afterwards, the congestion window is almost regular as one may infer from Figure 1, and confirmed by Figure 2. The case of 50 s deserves more attention. Figure 1 shows that the number of segments sent out over time increases very slowly because of the very large latency. Actually, a comparison with the other configurations shows that the time required to transmit about 150 Kbytes is 5 times larger and nearly equal to 1100 s. Similar considerations still hold also for the congestion window behaviour plotted in Figure 2, which shows a stepwise shape in the case of 50 s delay. This confirms that, in presence of very large bandwidth-delay product networks (as it may happen in interplanetary networks), TCP solutions are not efficient, since the increase in the congestion window is too conservatively ruled by the TCP acknowledgment arrival, which results in long idle times in these scenarios.
Page 17
Sequence Diagram
160 Geo-250 ms Moon-1280 ms 10 s 140 50 s
120
Data Transmitted [Kbytes]
100
80
60
40
20
0 0 200 400 600 Time [s] 800 1000 1200
Figure 1: Diagram sequence for the four investigated scenarios.
Figure 2: Congestion window diagram over TCP segments. The DTN/TCP scenario. The DTN/TCP experiment deploys the bundle protocol over the long haul link. UDP was selected as a subnetwork, in order to work around issues related to the impairment of conversational protocols over very long networks. Figure 3 shows the received UDP datagrams with respect to time. The results related to the 200 s experiment display an interruption in the reception of the UDP flow due to buffer overflow occurred at the long-haul emulator. This event was an indirect consequence of the very large latency that caused long buffer queues on the ACE platform. This behaviour is further amplified in long-run simulations that give rise to buffer overruns, as highlighted in this case.
Page 18
Apart from this critical case, the other configurations with large delay (e.g., 50 s and 10 s) show the benefits of the DTN architecture implementation. In fact, Figure 3 shows that the number of received packets over time linearly increases almost independently of the propagation delay; the curves related to delay configurations of 50 s and 10 s, respectively, nearly overlap and, besides, they even keep really close to the delay configuration of 250 ms (reported as geo.dat). Being congestion control procedures based on feedbacks missing, the main difference exhibited in this case with respect to TCP employment is that bundle rate transmission keeps approximately constant regardless of the investigated environments physical characteristics.
Figure 3: Received datagrams vs. time for the DTN/TCP trial.
2.4 Results
The experiments, achieved by means of the integrated and distributed testbed, showed that the adoption of a DTN-compliant stack allows overcoming impairments typical of interplanetary environments, in terms of very large propagation delays. In particular, the superiority of this solution was checked over traditional TCP/IP protocol suite. In this light, the results showed that in some case TCP-based protocol are neither able to establish data connection because of the large propagation delay; on the contrary DTN architecture, built on Bundle Protocol facilities, is able to ensure delivery of data also in presence of very harsh condition, independently of the experienced latencies.
Page 19
3.
PROJECT SATNEX JA2410 FT5 MULTESEM
3.1 Overview
SatNEx (Satellite Network of Excellence) and its extension SatNEx II are two Network of Excellence (NoEs) funded by EC within FP6 program. In this framework, a particular attention is devoted here to the activities performed within WorkPackage (WP) 2400, titled Research Trials, Tools, and Testbeds. In short, the goal of this workpackage is to promote and organise collaborative cooperations among SatNEx-II partners, aimed at investigating different SatCom domains by means of research tools properly designed for the scope and through the ideation of effective test beds suitable for the sake of the experimentation. Some details about the Joint Activity (JA) 2410, titled Access, Network and Transport Layer Trials belonging to this WP are given here. In particular Focus Topic 5 (FT5), MULTESEM (TEstbeds for Satellite Emulation) is focused on. The challenges exhibited by satellite communications, in terms of large bandwidth-delay product and link errors, have been thoroughly explored over the last decade. In addition, the extension of this environment including also wired and wireless links, has fostered the scientific community towards the definition of a large number of transport protocols and architecture solutions tailored to this larger scenario. Here, we limit ourselves to cite TCP Hybla and TCP-Westwood as transport protocols, even if this could be further extended. An alternative approach, widely adopted in satellite environments, is represented by accelerators or PEPs (Performance Enhancing Proxies), which basically rely on the introduction of intermediate agents at transport layer. In a future perspective, the Delay/Disruptive Tolerant Networking (DTN) architecture may represent an interesting solution not only for deep space communications, but also for the most challenging satellite networks. Given this complex context, it is paramount to design and set up effective tools to comparatively evaluate the proposed solutions in a controlled testing environment. For this purpose, CNIT and the University of Bologna (UoB) decided to integrate their assets and expertise to realize the UCIT (University of Bologna CNIT Integrated Testbed) common testbed platform for performance evaluation at the Transport layer. Here, we focus on the description of this testbed, referring, whenever necessary, to the configuration recently used to carry out a series of joint experiments in cooperation with the Network Research Lab at UCLA Computer Science Department.

Satellite connections are composed of wired legs and a final satellite link, while TCP background traffic is present only in the entirely wired paths. All the TCP variants available in the Linux kernel are supported as well as the FreeBSD implementation of Westwood (directly provided by UCLA). The satellite link can be realized either by emulation or by means of any real satellite system, as done in the joint UoB-CNIT-UCLA measurement campaign, where the Skyplex platform was exploited. Finally, the testbed allows the user to assess the performance of alternative solutions, based on satellite accelerators or on the DTN architecture. To describe in more details the testbed components, let us refer to the much more complex physical layout of the testbed, in the configuration used during the recent joint experiments campaign (Figure 4). The following components can be distinguished: a testbed controller, located at UoB; the UoB TATPA testbed (Testbed on Advanced Transport Protocols and Architecture), temporarily relocated in Genoa,
Page 20
a TCP satellite receiver (one Linux PC) in Naples and the CNIT Skyplex GEO satellite platform, which links the testbed core with the satellite receiver. We will examine the main components separately.
Figure 4: Testbed physical layout. The controller, connected to the TATPA core via a Virtual Private Network, allows the user a ubiquitous remote control of the testbed via a standard web browser. A dedicated PC hosts the web server and the control software engine, developed in PHP and based on a MySQL database. The aim of the TATPA web interfaces and management control system is to facilitate the shared use of the testbed. In particular, they allowed us to hide the software and hardware complexity related to the configuration, synchronization and utilization of all testbed elements. Moreover, the web controller provides an increased level of security, as users cannot access testbed components directly, and greatly speeds up both test execution and result collection. The TATPA core consists of several PCs running the Linux operating system (kernel 2.6.20), and a PC running FreeBSD, which is directly maintained by UCLA. Multi-TCP on Linux senders implements the full version of TCP Hybla (including packet spacing and Hoe's initial ssthresh estimation) and introduces powerful log functions, essential for an in-depth analysis of results. In particular, they allow to retrieve meaningful indications about the TCP dynamics, by capturing the values of the internal TCP variables (e.g., congestion window cwnd, slow start threshold ssthresh and retransmission timeout RTO) It is worth noting that the internal TCP variables are extracted directly from the kernel core, since common traffic analysis tools (e.g., tcpdump) cannot derive values of TCP variables.
Page 21

Owing to the features offered by the aforementioned three components of the testbed, a user is allowed to specify and run tests aimed at assessing the performance of TCP/UDP traffic flows and, alternatively, of DTN architecture applied over heterogeneous satellite networks. The tests consist in transferring data for a time duration specified by the user at the beginning of the trials. Transfer of data is managed by the testbed core transparently to the user and performed by means of either Iperf or DTNperf tools, in dependence on the specific protocol architecture under investigation. After collecting results through the integrated testbed, they have to be processed and carefully examined, in order to draw general conclusions not only about the effectiveness of different solutions, but also about the mechanisms that lead to different performance. To this end, the capacity of analyzing also the internal TCP variables is instrumental. To show the features offered by the integrated testbed, let us consider the example given in Figure 5, which refers to a TCP Hybla file transfer of 200s, on the CNIT-Skyplex channel, in absence of background traffic. The time sequence of the segments sent, together with the cwnd and the ssthresh dynamics are given in Figure 5. All the data were collected by the log-functions of the MultiTCP package and successively made available by the web interface. From Figure 5, meaningful information about the dynamics of this TCP variant under study can be inferred. Let us start from the analysis of the cwnd, which reflects the enhanced congestion control algorithm introduced by Hybla. Aiming at removing the penalization due to long RTTs, it allows a fast opening of the cwnd even on a long propagation delay GEO satellite channel (RTT larger than 600 ms). Losses determine cwnd reduction according to the Linux rate halving algorithm, which instead of halving the cwnd, gradually reduces it during the Fast Recovery phase. TCP retransmissions during the recovery phase are indicated by Tx segments with a sequence number lower than previously transmitted segments. The relatively long burst of retransmissions present in the Tx time sequence are likely indicators of buffer overflows. At the end of loss recovery phase, the cwnd rapidly increases, thanks to the Hybla enhanced congestion control, until new loss events are detected. Hybla ssthresh dynamics is also reported in Figure 5,. In correspondence of loss detection events the ssthresh is set to half of packets in flight. After the recovery phase conclusion, the cwnd is increased following the Hybla slow-start or congestion avoidance laws, depending on the relative values of cwnd and ssthresh.
Page 22
3.0E+07 Tx segments
1800
Tx sequence number (bytes)
2.5E+07 cwnd 2.0E+07
1500
cwnd, ssthresh (segments)
1200
1.5E+07
ssthresh
900
1.0E+07
600
5.0E+06
300
0.0E+00 0 50 100 Time (s) 150
0 200
Figure 5: Example of analysis: segments sent, cwnd and ssthresh curves. Hybla, CNIT Skyplex channel, no background traffic. Figure 6 and Figure 7 present a short selection of obtained results. In this case one satellite TCP connection runs for 180s. After the start-up phase is closed (about 60s), an UDP spike perturbation on the wired path (cross-traffic) starts and lasts for 10s, transmitting at 9.5 Mbit/s. This way, we effectively reduce the available bandwidth on the R1-R2 link to 0.5 Mbit/s, of the satellite bandwidth. The aim of the test is to investigate the capability of the satellite connection to react to the perturbation.
Page 23
2000
2000
1500
Goodput (kbit/s) Goodput (kbit/s)
1500
1000
1000
500
500
a) PEPsal
0 0 30 60 90 Elapsed Time (s) 120 150 180 0 0 30 60 90 Elapsed Time (s) 120
b) Hybla
150 180
2000
2000
1500
1500
1000
1000
500
500
c) SACK
d) BIC
150 180
2000
2000
1500
1500
1000
1000
500
500
e) Vegas
f) Westwood+
150 180
2000
1500
Goodput (kbit/s)
1000
500
g) Westwood
0 0 30 60 90 Elapsed Time (s) 120 150 180
Figure 6: Short time goodput for PEPsal (a), Hybla (b), Sack (c), BIC (d), Vegas (e), Westwood+ (f) and Westwood (g) during the connection lifetime; a UDP spike perturbation starts at 60 s lasting 10 s. Averaged results. Figure 7 shows the short time goodput, calculated by adopting a sliding window of 10 s and by subsequently averaging over the three consecutive experiments. Results show the superior agility of PEPsal, Hybla, and BIC. The same conclusions are supported by, which depicts the time requested to fully recover from the UDP perturbation (i.e. the time requested by the short time goodput to recover the value assumed at perturbation beginning), for the tested TCP variants.
Page 24
50.0% 45.0% 40.0% 35.0%
Penalization
30.0% 25.0% 20.0% 15.0% 10.0% 5.0% 0.0%

PEPsal Hybla SACK BIC Vegas West+ West
Figure 7: Average time requested by some of the tested TCP variants to recover from the UDP perturbation.
3.4 Results
The powerful facilities provided by the UCIT testbed revealed fundamental to investigate the performance analysis of several TCP version over real satellite segments. In particular, a complex scenario configuration, including both terrestrial and satellite connections provided insights into TCP performance when congestion events are likely to happen also on terrestrial links. Furthermore, the performed trials on the field allowed to identify the performance key factors influencing behaviours of different TCP versions, as shortly reported in the previous sections. Finally, the integrated testbed resulted an excellent means for investigating performance provided by higher layer protocols, not limiting itself just to TCP. It is available to the SatNEx members and in general to the whole satellite community.
Page 25
4.
PROJECT DVB-RCS SIMULATOR/EMULATOR
4.1 Overview
This project refers to in-house R&D work performed internally at the University of Rome "Tor Vergata". The reference model for a DVB-RCS network is shown in the Figure 8. The network topology is a star network with the GW station as hub.
Figure 8: DVB-RCS Reference scenario The GW transmits a forward carrier towards all STs. The STs, in turn, share a channel towards the GW according to a Demand Assignment Multiple Access (DAMA) protocol. The GW typically provides access to the Internet and/or to a corporate network. STs cannot communicate directly with each other, but some systems allow double hop connection via the GW. DVB-RCS bandwidth management is asymmetric. In the forward link a TDM scheme is used. This is managed by the GW, and the way the available bandwidth is shared between concurrent flows is an implementation issue. Typically, the GW maintains several FIFO queues with different priority. In the return link, bandwidth is shared between STs according to a DAMA scheme. This study considers 3 types of bandwidth allocation: CRA (Constant Rate Allocation) is a fixed allocation, available permanently to an ST irrespective of whether it is used. VBDC (Volume Based Dynamic Capacity) is dynamically allocated on request of the ST. The request is for a given volume of data. Each request is a one-off request for a given volume, and requests are cumulative. The time between issuing the request and getting the allocated bandwidth is typically in the order of 1.5 seconds, but may vary from one system to another depending on the details of the frame structure and the precise allocation algorithm. The standard supports also an Absolute VBDC (AVBDC) scheme in which requests are absolute rather than cumulative, typically used to cope with potential loss of requests. In our analysis we will refer only to VBDC.
Page 26
RBDC (Rate Based Dynamic Capacity) is dynamically allocated on request of the ST. The request is for a given data rate and is typically valid for some seconds, being updated by subsequent requests as required. The extra delay of the request/allocation cycle is only felt on the initial request for RBDC, and on requests that modify the requested rate. The impact of dynamic allocation on RTT is therefore less severe than for VBDC. Some systems support a fourth type of bandwidth allocation: FCA (Free Capacity Assignment). Any bandwidth not used for fulfilling requests is split between STs in some way. This feature is not included in our study. It requires knowledge of, or assumptions about the total traffic in the channel, and its effect is therefore unpredictable from the viewpoint of a single or a few STs. We felt that including it would bring little benefit, and would make interpretation of results more difficult, having one more parameter to cope with. From a performance point of view, the 3 types of allocation can be described as follows: CRA has a constant RTT of around 500 ms for a geostationary satellite channel. Bandwidth is reserved whether or not it is used. Any unused bandwidth is wasted. VBDC has a much longer RTT, typically around 1.5 seconds, due to the request/allocation cycle. Normally, capacity will only be requested for data that is already in the buffer, so the bandwidth utilization is 100%. RBDC has an RTT similar to CRA, except some extra delay on first request and on adjustment of requested rate. The bandwidth provided will rarely match precisely the bandwidth needed, so some bandwidth will be wasted most of the time, but less than for CRA. Most implementations offer combinations of two, or all three of the allocation schemes. The precise algorithm for requesting and granting VBDC and RBDC is not part of the DVB-RCS standard, and it is difficult to get information of the details of implementations. So we had to make some assumptions. VBDC is rather straightforward, and there are not many choices available. RBDC, on the other hand, is much more open to different algorithms. We chose a relatively simple model based on a sliding average of recent traffic demand. It is our understanding that VBDC is intended for best effort traffic like TCP, while RBDC is intended for stream traffic that has more or less constant bandwidth requirements over extended time periods. We will discuss in the conclusion whether these expectations are met.

4.2.1 Simulation Platform A DVB-RCS simulation platform has been built on the satellite network extensions of the Network Simulator Ns-21. The reproduced scenario models a star-based architecture where multiple Satellite Terminals (STs) are connected to a satellite gateway (GW), including the Network Control Centre (NCC) functionalities, through a geostationary bent-pipe satellite node. The configuration scripts also allow for intra-segment mobility simulations, where a mobile node detaches from a satellite node and attaches to a wireless node, simulating a simplified Mobile IP architecture. In addition, a new module for DVB-RCS MAC layer has been implemented in the satellite stack. All the DAMA schemes envisaged by the standard are supported (i.e., CRA, RBDC, VBDC) as well as
1
http://www.tlcsat.uniroma2.it/DAMA
Page 27
their possible combinations (i.e., mixed CRA-VBDC). The structure of the implemented DAMA model is represented in Figure 9, mentioning names of the new agents/classes introduced. In Figure 9, it is also detailed a possible path for data IP packets (plain arrows) and messages exchanged at MAC layer (dashed arrows). MAC signaling is not crossing the satellite link, but it is part of the same MAC NS2 instance. Nevertheless satellite delays are accounted internally to simulate the real signaling latency.
Figure 9: Simulator architecture Encapsulation of packets in MPEG is not performed, together with a simplified TDMA framing, not compromising results obtained. A vast gamut of statistics (graphs or data files) can be obtained as simulation output through TCL scripts. In particular, such outputs can be divided into three categories: 1. Lower layer statistics these concern allocation dynamics at the MAC layer a. System Response Time measurements time elapsing between a capacity request and the corresponding allotment; b. Traces of the allocated slots per superframe in the different DAMA disciplines; c. Calculation of the saturation time- time at which the maximum allowed transmission rate is achieved (significant for TCP long transfers). 2. End-to-end statistics a. Round Trip Time (RTT); b. Throughput 3. TCP statistics monitoring of the evolution of TCP internal variables: a. Congestion Window (cwnd) and Slow Start threshold (ssthresh) trends; b. Packet sequence Numbers; c. Trace of the retransmissions. 4.2.2 Emulation Platform
Satellite emulator has been conceived and developed to reproduce in real-time the services and quality of service of a DVB-RCS satellite network, while some network impairments (e.g., end-to-
Page 28
end delay) are reproduced in software. The Emulator core is composed of 5 units. Every unit-PC emulates a single component of a typical VSAT satellite environment, with DVB-RCS or DVB IP and terrestrial return channel. In particular, PCs represent: 1. Gateway/Hub (SatGW); 2. Satellite (SAT); 3. Satellite Terminal (ST); 4. Two User Terminals (UT1 and UT2) Figure 10 shows the PCs logical interconnections and the provided interfaces. Specifically, emulator provides the interface for a wireless extension in order to integrate satellite segment with other real or emulated wireless systems. With reference to Figure 10, UT2 is interfaced to a WiFi access point, behind which a WiFi network is configured. Furthermore, emulator platform can be accessed via a Web graphical interface. In this way, a remote users dislocated along Internet can configure a target satellite scenario, run tests, and collect statistics.
Figure 10: Conceptual Emulator Architecture
The hardware equipments involved in the emulator are shown in Figure 11.
Page 29
Figure 11: Real Emulator Layout
Software modules have been developed over Linux OS in order to take advantage from the Open Source strategy. The kernel used is version 2.6.20, which offers a large set of functions for classifying and scheduling network traffic, IPsec support and a large set of transport protocols including UDP-Lite and new variants of TCP (i.e., TCP Hybla, TCP Westwood+, TCP Veno, TCP Low-Priority). Finally, DAMA functionalities rely on the same algorithms implemented on the NS-2 simulator and work intercepting traffic from ST (or multiple virtual STs), managing a queue at application layer (ip_queue), delivering requests on a dedicated channel via an UDP socket and finally processing packets according to DAMA allocation decisions on IP packet basis with a strategy close to TDMA adopted in real DVB-RCS systems. The emulator proved good performance even without emulation of lower layer mechanisms (e.g. TS encapsulation). Performance analysis on the Emulation platform can be done using classic network analyzer tools (e.g. Wireshark/Ethereal).

Emulator platform has been used and/or extended in the frame of two main research projects:
Page 30
1.
The project EMERSAT (See Section 15) - funded by the Italian Space Agency (ASI), which has the objective of developing, integrating and validating a pre-operative model for communication services for emergency management. In this frame, above emulator has been extended to provide a demonstrator of the target services. The project INTERSECTION (See Section 16), which is a collaborative project cofunded by the EC under FP7 ICT.
2.
4.4 Results
DAMA exploitation introduces a significant delay in addition to the already high propagation delay of the satellite link, and is affects significantly the behavior of TCP data transfer. This effect is present on both data traffic directions, but it is less evident on the forward link data transfer, because in this case the return link (where the DAMA mechanism is implemented) handles small packets corresponding to TCP acknowledges (ACKs) and has small rate variations. A common slot size in the DVB-RCS return channel is a multiple of an ATM cell, so that each ACK just requires at maximum a single slot. Data packets for TCP transmission are usually bigger and require a greater amount of slots, implying greater allocation variations since the DAMA algorithms work under competition and resource constraints. In this paper only data transfer on the return link is dealt with. The first test concerns the measure of a single TCP connection sequence number evolution in both emulated and simulated approach for TCP Reno and TCP Vegas over DAMA RBDC (Rate Based Dynamic Access) access scheme. Figure 12: Sequence Number of a TCP transfer shows that with the two approaches the same results are carried out and that performance are significantly different for the two TCP flavors. In fact, TCP Vegas clearly suffers from bad estimation of available bandwidth due to the high variability of perceived RTT in a DAMA system. Figure 13 shows RTT variations as a function of time for a TCP Reno connection over DAMA with VBDC (Volume Based Dynamic Access) both in the emulated and in the simulated environment. Although the match is not perfect, the overall behavior is similar, with a common average RTT of about 1.5 s. Figure 14 shows the throughput for TCP Reno connection evaluated both through simulation and emulation. The results from the two approaches are close in average and represent quite well the real system behavior. Oscillations peaks on the Linux line are above the system capacity because of buffering at MAC layer not included in the TCP dump performed at the source, but the average throughput is compliant with the system capacity set at the beginning. With the aim to optimize TCP performance in such environments, the examined tests are important also to identify the criticalities of the DVB-RCS system. In particular, for classic TCP congestion control algorithms the initial growth of the transmission window is inefficient in the startup phase, even with high ssthresh as it is actually in Linux PC (and consequently set in NS2 too). Furthermore, Vegas estimation of optimal transmission rate at steady state is fooled by the DVBRCS asymmetric and RTT-variant links. The problem of defining a more efficient transport protocol must cope with all these issues, but still maintaining the typical fairness of concurrent TCP flows.
Page 31
Figure 12: Sequence Number of a TCP transfer
Figure 13: RTT samples -VBDC
Page 32
Figure 14: Throughput evaluation - RBDC
Page 33
5.
PROJECT SATNEX JA2410 FT3 VOIP OVER SATCOM
5.1 Overview
SatNEx (Satellite Network of Excellence) and its extension SatNEx II are two Network of Excellence (NoEs) funded by EC within FP6 program. In this framework, a particular attention is devoted here to the activities performed within WorkPackage (WP) 2400, titled Research Trials, Tools, and Testbeds. In short, the goal of this workpackage is to promote and organise collaborative cooperations among SatNEx-II partners, aimed at investigating different SatCom domains by means of research tools properly designed for the scope and through the ideation of effective test beds suitable for the sake of the experimentation. Some details about the Joint Activity (JA) 2410, titled Access, Network and Transport Layer Trials belonging to this WP are given here. In particular Focus Topic 3 (FT4), VoIP over Satellite Networks is focused on. The testbed have the purpose to study the performances of VoIP (SIP and H323) protocols over a real satellite network. CNIT have an operative satellite network connecting 25 sites in Italy. The network is in a transitional phase at the writing time, as CNIT is switching from a Skyplex-based mesh network to a DOCSIS-based star network. The new configuration is available in some sites for testing purposes. Hence, preliminary tests have been carried out on the new platform. The VoIP performances studied have been focused on the efficiency of the various configurations, on the stability and usability of the software (softphones, PABX, etc.) and on the performances measurement. Both plain VoIP and videoconference have been tested. In particular, for what concerns the measures, the following parameters have been considered: delay/jitter, bandwidth, packet loss, PESQ (experimental).

The testbed is made by two parts: the satellite network and the VoIP software. Satellite network The CNIT baseband devices are VIASAT Surfbeam access modems, relying upon a broadband satellite system developed by ViaSat Inc., based on the Data Over Cable Service Interface Specification (DOCSIS). It is designed for use with geostationary spot-beam based satellites in the Ka (20/30 GHz) or Ku (12/14 GHz) band and provides the user with a broadband experience comparable to that currently provided by cable modems at similar costs. Although the upper layer protocols are all based on DOCSIS, the physical layer (PHY) has been modified to accommodate the unique challenges of the satellite-land channel. The modulation scheme used by the SurfBeam user SM terminals on the return link back to the satellite is QPSK with a forward error correction (FEC) rate of 1/2 or 3/4. The system utilizes various return link symbol rates including 2560ksps, 1280ksps and 640ksps. The return link is a multi-frequency time division multiple access (MF-TDMA) system. The overall satellite network architecture is depicted in Figure 15.
Page 34
Figure 15: CNIT satellite network architecture. VoIP software VoIP testbed architecture is made by several components as depicted in Figure 16. Namely: 1) 2) 3) 4) a VoIP PABX (AsteriskNOW + appconference) softphones (Counterpath X-Lite, others) network monitoring tools (Wireshark) traffic injection tools (iperf)
Figure 16: VoIP testbed architecture. The softphones are installed in the three PCs, along with the network monitoring and traffic injection tools. PC1, PC2 and the Asterisk server are located in Firenze, while PC3 is located in Pisa. The communication can be done using the PABX (i.e., all the softphones are connected trough the PABX) or directly between the softphones (i.e., the so-called peer-to-peer communication).
Page 35

Skyplex experiments A set of experiments has been carried out with both G.711u and GSM codecs. Results show that the G.711u average bandwidth occupation is 69.02 Kbit/s with a standard deviation of 18.34 Kbit/s. The distribution of the bandwidth occupancy is shown in Figure 17. This is particularly interesting for DBA (Dynamic Bandwidth Assignment) systems, since the non-constant bandwidth can trigger different DBA requests. On the contrary the GSM codec bandwidth usage is almost constant due to the missing silence suppression feature. Sets of experiments have been also carried out in order to compare IAX and SIP data channel performance differences. No significant difference has been noted between the two protocols, even in the presence of background traffic to fill the available bandwidth. It should be observed that the results do not include traffic multiplexing and/or SIP signalling channel synchronization. In the presence of interfering UDP traffic, the sum of queuing and propagation delays produce a detrimental effect on call quality, as shown in Table 1, which summarizes the MOS rating of the sample of users with different codecs and UDP interfering traffic. As shown in the table, with a shared satellite capacity of 1.4 Mbit/s, the voice call cannot be initiated (marked as X in the table) at signalling level with an interfering traffic saturating the link. With 1.2 Mbit/s, the SIP protocol connects the terminals but the voice signals are impaired (marked as LAGGED in the table). With 1.1 Mbit/s of UDP traffic and less, the call quality improves with moderate differences among the selected codecs. Table 1: MOS rating with different codecs and UDP interfering traffic. 1.4 Mbit/s 1.2 Mbit/s 1.1 Mbit/s 0.75 Mbit/s 0.35 Mbit/s GMS G.711a iLBC X X X LAGGED LAGGED LAGGED 2 2/3* 2/3 2/3 3 3 3 4 3/4
Figure 17: VoIP: bandwidth occupancy, G.711u codec. Surfbeam experiments PC1 (Florence) and PC3 (Pisa) communicate trough an Asterisk-based PABX server, located in Florence. On the PABX server is installed the APPCONFERENCE plug-in, enabling multi-user videoconferences. Using a packet sniffer and analyzer (Wireshark) forward traffic of PC1 (from PC1 to server) and Reverse traffic of PC3 (from server to PC3) has been studied. At application level we used the Eyebeam softphone from Counterpath. The used audio/video codecs are GSM
Page 36
and H.263. The switching of the user video flows is driven by a VAD (Voice Activity Detection) system integrated into APPCONFERENCE. In our analysis we studied audio and video traffic bandwidth and jitter parameters. Figure 18 shows PDF (Probability Density Function) H.263 bandwidth after a three minutes videocommunication over satellite network, respectively. The mean values detected are: 53.580 Kbps for forward traffic and 51.260 Kbps for reverse traffic. Therefore, in a videoconference using these two codecs (with Appconference plug-in), the required bandwidth for each client is about 80 Kbps. Figure 19 shows jitter values of GSM, detected during the same three minutes videocommunication. Using the GSM codec, forward jitter values are located between 0.5 ms and 8 ms and are mainly due to OS internal process queues; reverse jitter values are located between 10 ms and 20 ms, except for the initial jitter peak which is probably due to an estimation error of the packet sniffer software. Figure 20 shows jitter values of H.263. In this case, forward jitter values are between 1 ms and 10 ms and reverse jitter values are above over 10 ms, generally between 20 ms and 30 ms, highlighting the satellite channel effects on the communication.
Page 37
Figure 18: Bandwidth Probability Density Function of H.263 Video Codec.
Figure 19: Jitter levels of GSM Audio Codec.
Page 38
Figure 20: Jitter levels of H.263 Video Codec. Table 2: VoIP QoS parameters. BAD Packet Loss (%) 25 Delay (ms) Delay Jitter (ms) 225 MEAN GOOD PERFECT 10 125 3 250 75 0 < 150 0
> 450 450
During our videoconference tests, we detected values between good and perfect of VoIP QoS (Quality of Service) according to the popular MOS chart reported in Table 2. An estimate of the maximum number of users in a videoconference over the satellite system has been computed. On network side without asterisk server the main bottleneck is the uplink bandwidth. Hence, we have: Uplink band: 384/400 Kbps about 4 clients Uplink band: 800 Kbps about 9 clients Uplink band: 1200 Kbps about 12 clients It is interesting to note that, differently from the Skyplex system, the allocation/deallocation of the uplink bandwidth doesnt seems to have much influence on the traffic. Further analysis on this point should be done, also considering the lack of technical documentation about this point.
5.4 Results
Field trials have shown that VoIP and VidoOverIP over satellites are feasible also with inexpensive and off-the-shelf software. Moreover the dynamic resource allocation protocols do not interfere with the communication dramatically.
Page 39
On the other hand there are still some hidden software bugs that could arise only in a satellite environment, mostly due to protocols timeout or bad software implementations. Moreover in the commercial systems, where the bandwidth is not guaranteed, there is the possibility to have severe quality degradations due to other users behaviour. Last but not least, the audio and video codec choice is a crucial point both to have a good QoS, to save bandwidth and to gain positive triggers from the DBA systems. This to be taken particularly into account when the PABX can do some sort of transcoding. This capability should be severely restricted or used very wisely.
Page 40
6.
PROJECT SATNEX JA2410 FT4 VOTOS
6.1 Overview
SatNEx (Satellite Network of Excellence) and its extension SatNEx II are two Network of Excellence (NoEs) funded by EC within FP6 program. In this framework, a particular attention is devoted here to the activities performed within WorkPackage (WP) 2400, titled Research Trials, Tools, and Testbeds. In short, the goal of this workpackage is to promote and organise collaborative cooperations among SatNEx-II partners, aimed at investigating different SatCom domains by means of research tools properly designed for the scope and through the ideation of effective test beds suitable for the sake of the experimentation. Some details about the Joint Activity (JA) 2410, titled Access, Network and Transport Layer Trials belonging to this WP are given here. In particular Focus Topic 4 (FT4), VOTOS (Various cOngestion conTrol protocOl over Satellite) is focused on. The ever-increasing diffusion of the Internet Protocol suite has caused the Transmission Control Protocol (TCP) to become the most widely used for a reliable transport layer. Among the various functions performed by TCP, congestion control is one of the most important and delicate. Due to the increasing number of streaming and interactive applications based on IP (i.e. VoIP, IPTV, etc.) new congestion control protocols for IP traffic are arising aside TCP, such as TCP Friendly Rate Control (TFRC) algorithm for Datagram Congestion Control Protocol (DCCP). Unfortunately, high latency, bandwidth asymmetry, and transmission errors may remarkably affect the performance of such congestion control protocols on terrestrial wireless and satellite channels. In particular, slow start algorithms may be too slow for broadband connections traversing long RTT links, thus resulting less efficient. On the other hand, satellite channels increase the amount of time that congestion avoidance algorithms need to increase the congestion window, when compared to terrestrial links. The main issue is the analysis of the behavior of congestion control protocols over satellite networks, with particular attention to those systems that adopt the most recent Demand Assignment Multiple Access schemes, such as Skyplex Data, Amerhis, BGAN, etc. Analytical studies, simulations, emulations, and real trials are the fundamental features of this topic.

Measurements are carried out on Skyplex Data, an experimental satellite network based on the Skyplex OBP technology that was run by Eutelsat on the HotBird 6 satellite, which relied on DVBRCS features, while not being completely DVB-RCS compliant. On Skyplex, IP packets are encapsulated into an Mpeg-2 transport stream and transmitted to the satellite using Time Division Multiple Access (TDMA) uplinks using DVB-RCS format from small traffic terminals. On board the satellite, these signals are demodulated, regenerated and sent downlink in a format very similar to DVB-S. The HotBird 6 satellite is equipped with four Ka band transponders, whose footprint covers most of the European area. Control and management are centralized: the control centre, located in Lario (Italy), is in charge of generating messages sent to the traffic terminals used for acquisition and synchronization, and of computing and broadcasting the burst time plan (BTP) for the assignment of the capacity to the terminals. In order to meet user requirements, the satellite bandwidth (about 36 Mbps) can be divided in Low Rate channels (LR at 2.112 Mb/s) and High Rate channels (HR at 6.226 Mb/s), because each
Page 41
channel has a TDMA structure that allows a configurable number of time slots per frame. Our experimental testbed consists of an LR carrier with a TDMA frame of 48 time slots. The slot assignment is dynamic (DAMA). The bandwidth is requested periodically by each terminal to the network control centre on the basis of its own instantaneous need, and the time slot are assigned in a best-effort mode. However, a minimum guaranteed bandwidth equivalent to one slot per frame (44 kb/s), used for signalling and user data, and is reserved to each traffic terminal.
Figure 21: VOTOS testbed overview.

TCP steady state measurements over Skyplex We started by comparing the performance of some commonly used TCP stacks on Eutelsat's Skyplex Data satellite platform: the results are shown in Figure 22, which shows how Linux TCP, with and without SACK, and FreeBSD TCP behave on the satellite link.
Figure 22: Performance of different TCP flavours over the Skyplex platform. First experiments with Linux without SACK (TCP's selective acknowledgement) reveal that, on the first connection to a given destination, performance is severely hindered because of the first
Page 42
congestion event at the end of the Slow Start phase, which causes the loss of several segments that TCP takes a long time to recover. Use of SACK makes recover much more efficient. Performance on subsequent connections is good if the cached value of the Slow Start threshold has not yet expired. Instead, experiments with FreeBSD show good performance on all connections, because recent FreeBSD kernels perform an estimation of the bandwidth-delay product and prevent the congestion window from exceeding the estimated value, thus completely preventing packet losses, at least in our setting. This method produces a slight underutilization of the satellite channel, while providing excellent start-up performance even on the first connection. It is apparent from the figures that the inner workings and the overall performance of these three TCP flavours substantially differ:
Linux without SACK fills up the bottleneck buffer at the end of the Slow Start phase, and experiments many packet losses when the buffer overflows; the subsequent Fast Recovery phase is not fast enough to avoid a timeout and a very slow Slow Start phase, that retransmits a high number of packets already transmitted, whose duplicate ACKs do not contribute to increasing the congestion window. This behaviour is well known. Linux with SACK behaves much better, essentially because the Slow Start phase is fast thanks to the selective acknowledgements; the resulting throughput is, on average, as fast as the channel permits, even if the flow of packets is very irregular. FreeBSD uses an algorithm for estimating the bandwidth available to the TCP connection and the latency of the channel, and uses these estimates to cap the rate of packet transmission; the resulting behaviour, in this simple case where a single connection occupies the whole channel, is almost as efficient on average as Linux and in addition the packet rate is extremely regular, without even a lost packet and with an RTT only slightly higher than the minimum.
TCP start-up measurements over Skyplex In this section we focus on the behaviour of TCP during the Slow Start phase. Figure 23 compares the first 20 seconds of acknowledged sequence numbers for two different TCP implementations transmitting data over the satellite link. We show the performance of the default FreeBSD and Linux implementations, reporting for each case 9 connection traces. We note that at the beginning of the connections the behaviours of both TCP implementations are similar. We can distinguish two phases: an approximately exponential increase of sequence number and a linear increase phase. Indeed, since during the Slow Start phase the congestion window is increased by twice the amount of acknowledged bytes, the ACK reception rate increases exponentially until the TCP throughput reaches the available channel capacity; after that point the ACK rate remains constant. However, we notice that the time to double the congestion window is considerably longer than the connection round trip time usually observed over terrestrial networks. As will be clarified in the following, this phenomenon is to attribute to the DAMA policy adopted to share the satellite bandwidth.
Page 43
Figure 23: Start-up behaviour of Linux TCP over the Skyplex platform. In Figure 23 real traces are plotted together with simulated traces obtained with a satellite TDMA DAMA allocator for ns-2, which implements the dynamics of bandwidth assignment protocol. The simulator, validated with comparison with satellite measurements made on Eutelsat's Skyplex Data platform, is useful to assess the TCP behaviour under different working parameters. Though FreeBSD's TCP has the same qualitative behaviour of Linux's TCP during start-up, Linux is quicker because, according to RFC 3390, it sets the initial window to three packets, while FreeBSD more conservatively uses an initial window of only one packet. In the following we develop a simple approximate analytical model of TCP start-up over DAMA controlled links. Though this model is not meant to be accurate at the packet level, it can be very useful to evaluate the impact of the relevant parameters on the overall connection completion time. In particular, it accounts for the delay occurring between bandwidth request and assignment introduced by the DAMA mechanism.
6.4 Results
Experiments show that the steady-state behaviour of different TCP flavours over satellite links is nonuniform. FreeBSD and Linux with default settings perform reasonably well. SACK is essential to obtain good performance in Linux. A further observation is that the start-up behaviour of different TCP flavours over DAMA satellite links is similar and generally unsatisfactory, as the DAMA control loop interacts with the TCP startup behaviour, slowing it down. It is necessary to provide mechanisms to counter this effect.
Page 44
7.
PROJECT SATNEX JA2410 FT1 WICHMO
7.1 Overview
SatNEx (Satellite Network of Excellence) and its extension SatNEx II are two Network of Excellence (NoEs) funded by EC within FP6 program. In this framework, a particular attention is devoted here to the activities performed within WorkPackage (WP) 2400, titled Research Trials, Tools, and Testbeds. In short, the goal of this workpackage is to promote and organise collaborative cooperations among SatNEx-II partners, aimed at investigating different SatCom domains by means of research tools properly designed for the scope and through the ideation of effective test beds suitable for the sake of the experimentation. Some details about the Joint Activity (JA) 2410, titled Access, Network and Transport Layer Trials belonging to this WP are given here. In particular Focus Topic 1 (FT1), WICHMO (Wireless Channel Modelling) is focused on. The scenario consists of a hybrid network comprising a GEO satellite link and a wireless terrestrial link (Wi-Fi). This is a typical situation in: remote or temporary installations, where the Wi-Fi network is in infrastructure mode; emergency installations or rescue teams in remote area or disaster scenarios, where the WiFi network is in ad hoc mode. This is a challenging environment because of: long delays, variable bandwidth, highly correlated frame loss. The GEO satellite channel has a fixed delay, a fixed bandwidth and no packet loss, because the observed 10-4-10-5 Packet Error Rate (PER) is negligible with respect to Wi-Fi PER.
Figure 24: The hybrid network experimental scenario The WiFi channel has three layers that need simulating: the frame level, where the Frame Error Rate (FER) process is considered; the ARQ level, where retransmission of frames without an ACK is considered; the ACM level, where variable channel bandwidth is considered, depending on the FER process.
Page 45

From the point of view of TCP, each link is characterised by: capacity: available rate seen at the IP level; latency: the time a packet takes to traverse the link; buffer size: the size of the buffer the router or bridge on the bottleneck link uses to store packets waiting to be sent; packet error process: a statistical description of segment losses. As far as the satellite link characteristics are concerned, we considered a 2 Mb/s link, which is a common commercial figure. Geostationary channel introduces a radio signal delay of around 250 ms. There are processing delays at the routers, so any latency not smaller than 300 ms is a reasonable assumption. As far as the Wi-Fi link characteristics are concerned, we used a nominal rate of 11 Mb/s, for a net bandwidth at the frame level of 5.3 Mb/s for a unidirectional flow of 1000-data byte packets; long preambles, no fragmentation, RTS/CTS disabled; latency produced by the driver and the hardware around 1 ms; frame-level retransmissions limited to 7; retransmission delays greater than 50 ms in less than 0.1% of packets. Figure 25 shows the indoor setting in our experiments. Rooms are delimited by thin walls.
Figure 25: Indoor terrestrial segment. Tx in room 66, Rx in rooms 73 and 71.

Indoor WiFi on Hybrid Network Traffic sent is a CBR flow: one 1000 bytes-long frame every 5 ms at 11 Mb/s fixed rate with fragmentation and retransmission disabled for a total of 5 hours of measurements. The receiver checks a sequence number inside the frames and creates a trace of the lost ones. The time resolution of our measurements is 1.2 ms, that is, the time a frame occupies the channel. We considered two frame error models: Bernoulli (i.i.d. Losses) Each frame has the same fixed probability of being corrupted. Losses are independent of each other. Simple, tractable model. Bistable Two-state Markov chain.
Page 46
Transition probability from the good to the bad state is b, from bad to good is g. The stationary probabilities of being in the good and bad states are Pg = g/(b+g) and Pb = b/(b+g). Mean length of error bursts (consecutive errors), is 1/ g. Error bursts are separated by gaps (consecutive received frame) whose mean length is 1/b. In order to go from frame errors to packet loss we need an error model for the 802.11 link that mirrors our measurements. We wrote a trace-based error model for ns-2 which is available for download from http://wnet.isti.cnr.it/software/ttem. We feed this model with measured packet loss traces on a real 802.11 channel. Traces contain sequences of ones and zeros, indicating bad and good channel states. We consider four different models for the observed frame loss: Bernoulli process having the same frame error rate as observed; Bernoulli process having the same mean burst length as observed; Bernoulli process having the same mean gap length as observed; Bistable process having the same frame error rate, mean burst length and mean gap length as observed. Figure 26 shows the throughput that is computed using the measured traces compared with the considered models, plotted versus the measured packet loss rate.
Figure 26: Fitting several frame loss models with the measured traces. None of the simplest models can be used to obtain an accurate estimate of the TCP goodput. Neither Bernoulli nor bistable are completely adequate. Bernoulli with gap length fit or bistable could be used for TCP performance evaluation by choosing appropriate parameters, but this is not an ideal solution. More details on the specific activity can be found at: http://fly.isti.cnr.it/curriculum/pot_abstracts.html - C20:PacketLossHybrid-ASMS06Paolo Barsocchi, Gabriele Oligeri, and Francesco Potort, Packet loss in TCP hybrid wireless networks, in Proceedings of Advanced Satellite Mobile Systems Conference (ASMS), Herrsching (DE), May 2006.
Page 47
Outdoor Model for WiFi Packet Loss Using a significant amount of oudoor measurements on the Wi-Fi channel, which are available for download from: http://wnet.isti.cnr.it/data/wichmo/navacchio/, we realised a model for outdoor Wi-Fi propagation, coded into the MATLAB file wifiper.m (available on-line at http://wnet.isti.cnr.it/software/wifiper.m ). The propagation model is composed of a two-ray path loss model and a signal reception model.
Figure 27: Path loss model. In Figure 27, the usual double slope model is shown in green, the two-ray model we propose to use is shown in red, the measurements are the blue bars.
Page 48
Figure 28: Signal reception model. In Figure 28, we show how a BER model of QPSK over AWGN satisfactorily fits our measurements of FER versus received power. More detail on this activity can be found at: Paolo Barsocchi, Gabriele Oligeri, and Francesco Potort, Frame error model in rural Wi-Fi networks, in Proceedings of International Symposium on Modeling and Optimization (Wiopt), pp. 41-46, ACM, Limassol (CY), April 2007. WiNMee/WiTMeMo workshop.
7.4 Results
Two experiments were performed, which were described above. The experiment on indoor Wi-Fi on hybrid network showed that a two-parameter model (bistable, also known as a Gilbert model) is more accurate than a single-parameter model (Bernoullian, also know as Poisson model) for describing the type of frame loss that is observed on the Wi-Fi segment of the hybrid network. This is true as far as TCP connections over the hybrid network are concerned. The experiment on the outdoor Wi-Fi modelling produced a model for describing the frame loss process in a rural Wi-Fi environment. This is the typical ground segment of hybrid networks in applications like disaster relief, crisis management, communications in isolated and desert areas.
Page 49
8.
PROJECT WISECOM
8.1 Overview
The WISECOM project was co-funded by the European Commission under the FP6 IST Programme. It studied, developed, and validated by live trials candidate rapidly deployable lightweight communications infrastructures for emergency conditions (after a natural or industrial hazard). The system integrates terrestrial mobile radio networks - comprising GSM, UMTS, WiFi, and optionally WiMax and TETRA - over satellite, using Inmarsat BGAN and DVB-RCS systems. WISECOM uses lightweight and rapidly deployable technologies, and incorporates location-based services. The infrastructure is intended to cover immediate needs in the first hours and days after a disaster event, as well as medium to longer term needs, during the recovery and rebuilding phase following an emergency. The following sections provide a brief summary of the WISECOM Final Demonstration event, which took place at DLR, Oberpfaffenhofen, on Wednesday 28.05.08. A general overview of the different demonstrations which took place is provided, focusing on the live simulation of a disaster situation which was carried out with involvement of the rescue teams.

The aim of WISECOM is to develop and test an instantly deployable micro-cell base station providing GSM or 3G coverage and wireless data access (e.g. WiFi) that can be carried by one person on board a flight and be deployed within minutes. The backhaul connection to the intact network infrastructure is realized by means of a satellite link. Such a system could be set up anywhere in the world where there is satellite coverage; the satellite technology identified for this purpose is Inmarsat BGAN, providing essentially global continuous coverage. This solution for the very first hours and days after an emergency should be replaceable by a medium-term unit that allows higher capacity and lower usage costs than the portable one. It may be used for days or weeks during the recovery phase, with connection ensured by means of a broadband satellite DVB-RCS link.
Figure 29: System Architecture
Page 50

8.3.1 Demonstration of BGAN WAT capabilities in the DLR Control Centre The main objective of this demonstration was to present the main capabilities of the BGAN WISECOM Access Terminal (WAT) together with the monitoring and communication systems installed in the Control Centre and the ASIGN system. 8.3.1.1 WiFi over BGAN demonstration This first presentation was intended to provide guests with a general overview of the BGAN WISECOM Access Terminal (WAT). The following points have been addressed during this presentation: Presentation of the BGAN WISECOM Access Terminal (WAT) hardware and live deployment and starting up of the system. Connection of an HTC PDA to the WISECOM-PUB and WISECOM-PRIV WiFi networks generated by the BGAN WAT. In the case of the WISECOM-PUB network, the restriction of services for non-authorized users (normally victims) and their redirection to the WISECOM Welcome web page was shown, as well as the different offered services. These services include the sending of short text messages over the satellite link to the control server, which was tested by some guests using their own devices. Regarding the WISECOM-PRIV network, the availability of general IP services was demonstrated, including all the different types of Voice over IP calls using the system installed by DLR.
Figure 30: The BGAN WAT Hardware Demonstration of the different monitoring systems installed in the Control Centre, including the VoIP monitoring and management system, and the remote monitoring web interface, which monitors and controls the status of the WAT. Demonstration of the LBS software on the PDA and in the Control Centre that will be further used during the demonstration to perform the improved electronic triage of the victims over satellite. 8.3.1.2 GSM over BGAN demonstration A second, alternative version of the small WAT based on the BGAN satellite terminal, was presented by TriaGnoSys. The schedule of the presentation was the following:
Page 51
Presentation of the integrated emergency rucksack prototype. Explanation of single components, motivation for stacking and considerations for practical use. Explanation of deployment and start of WAT. Explanation of dual-cell configuration used for the demonstration. The configuration allowed two GSM cells for demonstration purposes: o o one GSM cell was configured to serve a sub-set of mobiles via the satellite link, for communications between disaster site and Control Centre; one GSM cell was configured to provide local communications between rescue team members and local control, not using the satellite link.
Demonstration and test by audience of various parallel voice calls within the local cell. The communication with the other cell suffered from a poor satellite connection and could not be demonstrated at that time. Concluding discussion based on questions from audience. 8.3.1.3 ASIGN Presentation and Demonstration During this part of the demonstration, the purpose and background of the ASIGN system was highlighted, showing that, unlike with a typical BGAN link, with ASIGN the images can be input in any desired quality within less than a minute. Finally, with the procedures both capturing and preserving GPS data, images are immediately mapped to a GIS server like Google maps or others. After this brief introduction, ASIGN was demonstrated using two different ways: By wireless transfer of captured images from a RICOH 500 SE camera indoors By remote camera control and a cabled transfer to the ASIGN trigger from a High Quality NIKON D300 camera outdoors with GPS The demonstration showed the immediate transfer over satellite to the WISECOM network of images that could be captured by first responders on the field. Images were displayed on a large video screen projector and guests could see the rapid transfer provided by ASIGN. Another screen showed the Trigger and the Receiver and AnsuR demonstrated interactive selection of regions of interest and illustrated the amount of savings in time and cost by using the ASIGN SW. With ASIGN it is practically feasible to input live images from the field during emergencies and use them, for instance, for coordination purposes and feedback guidance. 8.3.2 Outdoor demonstration of DVB-RCS WAT capabilities
8.3.2.1 Setting up the DVB-RCS WAT This part of the demonstration was intended to explain the actions taken to install the DVB-RCS station just after the first responders have arrived on the field and have started their recovery and relief actions. This DVB-RCS station is deployed to complement the already installed BGAN-based WAT: after the first hours of intervention (early disaster phase) and before terrestrial networks are restored (if ever), there is the need of higher bandwidth telecommunications. This is the goal of the DVB-RCS station, to provide broadband communications in order to: Support broadband applications telemedicine, GIS, etc.) (like videoconferencing, collaborative working,
Support the exchange of larger data files (EO products, maps, videos, etc.) Provide a collective access point for a larger number of users
Page 52
Provide a relay for higher bandwidth WLANs (WiMax, microBTS GSM cell, TETRA, etc.) The setting up of the antenna (physical installation and manual pointing) was done in 10 minutes only (5mn for the hardware set up, 5mn for the pointing). This shows that such a system can be operational with a short delay. Apart from the setting up of the system, the WiFi/WiMAX, GSM and ASIGN systems over DVBRCS were also demonstrated. 8.3.2.2 WiFi/WiMAX over DVB-RCS demonstration in a realistic emergency scenario The next step during the WISECOM Demonstration event was the presentation of the WiFi/WiMAX over DVB-RCS system. In this presentation, apart from a brief introduction to the main capabilities of the system and its architecture, a simulation of an emergency scenario was prepared on the field. The architecture of the system prepared for the demonstration consisted of a WiMAX base Station connected directly to the WAT and to a subscriber station mounted in a rescue team car. The communication between these two stations was performed via WiMAX. According to this configuration, the WiMAX base station located at the green tent was connected: to the Control Centre through the WAT and the DVB-RCS satellite link, to the different wireless networks deployed on the spot: GSM, WiMAX, Tetra (not demonstrated the 28th of May), to the global world network (through the WAT and the Control Centre), The objective of the demonstration was to show through a short scenario (in very limited time frame) the different capabilities of the system SATCOM DVB-RCS + WiMAX/ WiFi. The different steps for this demonstration were: 1. The DVB-RCS system (and especially the antenna) is quickly deployed at the green tent (WAT). The WiMAX Base Station is installed to cover an area were casualties are supposed to be located. Using the satellite connection, a videoconference between the WAT and the Control Centre is established.
Deported antenna WiMAX Base Station
Figure 31: DVB-RCS WAT (simulating the green tent area).
Page 53
2. Thanks to a WiMAX link, a connection is established between the WAT and the subscriber station located in a rescue team car.
AC Convertissor Marratech Computer WiFi Module
WiFi VoIP Phone Deported Antenna
WiMAX client
Figure 32: WiMAX client in the Rescue Team Car. 3. The rescue team in the car communicates (VoIP, then video) with the WAT and the Control Centre to keep them informed about the rescue operation and ask for advice in case of finding any victims. 4. In this case, the PDAs or laptops of the rescue team members are connected via WiFi to the WiMAX client in the car, connected via WiMAX to the WAT and connected over satellite to the Control Centre and other public terrestrial networks. First of all, the rescue team makes an IP call (between a WiFi IP phone in the car and a PDA located at the WAT) to announce that a victim has been found. Then a videoconference between the rescue team, the WAT and the Control Centre is established. Images of the victim are transferred from the rescue team car to the WAT and further to the Control Centre. Teams and green tent people identify the need to get additional expertise to make the correct decision. 5. An expert is called (for the sake of the demonstration, the link is done with a person in Toulouse) and joins the videoconference. The videoconference is therefore now extended to 4 people (rescue member on the spot where the victim is, the green tent team close to the WAT, people in Control Centre, and an expert from a remote location, i.e. Toulouse). All of them can discuss and share pictures and see each others through the webcam. Images from the spot are transferred to the expert. 6. The expert requires medical act to be done. Here an Electro CardioGram (ECG) measurement is simulated and sent to the expert who decides which appropriate actions should be undertaken. Data (e.g. ECG) are transferred to the expert, analysed, and diagnostic & plan of action are agreed with the Control Centre and teams on the spot. 8.3.2.3 GSM and ASIGN over DVB-RCS demonstration 8.3.2.3.1 Demonstrating GSM over DVB-RCS The next part of the demonstration was intended to present the GSM over DVB-RCS system in the context of a multi-service scenario. In order to achieve this objective, the GSM sub-system was set up by connecting the Base Transceiver Station (BTS) from Ericsson to the Optimizer (VMUX-400)
Page 54
via a 2 Mbps link, and from there to the DVB-RCS terminal via Ethernet and IP. The GSM base station was connected to a router in parallel with WiMAX and Wi-Fi. While the BTS was fitted in a rack, physically mounted along with the WIMAX and Wi-Fi equipment, the GSM antenna was mounted on a small pole along with the Wi-Fi antenna. The GSM antenna was a small, Omni directional unit, providing with coverage an area of approximately one kilometre. The GSM system was demonstrated by making calls to users phones. The WISECOM phones were equipped with special MCP SIM cards, and calls between WISECOM phones and to external spectators (could be victim or doctor) phones were demonstrated. The voice quality was very well considered and the system worked flawlessly. 8.3.2.3.2 Demonstrating ASIGN over DVB-RCS With Wi-Fi coverage already present, further setting up of ASIGN was not required. ASIGN was demonstrated as in the LAB but this time with full GPS fix and direct mapping to Google Maps. Images were transferred directly from a camera to ASIGN Trigger and then to the WISECOM Control Centre and from there back to selected users on the field. 8.3.3 Live Demonstration of an emergency situation For this part of the demonstration, a realistic scenario for a disaster was prepared. Particularly, an explosion at a construction area at DLR was chosen. The area covered with victims had to be large enough, to show the coverage potential of the WISECOM WAT. The soccer field close to the DLR offices has a diameter of more than 400 m and the construction area with adjacent buildings allowed hiding victims on top of a roof or in a construction pit. In addition, the grass on the soccer field was high, allowing hiding victims after the explosion of methane gas in a field toilet to disappear. Several victims suffer from burns and injuries from flying parts, blast trauma, inhalation trauma, etc. We assumed that victims would spread due to fire development, but after a while sit down, as they are hindered by their injuries, or by hypoxia due to inhalation of toxic smoke. As the airport was just adjacent to the soccer field, the fire and smoke emission were kept small not to interfere with airport operation. In addition, all parts of the scenario were kept as safe as possible, not to harm anybody during the demonstration. Different to reality, dying or dead patients were omitted, not to cause any psychological issues for the rescue teams. The following sections are intended to provide an overview of the demonstration. 8.3.3.1 Preparation of the victims For the live demonstration, 20 fake victims have been carefully prepared so that their fake wounds and injuries enable the doctors on the field to establish a realistic diagnostic of the seriousness of each victim. The diversity of the injuries enabled to classify the victims into different groups, corresponding to the severity of the injuries, and basically victims have been prepared so that 12 green victims, 4 yellow victims and 4 red victims can be found on the field, being the red victims the ones with more severe injuries. Afterwards, victims have been randomly placed on the simulated disaster area, fire is prepared and it is assumed that the Red Cross and fire brigades are alerted. In addition, the victims are experienced to simulate the behavior of the different pathology of the trauma to make the exercise more realistic. 8.3.3.2 Arrival of the fire brigades and Red Cross At 19:00, fire brigades and Red Cross arrived to the simulated disaster area, around which the victims were lying.
Page 55
Figure 33: Arrival of the chief emergency physician and other rescue forces (red cross and fire brigades) at the simulated disaster area. 8.3.3.3 Setting up of the Control Centre and of the treatment tents Upon arrival of the rescue team members, a Control Centre tent, and places to process the different victims with different types of injuries were installed. The red tent on the next figures contains the local management team of the fire brigade and the Red Cross. The dispatchers have there access to the LBS data. It is located close to the victim collection area (also called green tent along this document) as well as the disaster scene to provide best overview.
Figure 34: Red Cross staff is unfolding the equipment for the treatment area. As the weather was good, the green tents were not deployed. 8.3.3.4 Deployment of the WAT and installation of the Control Centre on the field While the red tent (local Control Centre) and the place to nurse victims (also called green tent) are set up, two members of the rescue forces went on the field and quickly and easily set up the WISECOM Access Terminal (the WAT). This process took less than 5 minutes. The WAT deployed on the field during the live demonstration was the portable one, relying upon a BGAN terminal. It enabled to successfully provide the demonstration area with WiFi coverage, used to successfully run the LBS application and VoIP voice calls. Inside the red control tent, a local LBS Control Centre (Laptop connected to the WAT thanks to WiFi) was set up. The LBS data and any information from the rescue teams were collected there. Rescue teams were instructed by the local coordinator in the red tent to help the severely injured patients (red color) with highest priority. This was performed thanks to the messaging system provided by the LBS software.
Page 56
Figure 35: Deployment of the WISECOM Access Terminal (WAT) close to the victims area by two rescue force staff members.
Figure 36: Installation of the local Location Based Service (LBS) Control Centre in the red tend. 8.3.3.5 Finding of the victims by the Red Cross Members Once the WAT is deployed and the red and green tent are set up, 3 rescue teams (composed each of Red Cross members and an emergency physician) equipped with the WISECOM PDA with LBS software, started walking around on the disaster area, looking for victims and performing primary triage. At this early stage, the aim was not to treat the patients, but to organize their evacuation towards the collection area. Upon discovery of new victims on the field, the state and type of injuries of the victims were assessed by an emergency physician. It was him who, according to the evaluation of the victim status, was able to classify the victim among the 4 triage colors (green, yellow, red and black, from less to more severe injuries) and to tell the members of the Red Cross how to fill in the triage cardboard to be put around the neck of the victims as well as its electronic version on the PDA.
Page 57
Figure 37: Assessment of the victim status by the emergency physician. 8.3.3.5.1 Filling in the Triage Tag It is important to notice that two systems have been simultaneously used during the live demonstration to perform the triage of the victims: Triage tags made out of cardboard have been used as a standard. They provide the unique victims number (STA-XXX, where XXX is a unique 3 digits number) and can be considered as a secure backup in case of failure of the WISECOM telecommunication equipment. The LBS software running over PDAs connected via WiFi to the WAT and via the BGAN satellite system to the remote Control Centre and LBS server containing the victim database. The LBS software enabled the live transmission to the Control Centers (in the red tent on the field and on the disaster safe segment at the DLR building) of an electronic version of the triage tags, containing all the information described in the triage tag cardboard plus GPS coordinates and time stamp of the victims. Figure 38 displays and compares the information contained in the triage card cardboard hung around the neck of the victims (left hand side) and the information that can be entered in the LBS software running on the PDA of the members of the rescue teams. The main advantage of the electronic triage tag with respect to the classical solution is the automatic insertion of the GPS coordinates of the victims, as well as a time stamp, and the instantaneous transmission of this information to the Control Centre via the WISECOM system.
Page 58
(a) LBS Main Menu
(b) LBS Victim Submenu Figure 38: Comparison of the cardboard tag on the left and of the electronic tag on the right. Note that the electronic tag includes the GPS position of the patient, accurate time stamp, and is transferred instantaneously to the Control Centre(s). 8.3.3.6 Transportation of the victims by the Fire brigades 8.3.3.6.1 Monitoring in the Control Centre and transmission of a command message from the Control Centre to the ambulance teams After a while, the 3 triage teams have found a given amount of victims and registered them to the Location Based Service (LBS) system. In the field Control Centre and at the DLR Control Centre, these victims are displayed as triangles of different colors (according to the type of injuries of the victims) overlaid on the map of the disaster area. Then, the controller in the field Control Centre is sending text messages to the different ambulance teams, to ask them to pick up specific victims, identified thanks to their triage number, which can be found on the paper triage tag (cardboard), hung around the neck of the victims by the
Page 59
triage teams, and is entered in the LBS software during the triage phase. Priority is given to victims with the highest need for treatment. 8.3.3.6.2 Finding the victim Upon reception of an instruction message from the field Control Centre (red tent) asking for picking up a specific victim on the field, a rescue team of the fire brigades walks directly to the specified victim on a direct path. This team is lead by a member using the WISECOM system and the LBS software to find the victim on the area (comparing its position and the one of the specified victim). Once found by the ambulance team, the status of the victim is updated to in transit with the LBS software. Practically, the victim was represented on the map (on the PDAs and in the Control Centres) thanks to a triangle which turns into a dot upon update of the victim status (see Figure 39). This information, distributed to the whole community of people involved in the rescue operation, enables everybody to be informed that the specific victim is now being transported to the victim collection area (green tent) where he will be nursed.
Figure 39: Once the specified victim (red triangle) has been found, the ambulance team updates the status of the victim to in transit and the triangle turns into a dot. This information is updated simultaneously on all PDAs and in the Control Centers. 8.3.3.6.3 Transportation of the victims to the relief camp Once the targeted victim has been found (thanks to the LBS software indicating the position of the victim on the field and the triage tag around the neck of the victim), the victim is loaded and carried towards the victim collection place where the victims will receive appropriate aid.
Page 60
Figure 40: Patient being carried out of the explosion area to the collection area. 8.3.3.6.4 Arrival of the victims at the collection area and updating of the victim status (final destination) All victims (but the green ones) are transported to the collection area, where they can be reassessed according to their new triage category and treated. The LBS software is used a last time to update again the location of the victim to final destination, thanks to the update location feature of the LBS software. Once the location of the victim has been updated to final destination, the dot representing the victim disappears from all the screens (in the Control Centers and on the PDAs used by the members of the rescue teams). At this stage, the victim was considered as rescued and out of the demonstration.
Figure 41: Victims are being treated at the collection area to be prepared for transportation to the hospital. A second triage is performed at this stage.
8.4 Results
8.4.1 Medical improvement The major advantage for any patient is a fast transfer to the final treatment. The demonstration clearly revealed that after finding and triage of the patients the transport teams could directly be ordered to the highest priority patients. As the patients could not be seen, the GPS directions allowed each transport team to directly walk to the appropriate patient. In contrast to the existing system of paper tags, that does not account for the location of the patient, the WISECOM system immediately provides location and triage information to the Control
Page 61
Centre as well as to the transport teams. The system allows the shortest possible time to relocate the patients and to bring the adequate patient to the collection place for further treatment. As waste of time on disaster areas can be more than 30 min up to several hours, it is a relevant finding that will definitely improve mortality of patients. 8.4.2 Operational improvement The first time the location and triage information is immediately available at the control centre. Any coordination of the rescue forces is readily possible. The more correct information about the scene is available at the control centre the faster the coordination can be achieved. In comparison to the existing systems, the WISECOM system is speeding up the information transfer and reduces errors due to wrong transmissions. The evaluation of the WISECOM system reveals that the overall use is an improvement, but in further development has to be invested to make the system more practical for everyday use. In conclusion, the system has proven to improve operational and medical output in a disaster scenario.
Page 62
9.
PROJECT SFEDONA
9.1 Overview
During the past summer periods, forest fires in Greece and in other, mainly southern, EU countries have been quite frequent and devastating particularly due to the vegetation type, climatic conditions and the large percentage of coverage of forest and wooded land areas. On top of these, the specific terrain morphology as well as the vast amount of mountainous and insular regions makes fire detection very difficult. In this context, a very recent and characteristic example is the devastating fires that broke out in the summer of 2007 in Greece (see Figure 42).
Figure 42: Burnt area extracted in Greece by Envisat MERIS FR In view of the above, the SFEDONA (Satellite-based FirE DetectiON Automated system) project aims to design, develop, validate and demonstrate a complete end-to-end fire detection and alerting application which makes use of state-of-the-art fire detection technologies based on terrestrial optical cameras and sensors, data fusion, satellite and wireless communications as well as modern IT technologies. In particular, the SFEDONA project will deal with the design, development, integration and validation of a terrestrial wireless network for the interconnection of various components installed on-field, such as optical and panoramic PTZ cameras, weather monitoring stations and wireless
Page 63
environmental sensors, as well as of a satcom network for the interconnection of the end users premises with local field. The outcome will be an integrated system offering a complete, end-to-end fire detection and alerting solution to the interested end users, such as Prefectures, Municipalities and large property owners, with the following services: Continuous 24/7, centralized and remote monitoring and control of large areas being prone to (mainly) forest fires. Early detection and alert of fire incidents as well as communication of critical data and alerts related to processed inputs received by various on-field cameras and sensors. Identification of exact location of fire alert incidents in electronic maps with the aid of an integrated GIS-based user-friendly application. Prediction of fire propagation orientation based on sophisticated algorithms and the processing of inputs coming from remote environmental sensors and weather monitoring stations. The SFEDONA project is co-funded by the European Space Agency, as part of ARTES 3/4 Telecom Products Programme (http://telecom.esa.int/artes34). The Prime Contractor of SFEDONA project is Space Hellas SA (GR).

The high level architecture of the SFEDONA system is depicted in Figure 43: SFEDONA System Architecture. It mainly comprises four subsystems: Remote Data Collection Unit (RDCU) Remote Control Unit (RCU) DVB-RCS SatCom Network Control Centre (CC)
Page 64
SatCom Network
Vision Sensor
Telecom Satellite
ZigBee
SatCom Interface Weather Meteo Station SatCom Interface
WiFi
Environmental Sensors
Vision Sensor
WiFi Panoramic Camera
Satellite Terminal
ZigBee WiFi Remote Control Unit (RCU) Vision Sensor Environmental Sensors ZigBee Satellite Terminal
End User (Prefectures, Municipalities, etc) Environmental Sensors
Control Centre (CC)
Remote Data Collection Unit (RDCU)
Figure 43: SFEDONA System Architecture Within the RDCU, there are optical camera sensors, weather monitoring stations and environmental sensors which are placed on the field. The optical cameras and weather monitoring stations are attached together and are located at a reasonable distance from the critical forest area. The optical cameras aim to monitor continuously the critical area and detect immediately possible fire and smoke sources. The environmental sensors are positioned at selected locations within the forest and together with the weather monitoring stations - aim to assist with the prediction of fire propagation. All heterogeneous data coming from the RDCU is wirelessly transmitted through WiFi interfaces to the RCU, where it is then correlated through intelligent data fusion software embedded algorithms. In the RCU, there is also a software application based on which alarm signals are communicated to the CC through the SatCom interface in case of alert. Moreover, a panoramic camera resides in the RCU in order to transmit low frame rate video stream to the CC via the SatCom interface in case of alert as well as for physical security of on-field equipment. At the CC, which is located at the end users premises, there is a fire detection and alerting GIS based application which provides rapid detection of fires and 24/7 monitoring and control of the critical area, based on the alert and control signals received from the RCU. Through this GIS-based surveillance application, the end user can be proactively informed about possible fires and their exact location on electronic maps. Within the CC, there is also another intelligent GIS-based software application for the prediction of fire propagation, which is mainly based on inputs received from the weather monitoring stations and environmental sensors.
Page 65
The detailed design of the Satcom Network subsystem is depicted in Figure 44: SFEDONA DVBRCS Satcom Network Architecture. The Satcom Network subsystem mainly comprises the following components: 2x Satellite Terminals, each one of which is further broken down as o o Indoor Unit (IDU): DVB-RCS compliant Satellite Modem Outdoor Unit (ODU): Parabolic Dish Antenna Antenna Az/El Mount Antenna Feeder Block Up Converter (BUC) Low Noise Block (LNB)
1x Telecom Satellite (HellasSat2, 39oE) 1x Hub Station (owned and operated by Hellas-Sat) DVB-RCS Satellite Service 512/256 Kbps
Satellite Hellas-Sat2 (39oE)
(Rest of)
RCU
DVB-RCS Satellite Terminal IDU
Coaxial
Coaxial
Satellite Terminal ODU
Satellite Terminal ODU
DVB-RCS Satellite Terminal IDU
(Rest of)
CC
Uplink (14 GHz) Downlink (12 GHz)
Internet
Hellas Sat Hub Station
Figure 44: SFEDONA DVB-RCS Satcom Network Architecture
9.3 Trials and Demonstrations Results

As part of the SFEDONA project, the following four different types of tests were conducted for the SFEDONA product validation: In-Process Tests (IPT): including testing of individual software and hardware items as they are procured or developed. These tests were carried out by Space Hellas in laboratory environment. Integration Tests (IT): including testing of the pilot system as it is built-up from individual software and hardware items to a complete product. These tests were carried out by Space Hellas in laboratory environment.
Page 66
In-House Validation Tests (IHV): including validation of the pilot system against the performance requirements. These tests were carried out by Space Hellas in laboratory environment. Customer Validation Tests (CVT): whose objective was to enable any weaknesses of the system to be identified and resolved prior to an operational roll-out. These tests were carried out by Space Hellas with active contributions from the involved end user in a real operational on-field environment (forest area under the jurisdiction of the end user). The major objective of the in-lab validation activities (i.e., IPT, IT and IHV tests) was to check that the system design is adequate and compliant to the specifications as well as to check that the pilot system was ready to be deployed at the end user site for commencing the field validation activities. Upon the successful completion of the in-lab validation activities, the SFEDONA pilot system was deployed at the end user site for the related CVT tests. Regarding the CVT tests, which refer to the field validation activities of the project, their main expected target was to validate and demonstrate the following services offered by SFEDONA: Remote and continuous monitoring and control of small/medium size suburban areas being prone to mainly forest fires but also fires from other causes originated in areas next to inhabited urban Early detection and alert of fire/smoke incidents Alert communication to control centre Identification of exact location of alert incident in electronic maps Estimation of fire propagation orientation The End User actively involved in the SFEDONA project referred to a Research Centre located on the foothills of Ymittos mountain in the region of Agia Paraskevi, Attica, Greece (3800N 2349E). This End User falls within one of the identified categories of the SFEDONA target customer group, namely, that of Individual Large Property Owners. Its jurisdiction area covers small/medium -size forest areas nearby inhabited regions. Due to its high potential risk of (mainly) forest fires, the End User has been inherently interested in the SFEDONA project and, thus, actively involved in its field validation activities providing also its requirements as well as its feedback from the related pilot operation. Apart from this End User in the premises of which the SFEDONA pilot system was actually deployed for the relevant validation activities, several other end user organizations supported the SFEDONA project by providing their user requirements and expressing their interest in supporting the project. These end users mainly fall within another identified category of the SFEDONA target customer group, namely, that of Prefectures and Municipalities. In Figure 45, Figure 46, Figure 47 and Figure 48 below, the deployment of the SFEDONA pilot system over the real operational field environment of the involved End User in order to conduct the CVT tests is illustrated.
Page 67
Figure 45: Deployment of RCU and RDCU#1 sub-systems co-located at End User site
Page 68
Figure 46: Deployment of RDCU#3 sub-system at End User site
Figure 47: Deployment of RDCU#3 metallic enclosure boxes at End User site
Figure 48: Deployment of ZigBee environmental sensor in the forest area of End User site
Page 69
Figure 49: Initiation of artificial smoke event with the use of smoke producers. The CVT tests specifically conducted over the real operational field environment (forest area) of the involved end user were the following: CVT-1: Pilot system setup, Objective: Site surveys and pilot system setup and deployment at the End User Site. CVT-2: Monitoring & control of small/medium-size forest area, Objective: Field validation activity at End User Site. The user requests from the panoramic surveillance camera installed on-field (RCU) to transmit low frame rate images in order to test received image quality. CVT-3: Detection of fire/smoke incident over small/medium-size forest area, Objective: Field validation activity at End User Site to test the capability of RDCU optical cameras and RCU embedded SW applications to detect possible sources of fire and smoke within controlled area and depict them at CC user console. CVT-4: User notification of fire/smoke alert over small/medium-size forest area, Objective: Field validation activity at End User Site. Once a fire source has been detected locally at the RCU level, test the alert be sent over the satcom link to the CC and the respective users notification. CVT-5: Identification & geolocation of alert incident in GIS maps over small/medium -size forest area, Objective: Field validation activity at End User Site to test the GIS-based SW application for identification and exact location of fire/smoke alert in electronic maps depicting the critical area, once a fire alert has been received at the CC.
Page 70
CVT-6: Prediction of fire propagation over small/medium-size forest area, Objective: Field validation activity at End User Site to test the capability of the SW application running on CC to accept inputs from environmental sensors and weather monitoring stations and produce in GIS maps the prediction of fire propagation, once a fire alert has been received at the CC. CVT-7: Pilot system operation, Objective: The End User to operate, use and evaluate the pilot system set up at his own premises for at least four months covering the summer fire season. To set-up the CVT tests, smoke producers to generate artificial smoke sources were employed (see Figure 49). Also, experienced staff and related fire-fighting equipment, such as foam fire extinguishers, of the Fire Protection Office residing within the involved end user to control and extinguish artificial fire/smoke sources in field environment were also employed. For a critical dimension (i.e., in the order of 1x1 m) of smoke generated by the smoke producer, the fire/smoke detection probability generated by the respective RDCU vision sensor reached the threshold value and, following the RCU Data Fusion algorithm detailed above, a respective fire alarm was generated at the CC users console. Regarding the calculated FWI values displayed on user consoles GUI at the time of fire alarms generation, they refer to the most updated environmental/meteo measurement data log made available at the CC from the relevant RDCU components. The calculated FWI values as well as the relevant environmental/meteo measurement data were as follows: Table 3: FWI values calculated for different meteorological conditions Location RDCU#1 RDCU#2 RDCU#3 Temperature Humidity (oC) 25.89 26.17 25.83 (%) 50 49 49 24h Accum. Wind Wind Precipitation Speed Direction (mm) (km/h) 0 0 0 18 16.2 19.8 N NE NE FWI 7.9 7.5 8.8 Fire Danger Info MEDIUM MEDIUM MEDIUM
Following the RCU data fusion which resulted in the fire alarm generation, a flashing icon of a fire appeared on the GIS map at the expected ignition point position wrt artificial smoke source, i.e., the terrace of the building on top of which smoke producer was initiated (See Figure 50). Also, an accompanying sound alarm was produced from the speakers connected to the CC PC Station. The end user requested and watched on-demand image data, in particular luminance data, from the RDCU#3 vision sensor through the user consoles GUI, which was made available at the CC user console within a couple of seconds. On top of the image (luminance) data, the specific tile referring to the high fire/smoke detection probability was also automatically indicated with a red border, which was found very useful by the end user. Moreover, through the available PTZ and preset position control commands on the user consoles GUI, the end user then pointed the RCU panoramic camera towards the corresponding area under alarm (i.e., forest area under FOV of RDCU#3), as well as requested and watched live panoramic image stream from the RCU panoramic camera in which the artificial smoke source produced was clearly visible (See Figure 51). Following the fire/smoke alert geolocation on GIS map, the end user initiated then a fire propagation prediction simulation through the users console GUI with the given characteristics of the actual weather/meteo conditions at that time. After a couple of seconds, the GIS map is updated and the fire propagation is displayed as a new map layer including the respective contour
Page 71
maps (See Figure 52). Contour maps generated and displayed on the users console GUI matched the actual ignition point, the direction of wind (i.e., North-East) as well as the simulated time period (i.e., 4hr 30min). Apart from the artificial scenarios described above as part of CVT tests which aimed to demonstrate the compliance of the SFEDONA system to its Specifications and, consequently, to User Requirements, the SFEDONA pilot system deployed at the End Users site was also operated and used by the End User on a daily basis for at least 4 months, covering as much as possible the critical fire summer season (CVT-7). During this pilot period, the End User conducted an ordinary day-to-day operation of SFEDONA pilot system, consulted Space Hellas in case of any problem arisen and also evaluated the pilot systems use and operation by providing useful recommendations and feedback. Also, during this pilot period, no actual fire/smoke incident occurred except for those fire/smoke incidents artificially generated in the framework of the CVT tests, which were successfully detected by the system and for which further details were provided above.
Figure 50: Users console GUI indicating users notification on fire/smoke alarm. In particular, flashing icon of detected fire event as well as RDCU vision sensor image data over the respective area under alarm are depicted.
Page 72
Figure 51: Users console GUI indicating users notification on fire/smoke alarm. In particular, panoramic camera stream over the respective area under alarm is depicted, where the artificial smoke source is clearly visible.
Figure 52: Users console GUI indicating fire propagation prediction simulation.
Page 73
Overall, based on the complete field validation results, the end user was satisfied with the use and operation of the SFEDONA pilot system as well as in terms of its capabilities and characteristics, i.e.: Accurate detection a fire/smoke incident. Early generation of respective fire/smoke alarms. Accurate prediction of a fire events propagation. GUI for panoramic image stream request and acquisition as well as for PTZ and preset position control commands. Received image quality from the RCU panoramic camera. Time response from one to another RCU panoramic camera image request and acquisition. GUI for on-demand request of RDCU vision sensor image data Received image quality from each RDCU vision sensor. Available select & zoom options on the GIS map through the user consoles GUI. GUI for fire/smoke alert identification and geolocation on GIS maps. GUI for fire propagation prediction. Moreover, the end user indicated some possible enhancements for a future release of the system, which will be taken into account for the commercial roll-out phase of the SFEDONA product. Based on the overall in-lab and field validation activities conducted, the performance of the SFEDONA pilot system was fully compliant to the System Specifications and User Requirements. Note also that the End User has requested the SFEDONA pilot system to remain in place for relevant user operations beyond the planned pilot period.
Page 74
10.
PROJECT NETADDED
10.1 Overview
Why NETADDED? Today, broadband connectivity is as important for economic prosperity and quality of life as decent road and public transport networks. Through their immediate and far reaching connectivity, satellite communications allow to extend broadband networks to rural and isolated areas. R&D projects like TWISTER (FP6 IP, Aeronautics & Space) have led to commercial deployments of hybrid satellite-wireless solutions in Europe where ADSL and cable modem solutions are not available, demonstrating the capability to design, deploy, operate and maintain high quality satellite broadband Internet access services for the benefit of public services, SMEs and households. Countries outside Europe are dealing with the same e-Inclusion issues and in addition, they have specificities that necessitate the adaptation to the local constraints. NETADDED goal has been to develop and validate technical features improving the deployment and operation of such hybrid satellite-wireless technologies, in coherence with the growing demand of broadband communications in the International Cooperation (INCO) countries, linked in particular to education & health applications, which are essential for developing countries. What is NETADDED? NETADDED (New Technologies to Avoid Digital Division in e-Divided areas) is a project led by EADS Astrium which has been selected for co-funding by the European Commission in the 3rd Call for proposals of the Aeronautics and Space priority of the Sixth Framework Programme (FP6). The project has been running between the 1st April 2007 and the 31st October 2009 and has consolidated the 13 participants Consortium as active player in bridging the Digital Divide in INCO countries.

The project objectives are two-fold: 1. Development objective: to support education & health development in Africa & Asia 2. Technical objective: to provide a sustainable technical solution adapted to the specific environment. The suitability of the proposed network solutions has been evaluated in terms of performance, quality of the proposed applications & contents and level of user satisfaction through validation sites selected with the support of national and regional public authorities. An important effort has been concentrated on the usage and evaluation of sites using the tools and procedures put in place in the deployment phase and optimised during the operation. The evaluation has been performed at two levels:
Assessment of network usage and reliability through the monitoring and supervision tools put in place at the NOC and on each of the sites. Evaluation of the quality of the proposed services as well as the level of user satisfaction thanks to an evaluation questionnaire.
Page 75
Figure 53: NETADDED validation sites
Education
Distant learning in Cambodia Broadband Internet access for rural schools & hospitals in Morocco
Access to educational contents for NGOs in Burkina Faso
Healthcare
Remote medical training in Benin
Continuous medical education on laparoscopic surgery for medical universities in Turkey and Morocco
Agriculture
Wireless Sensor Networks for precision agriculture applications in France Access to broadband services for rural communities in Greece Intelligent wireless networking for rural tourism in Turkey
Tourism & E-business
Figure 54: NETADDED application domains
Page 76

The validation sites have allowed to test and validate under real conditions the research and innovation activities, aiming at improving the conditions of deployment and exploitation of hybrid satellite-wireless solutions, which are at the centre of the NETADDED project. 10.3.1 Implementation of a compact and robust transportable broadband satellite based solution One of the main goals of NETADDED is to define the best satellite-based solution adapted to the real field conditions of Africa. The satellite terminal must be compact and robust, easy to deploy, transportable and suited to weather and temperature conditions. The NETADDED project has analyzed the user requirements for a transportable terminal adapted to the field conditions in African countries. A trade-off between a number of solutions has been carried out resulting in the selection of ABC S@t solution developed by CNES based on Inmarsat technology. The transportable satellite terminal is based on the integration of COTS elements, put together in a compact and robust packaging. Shock and vibration have been taken into account for the study of transportation conditions of the terminal. Special attention has been paid to the resistance of the selected equipments to temperature cycles, humidity and dust. Following the user needs, the transportable terminal has been completed by the definition and development of a software application for the optimization of bandwidth use in the domain of elearning applications. This first prototype has been used by a local NGO in Burkina Faso during a basic education campaign (October 2008 March 2009). A set of tests have been defined and carried out in the field, allowing to:
Validate the proper operation of the terminal in terms of performance, reliability, robustness and autonomy; Identify limits and necessary improvements (software or hardware); Test its operability by typical non-technical users; and Analyse the usage.
Internet access, videoconferencing and sharing of medical content were the main applications used during the test campaign. The main outcomes following users feedback on the usage of the transportable solution are summarized in Table 4. Table 4: Main outcomes on transportable terminal usage in Burkina Faso
Page 77
Transportability Resistance to shock and vibration Resistance to high temperature, humidity, dust Rapidity of deployment
The light weight of the terminal (12 kg) allowed to transport it easily by car or motorbike The terrible state of roads raised some minor problems of stability of the suitcases external connectors. Equipments placed inside the suitcase were well protected. Neither high temperature (36C on average) and humidity nor the very dusty environment revealed any visible failure. On average 6 minutes by non technical skilled NGO educators. The batteries had an average autonomy of 2 hours. They had to be charged every night after the learning session. During the sessions, solar panels were largely used to complement the batteries, along with a generating group when necessary. User friendly terminal, except for the LCD touch screen not well adapted to the sunny environment of Burkina Faso, and complexity on cabling and adapters for external power supply sources. Duration average 28 minutes per session to be added to the 6 minutes of terminal set-up. Both connected and off-line modes were used. Both cabled and wireless connection modes were used. 105 Mbytes of total amount of exchanged data using Inmarsat system during the test campaign, for 670 .
Autonomy
User interface
Usage
Operational costs
Figure 55: Transportable terminal and its foldable solar charger
Figure 56: Validation of the transportable solution in real operational conditions
Page 78
10.3.2 Definition and field testing of procedures for simplified installation by customers The installation of a bi-directional satellite terminal, especially the pointing of the dish, is quite cumbersome while it needs to be done accurately. It requires the pointing of the dish (azimuth, elevation and cross polarization) and the parameterization of the Customer Premises Equipment. This type of installation requires a certified installer, having followed a training to be able to do the installation correctly. These certified installers are mostly based in the European countries with an established market. Organizing the installation of a satellite terminal in a country in Africa can be quite a complex and expensive operation. The development of an easy installation method could enable the end user to install his terminal by himself. The method consists of a set of logical steps defined in a manual or an interactive multimedia presentation and a set of simple, easy to use tools such as a GPS or a compass. The ultimate objective would be a stand-alone solution where neither an expert installer nor a service operator has to intervene. The ELU system (Siemens Easy Line-Up for Satellite Networks) has been employed as the solution to address the terminal installation process. It requires only a laptop computer to assist the customer in dish pointing and cross-polarization adjustments. Performance was measured by checking the quality of the signal after the satellite terminal installation. In general, the tests showed that the usability of the system is quite good. Obviously, we cannot expect from users with no technical expertise to do as well as an expert technician, and this was evident from the tests. However, the system did allow all users to perform an acceptable lineup and establish the necessary communication link.
Figure 57: ELU (Easy Line Up) user guide interface
Figure 58: ELU test topology
Page 79
10.3.3 Improved autonomy in terms of maintenance and operation of both satellite and local loop segments Satellite terminals are very often used in remote locations with limited accessibility and limited alternative communications means. Hence, it is important to set up a robust and flexible remote control and maintenance methodology for the Customer Premises Equipments. The NETADDED project has defined and prototyped a remote control mechanism that enables the local loop operator to remotely monitor in real time the whole satellite (and wireless) installation. This mechanism allows to: Figure 59: Remote control system
Monitor both satellite and local loop segments, from both provider and user sides Issue alerts about network failures Perform remote interventions (such as a hardware reboot) for problem solving or QoS improvements
The tests were run in a simulated environment allowing to test the remote control in three different network environments. As a result we had the opportunity of testing the framework in a very demanding scenario which involved more than 1500 network elements. The tests run in the simulated environment have then been complemented by further testing in real conditions, which has taken place at the end of the second reporting period, after the installation of the Embaros site was carried out. These tests confirmed the results obtained in the simulated environment, as expected, and justify the potential of the remote control framework.
at provider site
Figure 60: Remote control hardware solution at user site
Page 80
10.3.4 Integration performances
of
satellite
with
new
wireless
technologies
having
improved
Among several wireless technologies considered during the NETADDED study, the results of activities on Wireless Sensor Networks are recalled here A soil moisture platform based on Wireless Sensor Networks dedicated to precision agriculture has been specified, developed and tested in laboratory. Besides, a fast and accurate mathematical technique to estimate available bandwidth in wireless mesh networks called SLOT has been formulated and validated by simulation. The LiveNode platform has the following hardware and software components:
LIMOS LIght weighted Multi-threading Operating System based on LINDA concept, CIVIC Communication Inter Vhicule Intelligente et Cooprative: Embedded wireless communication protocol, LiveNode LIMOS VErsatile Node: component-based concept adoption enabling to implement wireless sensor node such as wireless soil moisture sensor node, WiFi-ZigBee gateway etc. by using the same hardware.
Figure 61: Wireless sensor prototype The soil moisture WSN platform has been evaluated under real outdoor conditions in Allier (France) validation site and the SLOT tool has been used to estimate the available bandwidth of the Allier validation site experimental platform.
Figure 62: SLOT test topology in Allier (France)
Page 81
10.3.5 Provide services differentiation on the satellite segment In the frame of NETADDED different services differentiation methods on the satellite segment have been investigated:
Methods to improve quality of service dynamic control, directly by the end-user, with a QoS device installed at hub level Methods to control QoS through a low cost device to be installed on site Differentiation of services for several IP based videoconference applications QoS policies to improve the quality of image in videotransmission in different application contexts
Besides, QoS management specially adapted to the user requirements so to enable sharing of the satellite resource by user having different usage profiles (typically videoconference with guaranteed bit rate and Internet like services) and per use tariffs to reduce costs for the end user has been implemented. The issue of service differentiation cannot be addressed efficiently without a powerful traffic monitoring system so as to monitor and control how the network and the users behave once the appropriate QoS policies are implemented. It has been a major task in NETADDED to design and develop a service differentiation system with fully embedded traffic monitoring system. The development and integration to the MEDSKY2 platform of an efficient satellite network monitoring tool, available on-line and in near real-time, with appropriate time resolution and adapted graphs for quick action, has been achieved. In addition, the QoS management and rules have been completed and adjusted several times to take into account experience feedback. Also a new software development on the videoconferencing application has been launched with the purpose to enable a better multicast management as well as a better integration with satellite networks and TCP acceleration features, along with the management of powerpoint slides.
Figure 63: Satellite network monitoring tool
MEDSKY is a flexible, scalable and standards based Telemedicine solution for Hospitals, clinics, rural medical centres, as well as general practitioners. The MEDSKY service has been developed by TTSA (Telemedicine Technologies SA) jointly and Eutelsat S.A. for "Telemedicine & distance Learning".
Page 82
10.3.6 Implementation of a low cost distant learning system adapted to satellite-wireless broadband infrastructure When it comes to e-learning and distant learning, the number of products and services offering can be overwhelming. Some are high-end, full featured and expensive, others are cheap or even free but unreliable. Connected Schools NGO aims at providing professional education to disadvantaged children in emerging countries by means of distant learning to compensate for the lack of skilled teachers there. The objective of the activity was therefore to evaluate and integrate various hardware and software to implement a low cost distant learning system (ie server and client) with many functionalities as possible in the following list: audio conferencing, whiteboard sharing, desktop sharing, video call, video broadcast, video conferencing, chat, Internet access, fast access to stored training content, email, forum. The characterisation of various distant learning hardware and software tools has been completed, allowing the implementation of a low cost distant learning system (ie server and client).
First a set of software was selected on the basis of three criteria: cost, feature set and fame. The performance of each tool has been detailed and quantified for each criteria and finally the goal was achieved to provide a reasonably reliable, user friendly, well performing collaborative work toolset at no cost. For the hardware evaluation the primary factor considered was cost and the second was power consumption. The combination of low power notebooks with the use of LED projectors has made possible the concept of a single solar panel powered distant learning classroom
Figure 64: Performance comparison of videoconferencing tools Whiteboard sharing performance comparison
Page 83
10.4 Results
The NETADDED project has deployed and operated 14 validation sites, corresponding to a total of 14 satellite terminals installed in 7 different countries (Benin, Burkina Faso, Cambodia, Greece, France, Morocco and Turkey). These sites have allowed:
to assess the added value of satellite (combined or not to wireless) with respect to terrestrial solutions alone, to bring and create adapted educational and medical contents for INCO communities, the development, promotion, take-up and use of innovative IT applications in the domains of education, healthcare, agriculture, e-business and tourism.
Out of the 14 validation sites, 13 validation sites will remain operational, representing 93% of all deployments.
Page 84
11.
PROJECT SISTER
11.1 Overview
SATCOM in Support of Transport on European Roads (SISTER) is a research and development (R&D) project co-funded by the European Commission under Framework Programme 6 (FP6). The project is run under the European Commissions DG Enterprise and Industry with a budget of 10.5 million. The SISTER project brings together major players from the ITS, space and services industries in the consortium consisting of 20 partners, coordinated by Avanti Communications. Satellite navigation services have already proved their value in an enormous range of road transport applications and many new initiatives are planning to take advantage of the Galileo satellite services in the years ahead. A large proportion of these applications require one or twoway communications services in order to function. In many cases to date, terrestrial communications such as GSM and GPRS have been employed. However, there are numerous circumstances where these technologies may not be sufficient to meet the communications requirements, such as: High availability applications, such as emergency alerting, where communications coverage must be comprehensive and robust; High reliability applications, such as dangerous goods tracking, where guaranteed Quality of Service is required; High capacity demand applications, such as the updating of digital maps. Here terrestrial infrastructure is often too expensive for the distribution of large volumes of data to many users using point to point communications. In many of these applications, satellite communications, whilst not replacing the need for terrestrial services, can complement them and lead to a superior overall solution. The SATCOM In Support of Transport on European Roads (SISTER) project promotes the integration of satellite and terrestrial communications with GALILEO to enable mass market takeup by road transport applications. The scale of the road transport market combined with innovative solutions to road transport problems requiring the integration of location based services with communications makes this market potentially extremely attractive. Regarding its R&D Objectives, the SISTER project was intended to address the ITS and SATCOM markets by better understanding the needs of both. Through detailed analysis and development, the project planned to realise unique opportunities in the ITS market and produce both a commercially and technically viable product. A description of the main R&D objectives can be found below. Applications. SISTER approached the challenge of introducing SATCOM to ITS by analysing the capabilities and requirements of both. In the first stage, the project focused on learning about the current ITS market and addressed services where the need to improve communications capabilities was identified. In parallel, a number of different communications media were studied to better understand their strengths and weaknesses. Business considerations were given to assess the commercial viability of the selected options. The study resulted in a selection of applications being identified, researched and developed. The SISTER applications requirements were matched against specific capabilities of the satellite communication such as broadcast and bi-directional service.
Page 85
Communications. A similar analysis was carried out to select the best bearers for the SISTER applications. Factors such as coverage, latency, cost and availability were fully investigated to ensure they met the requirements of the applications. A Gap Analysis suggested however that no single communication medium could meet all the expectations of the ITS market. This finding had an impact on the other part of the project development of the satellite transceiver. Satellite transceiver. There are currently no products targeted at the mass market that integrate satellite positioning, satellite communications and terrestrial communications. The market opportunities for satellite positioning and broadcast / multicast services into vehicles are considered to be significant. The SISTER transceiver is expected to evolve into a mass production device providing superior communications capabilities for the ITS market. Integrated antenna. Following development of an integrated transceiver, an obvious requirement was to develop an integrated antenna that, on the one hand would fully support all communications links at any time, and on the other would be attractive for the automakers and transport companies. Positioning. Software defined radio has the potential to revolutionise satellite navigation services. Software receivers will enable satellite navigation services to be readily upgraded with a simple firmware upload (e.g. to support EGNOS, GPS L1/L2C/L5, or GALILEO signals), moving the GNSS industry and associated businesses from being product driven based on the sales of electronic devices, to being service oriented focused on the provision of applications. Software receivers will facilitate revenue generating, value added commercial services making use of integrated satellite navigation, telecommunications and other services. The reconfigurable GALILEO receiver will utilise existing software GNSS receiver components to prototype a GNSS software receiver which can be reconfigured and upgraded through updates distributed by SATCOM. Such re-configurability is planned for the next generation of GPS satellites and is expected to be included in the requirements for a second generation GALILEO system. Once demonstrated the intention would be to plan an enhancement to the SISTER Satellite Transceiver (SST) as an upgrade of the device developed during this project. The Real Time Kinematics (RTK) demonstration will make use of the University of Nottingham /Lecia Geosystems RTK Network, the SST, and off the shelf aviation grade Inertial Navigation System. RTK is not currently a mass market technology, although advanced ITS applications (lane departure warning) will require the highly accurate positioning that RTK can provide. In the SISTER project RTK will be advancing the state of the art by bringing it closer to the mass market.

The analysis performed at the beginning of the project suggested that no single communication medium could support requirements of the ITS applications. Moreover, a choice of satellite communication system that would fill up the gaps in the terrestrial capabilities and be suitable for the ITS market proved challenging. Research of ITS applications recognised their very different nature and requirements. The challenge therefore, was to find such a selection of communication options as to ensure satisfying the very different needs of the most popular and market attractive applications. All these factors contributed to the development of the SISTER architecture (shown in Figure 65).
Page 86
Figure 65: SISTER Architecture The SISTER system is GNSS based using an integrated communication platform, managed by the Middleware on the vehicle side and by the Data Distribution Server (DDS) in communication from the back offices. The back offices send satellite data via the DDS, which in turn selects the satellite network to be used through a configurable profile. The SISTER Satellite Transceiver in the vehicle combines GPRS, Iridium and Thuraya modems for bi-directional communication and WorldSpace and Solaris W2A for reception of broadcasts of ITS relevant data.
Page 87
Figure 66: SISTER Satellite Transceiver and Integrated Antenna. Selected applications in the vehicle can communicate with their back offices using the SISTER common communication solution. Traffic is prioritised in the SST and the traffic management entities ensure the best communication channels for a given request. Having CALM (Communications Access for Land Mobiles) based protocol, SISTER can accept any new application that is compliant with its protocol.

A number of ITS related applications are trialled within SISTER and a public demonstration has taken place in Nordwijk, Netherlands. 11.3.1 Road Use Charging Electronic road user charging describes a technical implementation of the road pricing concept. Current road user charging (RUC) systems are mainly based on dedicated short range communications between the vehicle and the infrastructure or GSM/GPRS cellular communication. SISTER investigates the application of a satellite communication link for EFC (Electronic Fee Collection). The idea of using SATCOM for RUC was to respond to the problem of ever increasing number of vehicles on European Roads and relate to emerging concepts of panEuropean road pricing.
Page 88
The SISTER broadcast communication service will be used for distribution of RUC data files required for regular updates at the OBU. These are tariff and map data and software updates. The SISTER bi-directional service will be used for the exchange of toll records between RUC OBU and RUC back office. The RUC application receives GPS data from the SISTER Satellite Transceiver, generates the toll records, and calculates the toll charge. Afterwards, the OBU passes the toll records to the SST for transmission. The checks the availability of Thuraya, Iridium, and GPRS and chooses the most suitable channel. The toll record data will be transmitted to the RUC back office by using the chosen communication channel and the back office sends an acknowledgement message via the same communication channel back to the RUC application. 11.3.2 Map Updates The Map Update applications aim at studying and demonstrating use of satellite broadcast in sending large volumes of data to a large number of users. Expected advantages of using satellite communication for such data transfers are mainly cost savings, coverage improvements and increased reliability. The Map Update demonstrations within the SISTER project focus on three major demonstrators: Incremental Map Updates - Updating attributes of the map (e.g. speed limits or signs). Tile updates - Updating parts of the map (replacing tiles). POI update Updating information about Points of Interests (e.g. petrol stations, hotels, etc). Map Updates are distributed using the Data Distribution Server (DDS). The DDS collect files of different sizes from several back offices or clients and sends them through the broadcast service to the SST in the vehicle. The Middleware is responsible for reassembling the files and forwarding them to the destination application. 11.3.3 Dangerous Vehicles and Goods Management The Dangerous and Valuable Goods Management (DVGM) application is aimed at investigating suitability of satellite communication in combination with terrestrial communication in the area of transport. An increasing number of freight hauliers want to be kept informed about the whereabouts and condition of their cargo. The accuracy of location and detailed information about the cargo is expected to constantly improve. DVGM Customers want to be certain that no unauthorised parties have access to their cargo during a trip. For this reason electronic locks are installed. These locks make sure that the doors of a trailer can only be opened at certain locations and only when allowed to do so by an officer in the control room. This functionality requires a permanent availability of communication and knowledge of the current position. Dangerous goods add another dimension because of the safety risks but have similar requirements concerning communication (always and everywhere). The dangerous Vehicles and Goods Monitoring (DVGM) demonstration within the SISTER project will focus on a number of different areas: DVGM Message Updating by broadcasts Bi-directional DVGM Message Updating SeCu-Lock control Sensor information
Page 89
In SISTER, the DVGM application uses bidirectional communication between the back office and the SST. To simulate the effect of dropping connection, the Test Manager may interrupt or block a communication channel. For each communication channel the same test will be performed. This can be done in parallel by instructing the Middleware to send the same message via different channels. Results should help in estimating improvement in availability and latency compared to any single communication medium. 11.3.4 Emergency Calls The objective of the SISTER eCall application is the validation of SATCOM as a facility for the panEuropean eCall-services. This demonstration enables the evaluation of SATCOM as a complimentary communication method for the eCall-services. The results of the SATCOM based data communication will be compared to the use of terrestrial data communication for critical functions. The eCall testing in SISTER will be based on the eCall architecture, which uses the GSM network to communicate between the vehicle in the incident and the Public Service Answering Point (PSAP). The eCall service uses the single pan-European emergency call number 112 to ensure that eCall has full roaming capabilities in Europe. In SISTER, the in-vehicle transceiver system will be integrated with the SISTER Satellite Transceiver in order to provide an additional coverage for areas with a weak GSM signal. This will allow eCalls to be made in areas currently not serviced by terrestrial networks (see Figure 67).
Figure 67: SISTER eCall concept. The focus of the trials will be on sending and receiving the data messages and no voice calls to PSAP will be established. The trials will involve both Iridium and Thuraya services to provide comparison data between the terrestrial networks and the competing satellite networks. 11.3.5 Enhanced GNSS Software defined radio techniques are used to implement operations commonly done in hardware such as filtering and frequency conversion. At the expense of usually lower processing capabilities compared to ASIC (Application Specific Integrated Circuit), great flexibility and low recurring costs are achievable. A GNSS receiver is usually a combination of hardware and software. Depending
Page 90
on how much of the receiver is actually implemented in software, a different classification can be given to it The development of the GNSS software receiver specifically designed for road user charging explores the advantages of tailoring a highly flexible and low cost receiver technology to perform best in a challenging scenario affected by signal attenuations and reflections. In addition, such receiver allows embedding redundancy checks and digital signatures to the very core of the baseband signal processing engine, with an obvious benefit when addressing liability critical applications The main objectives of this part of the proof of concept are to demonstrate the authentication and the reconfiguration of the GNSS software receiver. Along with these, general receiver performances as well as other wireless networks availability (WiFi, GSM, SDB service) and environmental condition logging would be desirable as well. 11.3.6 Real-time Kinematics The RTK study has a two-fold use: the first is to push the limits of the best performing navigation devices on the market when driving in an urban environment, thus providing the most accurate reference navigation track possible. The second is to assess the feasibility of broadcasting wide area GNSS augmentation data over satellite communication networks using advanced modelling and compression algorithms. Early results have shown that: A solution involving a one-way data broadcast is possible, so the number of users is not limited by the need for a back channel Subsequent investigations have indicated that 120kbps would be required to send full-rate reference data from a European reference network Latency of up to 10 seconds in the delivery of the correction messages can be tolerated without significant loss of accuracy. 11.3.7 Noordwijk Demonstrations The demonstration in Noordwijk, Netherlands, was the first public demonstration of the SISTER communication solution prototype. All applications described below were demonstrated simultaneously following a scenario for a predefined route. Attendees had the opportunity to experience the whole system as demonstrations included two sessions run in parallel: in the car and in the back offices of participating applications.
Page 91
Figure 68: Inside the SISTER test vehicle Participants were also able to drive a specially prepared vehicle equipped with screens, which displayed real time changes in the applications. A moderator in the vehicle guided viewers through the demonstrations, explaining specific features of each application. On the other side of the system, the rest of participants were able to track the vehicle on a map and observe back office mechanisms like triggering new updates or receiving new messages from the vehicle.
Page 92
Figure 69: Demonstration route in Noordwijk The route was run through a series of different environments ranging from urban to semi rural to demonstrate different strengths and weaknesses of each communication channel. 11.3.7.1 Road User Charging During the RUC demonstration, the tariffs were altered and the new ones were broadcast to the vehicle. An in-vehicle RUC application recognised a chargeable part of the road and initiated charging procedure by generating and sending toll records to the RUC back office. The audience were able to see the chargeable road segments in a graphical way. Generated and sent toll records were displayed in a log. In the back office it was possible to see over which communication medium the records were sent. 11.3.7.2 eCall eCall messages were sent from a various locations along the route. Participants in the vehicle were able to send a message themselves and track progress of the message until acknowledgment was received from the eCall back office. The audience watching back office parts of the demonstration were able to see an alert coming in, together with the information required by emergency services. 11.3.7.3 Maps Update Speed Limit updates along the demonstration track in Noordwijk was shown. Dedicated spots along the route were broadcasted via WorldSpace for which simulated speed limits were imposed. The main objectives of the demonstration was to show how broadcasted updates are received while driving along the track and how updates are processed by the in-vehicle application to provide a warning and advice to the driver of speed limit changes ahead on their route. 11.3.7.4 POI update New POIs were generated externally by the customer (POI Client) on demand and submitted to the back offices server. The POI data entered and released by the customer was transferred from the back office server via Internet to the Data Distribution Server (DDS) for satellite broadcast. The DDS forwarded the data to the selected satellite system provider (in this case WorldSpace). The audience was able to see the screen of the POI back office user interface, providing the following functions: Creation a modification of User POIs Creation of send jobs to provide a selected set of POIs to the DDS Log file request to the DDS to check state of send job(s) Settings for operation With this, the audience could experience setup and sending of POIs, observe responses from the DDS and follow the status of current send job(s). The broadcasted POI messages where received by the SISTER Satellite Transceiver and forwarded to the Onboard Navigation Unit. The navigation application identifies received POI data and provides POI update information to the user HMI (Human-Machine Interface). The audience could observe when received POI data, validated by pre-processing on the SST, was forwarded to the Onboard Navigation Unit: the navigation application displaying the info new
Page 93
POI(s)I received. The driver could, if required, acknowledge the message to begin navigation to the received POI. In this case, a route to the new destination was calculated automatically and guidance could be started. 11.3.7.5 DVGM The demonstration of the DVGM application showed that messages can be sent using different profiles and therefore different communication channels in a sequential and parallel way: Every 10 seconds a position and (emulated) temperature of the cargo was sent to the back office via GPRS; if this didnt succeed within 30 seconds Thuraya was tried and if that was unsuccessful, Iridium was used. Because it is quite likely that GPRS will be available, the two other communication channels may not be seen as operational. Note that in real life a more complex scheme is used in which only after a certain number of failed (low urgency) messages a more expensive communication channel will be used and with a lower transmission frequency. To demonstrate the effect of poor GPRS transmission, the position and temperature message was sent with a different profile which only used Thuraya and Iridium. Part of the tour was defined as a bad GPRS section, based on position. The transmission frequency was reduced to once per minute, but the messages still contained the 10 seconds position and temperature measurements. For demonstrations, two profiles were used: one that favoured Thuraya over Iridium and one that favoured Iridium over Thuraya. Depending on the actual availability and latencies the messages may arrive out of order. An alarm message concerning the dangerous cargo was sent by all channels in parallel. For demonstration purposes, the action was triggered by nearing a specific location, but a button was also available that could be used to trigger the message by a user. In the back office it could be seen that messages arrived via different communication channels and the latency of each message was also displayed.
11.4 Results
The SISTER project is expected to end in June 2010, and is currently collecting and analysing trial data. The SISTER results will be provided upon the completion of the project.
Page 94
12.
PROJECT TANGO Overview
12.1
The GMES (Global Monitoring for Environment & Security) services are currently being developed to support public policy makers needs in the domain of environment and security, and rely on a comprehensive Earth observing system, using space borne and in situ techniques. The satellite telecommunications will be a key component of the future GMES architecture, enabling to expand GMES services and to enhance their performances where unmet needs can be identified: Improvement of the service area through the dissemination of the GMES applications wherever it is needed; reach communities with no other solutions for instance in the ocean or following a natural disaster-; deployment of Adhoc networking for crisis management, Improvement of the reactivity and freshness of the data through faster scene and in-situ data collection Speed up the transfer of data expected as these prototypes services become operational and allow higher volumes to be processed TANGO implements a bottom up approach to identify the requirements for telecommunication services that are not met for the delivery of GMES services. The consortium structure enables privileged crosslinks with key GMES projects addressing all GMES themes.
Page 95

TANGO demonstrations contribute to two European Commission identified fast tracks (the marine and emergency response core services) through the integration of satellite telecommunication solutions with on-going GMES developments in the framework of security and crisis management, fisheries management, maritime surveillance and humanitarian aid. The table hereafter provides the overview of the set of demonstrations carried out in the frame of the project. Due to the large number of demonstrations, only some of them are detailed in the documentation.
Demonstration scenario
On-field crisis management On-field crisis management
Place
Elancourt Cahors
Date
September 2008 December 2008
Satcom solutions
PMR satellite transportable solution Transportable stations
RECOVER, MOBIDICK and TRACKS trucks Hybrid terrestrial
satellite solution GSM/DECT/IP over DVB-RCS SES ASTRA2Connect Fisheries monitoring Fisheries monitoring UAV Fisheries monitoring Azores Maritime Surveillance (Ship tracking) Maritime Surveillance (Met-ocean observation) Humanitarian Aid Vulnerability Mapping RESPOND Security (Evacuation from a crisis area) Risk & Crisis Fisheries management Comoros Italy Azores Ocean Atlantic Baleares Vietnam Madeira April 2009 September 2009 May 2009 March to June 2009 August 2009 May 2009 May 2009 SES ASTRA2Connect Iridium Simulated Swift Broadband BGAN LRIT / iridium, AIS ARGOS 3 BGAN, ELISEO (Iridium) RECOVER, BGAN, ELISEO (Iridium) Security
Maritime Surveillance Humanitarian Aid
Figure 70: The list of TANGO demonstrations
Page 96
12.2.1 TANGO first Risk & Crisis demonstration run in Elancourt
The first Risk & Crisis management demonstration was performed in Metapole, EADS SN premises in Elancourt, France, on the 15th of September. The PMR by satellite solution was developed in the frame of the TANGO project to answer to collected user requirements in the domain of crisis management and public safety: secure and robust voice communications for rescue team management, interoperable system to keep contact with other rescue forces, efficient data information system to collect and transmit information of current situation and evolution of mission. The hybrid solution combines a Tetrapol Projectable Telecommunication Network Solution, to be autonomous as much as possible and to satisfy quick deployment and transportation constraints, and satellite telecommunications solution to ensure rapid deployment of links between two points when terrestrial telecommunications are not available or out of service. The demonstration of the solution was conducted on a typical crisis scenario in presence of OTAN, French Gendarmerie and French Civil Security, who provided positive feedback and were convinced by the technical solution.
Figure 71: Some pictures of the Cahors demonstration
Page 97
12.2.2 Crisis Management Demonstration in Cahors/Lalbenque
EADS Astrium and their partners ran on the 11th December 2008 in Cahors/Lalbenque a demonstration showing the added values of Satellite Telecommunication solutions in crisis management. The demonstration made a specific focus on the adaptability and scalability of these solutions in the management of evolving crisis and the dissemination of GMES services (Global Monitoring for Environment and Security). Practically all the solutions as well as the crisis management applications developed/adapted in TANGO were used for the demonstration purpose. Among them are: Transportable stations RECOVER, MOBIDICK, TRACKS implementing hybrid terrestrialDVB-RCS solutions, Fixed stations ASTRA2connect, Solutions and applications dedicated to crisis management: ELISEO, RISKFRAME, Common Telecommunications Service Platform (CTSP). The demonstration had different objectives: o Show the adaptability of TANGO satellite telecommunication solutions to the evolutions of crisis needs. This is possible owing to their scalability and modularity characteristics. o Illustrate the added value of these solutions to the enhancement of GMES emergency services. This covers all phases from the Preparation, Response to the Recovery.
Figure 72: Overview of Satellite Telecommunication solutions role and use in the demonstration
Page 98
A comprehensive crisis management scenario was deployed. Starting from a fire in a spotted area, the crisis spread and raised risks of contamination over several areas. Fire brigade team organisation evolved with the dynamic situations. The use of different satellite telecommunication solutions according to the evolution of crisis was shown. The purpose of these solutions was both to offer communications to on-field areas as well as to disseminate GMES emergency services. The use of CTSP to tailor them to on-field needs was shown. This was part of TANGO risk & crisis demonstration specificity.
Figure 73: Fire Brigade team of SDIS 46 in preparation for the demonstration run
Figure 74: Use of CTSP to select satellite solutions adapted to crisis management needs
Page 99
The demonstration was a success. This was possible owing to The strong involvement of the Fire Brigade of Lot (SDIS 46 Service Dpartemental dIncendie et de Secours du Lot) both in the scenario definition, scenario run and feedback. The attendance and feedback from the end users such as Cahors local authority, Humanitarian aid NGO and GMES service provider such as MapAction, European Public Safety organisations. The GMES services kindly made available for the demonstration by GMES service providers such as: CNES, Infoterra, GMV, Sertit, MapAction. The logistics and the support provided by the aerodrome of Cahors/Lalbenque.
Figure 75: Overview of different transportable stations: MOBIDICK, RECOVER, TRACKS in the aerodrome of Cahors/Lalbenque
Figure 76: Use of Satellite for communications and GMES dissemination
Page 100
12.2.3 Fisheries Surveillance Demonstration in Moroni, Comoros Demonstration background The European Commissions Joint Research Centre (JRC) and Navigs Sarl successfully tested with their end-users, the Fisheries Monitoring Centre of the Comoros in Moroni, a new architecture developed in the framework of the TANGO project aiming at providing cost efficient near real time fisheries monitoring capability to remote and isolated areas of the globe. The TANGO demonstration held in the Comoros from 30 March to 8 April 2009 was designed to test the feasibility of bringing real-time vessel detection system (VDS) capabilities to a country that is physically remote, suffers from a rudimentary infrastructure and weak telecommunications services. Because the exclusive economic zone (EEZ) of the Comoros is one of the Indian Oceans key tuna fishing grounds, and because the country, one of the poorest on earth, has no monitoring, control and surveillance assets in the form of patrol vessels and patrol aircraft, VDS could be the key to determining the level of illegal fishing in the EEZ.
Figure 77: Vessel Detection System
The demonstration aimed at evaluating the benefits of satellite telecommunications means in complement to the already mature VDS (Vessel Detection System). The TANGO fisheries team has worked together with SES ASTRA TechCom, Newtec and EADS Astrium to implement the telecommunications part of the VDS architecture. The architecture relies on the provision of dedicated satellite communication means to transport near real time satellite imagery scenes from a data relay ground station in Europe to the FMC, thus enabling a local VDS capability which would have not been possible with the limited capability of Comoros local telecommunication infrastructure. Details of the demonstration Though the demonstration was originally designed to take place in two phases, difficulties in supplying required equipment on-site necessitated a scaling-down of the effort to a single phase. In early March, Newtec installed and put into operation an antenna and receiver of the
Page 101
Astra2Connect telecommunications system. During the same period, JRC ordered satellite images of the Comoros EEZ covering the demonstration period, making use of a number of satellite image suppliers. The planned operation was to download satellite images and to compare the data extracted from them so as to compare it with vessel monitoring system (VMS) data. This could yield a preliminary assessment of the presence of illegal vessels.
Figure 78: The Astra2 connect antenna
One of the reasons for the choice of the Comoros was to test the possibility of realizing a VDS in difficult conditions and this, indeed, proved to be the case. The Comoros is notorious for frequent power outages, and these were exacerbated by torrential rains during a significant period of the demonstration. Furthermore, an auxiliary diesel generator was not in operation during the period, thus limiting execution of the demo to periods when the normal power grid was operational. Despite these setbacks, direct access to the satellite images to the Fisheries Monitoring Centre was successfully achieved, through the Astra2connect satellite communication capability. The largest files, which came from Radarsat 2, were typically 213 MB in size and were downloaded at a speed of from 80 to 85 KB/s, for a total time of just over 40 minutes. This performance is consistent for requirements of a quasi-real-time VDS. The performance in acquiring and downloading the images attests to the fact that the technical capability was successfully demonstrated and that such a tool could be used advantageously in the future.
Page 102
12.2.4 TANGO Maritime Surveillance (ship tracking) demonstration in CROSSMED, Toulon, France The Maritime Surveillance demonstration of the TANGO project has taken place on 23 June 2009 in the French Maritime Rescue Coordination Centre (MRCC) for the Mediterranean sea, known as CROSSMED. For the demonstration, the audience is composed of about 25 people representing various governmental services. The exercise is monitored by the French Affaires Maritimes CROSSMED officers. In the audience, the Prefecture Maritime, which coordinate the state action at sea and may prosecute a polluter or instance, the French navy Operation commander for the Med sea, with search-and-rescue and police specialists, the French customs air patrol involved in pollution watch, and the European agency FRONTEX, specialized in border surveillance. A superintendent of the company Louis Dreyfus Armateurs was present to represent the point of view of the shipping industry.
Figure 79: The company Louis Dreyfus Armateurs allowed two vessels to be volunteers to be tracked by LRIT The TANGO ship tracking scenario The scenario invented for the exercise is the following: a governmental agency has to perform several types of tasks. It relies on one or two GMES Service providers (CLS and EUSC, based in France and Spain) for the analysis of data and uses the THEMIS software system to merge all data in one map. The sequence of tasks is the following one: 1. Routine tasks such as vessel traffic and pollution monitoring. The vessel traffic tracking usually relies on governmental infrastructure like coastal radars and AIS receive stations connected to a single point, generally not using satellite telecommunications. TNO demonstrates the use of combined realtime coastal surveillance on which the Louis Dreyfus ship tracks have been observed: 2. As part of routine tasks to monitor the traffic lanes in long distance, the agency acquires low resolution/wide coverage satellite radar scenes from Envisat and ERS2, two ESA satellites. This part of the exercise has last from 1st March to 1st June 2009
Page 103
Figure 80: Vessel traffic displayed by CLS combining AIS and LRIT 3. On the 31st May 2009, the agency is informed by another intelligence agency that a suspicious boat (a sailboat fitted with a satellite transponder) has been detected while stopping in the English Channel. The agency accesses to LRIT (Long Range Identification & Tracking) position reports, under its Coastal State profile. In pre-defined LRIT custom coastal areas, the agency receives a list of ships position reports. The agency starts tracking a merchant ship of interest. The agency asks CLS to program high resolution satellite radar scenes from Radarsat2, in order to confirm that the LRIT position report corresponds to the ship. The scenes allow to detect a 160-meter long ship (ship identification is not possible): 4. On the 1st June 2009, the agency starts its annual clean coast campaign, and increases the level of surveillance of the potential pollutions. The agency asks the GMES Service Provider (i.e. CLS) for some high resolution ENVISAT and Radarsat2 satellite images
Figure 81: Ship detection Radarsat image
Figure 82: Detection of pollution Envisat Image
Page 104
Specific added-value of TANGO The first advantage of TANGO is to give access to a catalogue of various satellite solutions to solve every mission. In this present exercise, TANGO would have helped in choosing to technology to track the boats and the merchant ships. Few high data rate satellite telecoms were used. Unlike the other demonstration supported by TANGO, the Maritime Surveillance exercise relies on existing telecommunication infrastructure:
Page 105
12.2.5 TANGO Humanitarian Aid Demonstration, Hue, Vietnam The purpose of the exercise was to evaluate the support of TANGO solutions for telecom equipment and services in a typical RESPOND scenario (GMES services supporting humanitarian relief, Disaster Reduction and reconstruction - www.respond-int.org) dealing with preparedness and crisis response in the case of floods disaster event. TANGO provided support to field team activities with portable satellite telecommunication equipments integrating technologies for voice and data communications, and providing also GIS capabilities. The team was composed by UNOSAT experts in charge of the coordination of the demonstration, Infoterra France, in charge of the Eliseo tool, and EADS Astrium, the TANGO project coordinator. Tasks carried out within the demonstration in Hue were also efficiently supported by the Vietnam National University, Hanoi, as well as the Bureau of Government, Ministry of Science and Technology, Ministry of Defense, Peoples Committee of Thua Thien Hue Province, Science and Technology Service of Thua Thien Hue province, Hue University, Hue Center of Information Technology, without which the demonstration would not have been such a success. Two operational crisis scenarios were used for the demonstration. In the first scenario, the Hue city area is flooded due to monsoon rains and the team has to identify flooded areas, safe areas, and ways to evacuate the affected population. In the second scenario, the landfall of a typhoon causes the flooding of the lagoon area in the Hue region and the team has to identify the flooded areas and status roads. Two teams were established, one for each scenario.
Figure 83: First scenario map
Figure 84: Second scenario map
Page 106
Participants worked for two days on a geographic area confined by the sea, river, mountains and the beach to identify the areas potentially flooded, the safe areas nearby, and how to evacuate the affected population. The boundaries of these areas were drawn including the road network using the Eliseo tool and the information was transmitted to the Command Center located in the Hue City. The Command Center, after coordination of data collection, retransmitted the filtered data to RESPOND HQs located in Europe through satcom links. After processing the data available, the RESPOND team in Europe sent back to the field the maps necessary to coordinate the operations of rescue teams.
Figure 85: Photo in Vietnam The results of the demonstration were highly appreciated by the Vietnamese authorities during the debriefings in Hue and Hanoi, opening the concrete possibility of future collaborations. The Vietnamese authorities underlined that satellite telecommunications associated to geospatial data as in the case of the TANGO project play an important role in monitoring risk, responding to crisis and bringing more efficiency in disaster management. The demonstration team benefited from support from Inmarsat for the satellite bandwidth service provision and from Ansur Technologies of Norway for the ASIGN Image Communications Solution. The BGAN and ELISEO telecom equipments have worked without failures including under torrential rain in Hanoi.
Page 107
12.2.6 TANGO Security Demonstration in Madeira, Portugal The security demonstration of the TANGO project was successfully performed on 27th-28th May 2009 in the Island of Madeira. The exercise was organised and coordinated by the European Union Satellite Centre (EUSC) in collaboration with several partners from different technical areas, among which EADS Astrium (TANGO project coordinator), CNES (Centre National dEtudes Spatiales), Infoterra France, Charles University (Czech Republic) and Avanti. The demonstration was hosted by the Madeira Operational Command, who kindly offered access to their premises, provided organization support and actively participated in the demonstration. The exercise simulated an evacuation of EU nationals affected by a crisis situation in Alania outside EU borders. The scenario was integrated in the framework defined by the European Union and benefited from the support, guidance and implication of representatives from the EU Situation Centre (Brussels). The existing telecommunication networks were ignored during the exercise to simulate the lack of terrestrial communication infrastructure during a crisis. The exercise allowed to highlight the benefits of providing near real time satellite imagery plus advanced telecommunication services by the bidirectional linking of the three sites participating in the exercise: the actors in the field (SitCen-A plus Mobile Unit), EUSC providing data and information updates and the headquarters managing the operations (SitCen, Brussels). Transportable and easy to deploy satellite communication solutions adapted for crisis management situations were demonstrated. These solutions successfully provided stable and reliable communications between actors involved in the scenario to allow voice, data and internet communications, the transfer in real time of geospatial data as well as GPS positions collected on the field, and to provide access to near real time earth observation satellite imagery information. The geospatial information was efficiently shared between different actors of the scenario in the three sites, providing an optimised support for decision making. During the demonstration both operational satellite telecommunication solutions like ELISEO from Infoterra France, and innovative solutions such as RECOVER, developed in the frame of the TANGO project under CNES leadership, were brought into service for the benefit of the evacuation scenario. ELISEO combines geomatics GIS and GPS applications with satellite communications adapted for field mapping services, integrating cartography, positioning and communication. It allowed a permanent connection between the Mobile Unit on the field and the local command centre (SitCen-A) for communication and tracking of the evacuation routes in the field. The RECOVER (Risk and Emergency COntainers for Valuable and Essential telecom Recovery) is a modular and compact solution composed of a set of containers providing the following types of links during the evacuation exercise
Figure 86: Deployment of ELISEO
Page 108
In order to ensure internet connexion with the EUSC and EU SitCen in Brussels, RECOVER was installed at the local command centre (SitCen-A); RECOVER provided permanent connexion to theELISEO platform through satellite internet connexion to facilitate communications with the Mobile Unit. Telecom solutions were selected from the offers provided by the Common Telecommunications Service Platform (CTSP). these solutions were successfully tested in the security demonstration. The exercise benefited also from the highly appreciated support of Inmarsat for the provision of the satellite bandwidth for BGAN communications. Operational activities developed during the demonstration were supported by products generated from a geographical information system (the Evacuation GIS), based on satellite images and aerial photographs of high-resolution in which route analysis was performed to determine the best evacuation routes from specific evacuation areas. The system enabled demonstration actors to obtain essential information for a fast and efficient evacuation of EU citizens such as the selection of the most suitable or the fastest route, estimated travel time, location of evacuation points, hospitals and other important facilities, etc.
Figure 87: Display of Geographical Information System (GIS) To comply with the security requirements of the end users collected during the first phase of the project, communications and data were encrypted/decrypted during the exercise using dedicated hardware and software.
Page 109
Figure 88: Local command centre The evolution of operations was accompanied by access to servers located at EUSC in Torrejn and at Charles University in Prague. The demonstration was attended by civil and military authorities of the EU, the Regional Government of Madeira and the Madeira Operational Command who highly appreciated the demonstration. Running in parallel with the exercise, there was a programme of presentations and briefings by the project partners about the technologies being used in the demonstration. This event provided an excellent opportunity for networking and awareness on the status of EU operations and the benefits of using satellite telecommunications in international crisis.
Figure 89: Display of Geographical Information System (GIS)
Page 110
13.
PROJECT SATELLITE-WIFI HANDOVER SIMULATION Overview
13.1
This project refers to in-house R&D work performed internally at the University of Rome "Tor Vergata". Nowadays broadband access to networks is often required in mobility and along wide and heterogeneous geographical areas. In this context, broadband satellite networks allow a potentially global coverage and then an ubiquitous access to the communication services, while WiFi systems in general offer a much higher capacity and less latency but in a limited coverage area. These technologies, if jointly used, can represent an optimum solution for mobile and nomadic users to uninterruptedly access the Internet: high capacity and low delays under the WiFi Hot Spot coverage, long range mobility and service continuity, where WiFi access is not available, thanks to satellite links. Of course, efficient inter-segment handovers (HO) procedures are needed to switch between such different technologies. Mobile IP (MIP) protocol provides mobility support at network layer, allowing mobile nodes to change point of access to an IP network transparently. MIP envisages the definition of a location management agent, called Home Agent (HA), which keeps the association between a home permanent IP address assigned to the Mobile Node (MN) in the home network and several care-ofaddress (CoA) assigned when visiting other networks. When MN moves to a new location, it obtains and registers a CoA with HA. CoA can be, for instance, an IP address belonging to the subnet of the new access router, called Foreign Agent (FA), which the MN is connected to. Therefore, all the packets directed to the MN are intercepted by HA, which encapsulates and forwards them to the CoA. The FA then de-encapsulates incoming packets and delivers them to the MN. Packets generated by the MN instead have as source the permanent IP and not the CoA, so that explicit support for mobility must be present in the routers of the visited networks. MIP has been introduced to offer mobility to nomadic users giving a dynamic point of access from different wired networks keeping a unique IP address reference. This concept has been extended to wireless networks, which are more suitable to mobility and more demanding in terms of handovers procedures. Nevertheless, in all its realizations MIP has to deal with the so-called Handover Latency, or out of service time, and it is not able to mask the impairments of such latency to higher layers. In fact a MIP handover results in an interruption of the communication at layer 3 with consequent packet losses. The duration of such interruption usually is composed of the time to connect MN to the new link (HO performed at layer 2) and the time needed to update routing (HO performed layer 3). TCP, the connection-oriented transport protocol, is particularly affected by handover occurrence. In fact, in addition to the Handover Latency time, HO between links with different delay and bandwidth-delay product can cause a number of problems such as the generation of segment bursts and delivery of out-of-order packets. In fact: TCP misinterprets any loss during HO as a congestion signal, thus dropping its congestion window and as a consequence the transmission rate; TCP computes the retransmission time out (RTO) on the basis of measured RTT values; then, a sudden significant variation of the RTT after handover can lead to two undesired dynamics; (a) if the new link has a larger RTT, RTO can prematurely expires, with a consequent reduction of the congestion window to a minimum value, even without losses; (b) if the new link has a shorter RTT, too long time (equal to the old RTO) must elapse before TCP sender can recover from a packet loss;
Page 111
after the HO procedure is completed, the new link is established but TCP state variables, which regulate transmission rate, are either still tailored for the old link or dropped after a loss detection and long time may be required before retrieving the optimum settings. To counteract impairments at transport layer (adopting TCP) caused by HO a cross-layer architecture is proposed. The following CL signaling are enabled: 4. From Link to Transport Layer (s1), on the basis of L2 status, the Link Tuning Layer (LTL) can generate two trigger signals; if MN is connected to WiFi, signal trigger can be generated as soon as the signal-noise ratio over the WiFi link degrades under a preselected threshold; if MN is connected to the satellite link, signal trigger can notify that a new WiFi network is in the range of MN. Optimization Sub-System (OSS) delivers L2 triggers to the Transport Tuning Layer (TTL); this signal is used to prepare TCP to the forthcoming HO event. In fact, L2 HO is in general unpredictable by upper layers, and leads to the loss of the outgoing/incoming packets. The goal is to stop TCP transmission opportunely before L2 HO in order to prevent packet losses. From Link to Network layer (s2), when the new link is available to be accessed, LTL generates a L2 trigger to advertise the L2 handover. This trigger is sent to the Network Tuning Layer (NTL) and indicates that HO procedures can start. From Network to Transport layer (s3), Network Tuning Layer (NTL), when receiving a L2 trigger, sends a disconnection signal to TTL in order to announce the disconnection; in addition, when HO is completed and the new link connection is established, NTL sends to TTL a connection signal; both connection and disconnection signals are then used by TTL to make proper adjustments to the TCP status variables.
5.
6.
All the triggers are managed by a centralized OSS, which allows CL communication between link and network layer. Scheduling of CL signals (s1,s2,s3) plays an important role in achieving optimized performance. In particular, the interval time between s1 and s3 must be adjusted in order to allow both TTL and TCP to perform all the appropriated actions before disconnection (see next sub-sections for details). This interval time depends on a number of factors as, for instance, the RTT in the current link, current channel characteristics correlated with the MN speed, communication direction, etc. In this paper, we assume that OSS is able to calculate the optimum interval time, meaning that disconnection is performed just after the end of TCP CL operations aimed to temporary stop transfer: no packet/ACK losses while TCP idle time is minimized. In general, it is preferred to slightly overestimate this interval time in order to avoid losses. TCP protocol modifications triggered by CL signaling are different for the two communication directions.
13.2
Testbed Description
In order to evaluate performance of TCP with possible enhancements in comparison with the standard protocol stack performance, a NS 2 simulation has been set up. In particular, a new TCP CL module has been added to the simulator. The baseline simulation script simulates a data transfer according to the scenario described in section III, assuming a SAT channel of 1 Mbit/s with RTT fixed to 500 ms and a Wi-Fi Hot Spot area with a bandwidth of 2 Mbit/s and a RTT delay of 20 ms. Data packet dimension is fixed to 1460 bytes. Both the number of transferred bytes and throughput during HO are used as metrics to evaluate performance. The selected application is FTP, which runs in both the communication directions, that is from Mobile Node (MN) to Correspondent Node (CN) and vice versa. At the beginning of the FTP session, the MN is connected to a WiFi AP. During the transfer, three handover events occur:
Page 112
a. MN moves from WiFi to Satellite after 10 s, b. MN switches to a new WiFi AP after 20 s from event a), c. MN connects again to the satellite link until the end of the simulation after 15 s from event b). In the case of Cross-Layer modified stack, one RTT (of the current link) before HO, the L2 trigger is generated, followed by the proper cross-layer procedures. The data transfer simulation has been repeated varying the Handovers latency in a range from 0.1 s (5 X WiFi link RTT) up to 5 s for satellite originated HO. In the case of WiFi originated handover latency starts at 2.5 s (5 X WiFi link RTT). In fact, as presented in section III.A, HO disconnection lasts at least 5 RTT of the destination network, needed to complete HO procedure (see Figure 3). FTP data transfer uses TCP standard New Reno with and without Cross-Layer actions optimized as described in Section VI according whether MN-to-CN or CN-to-MN direction is considered.
13.3
Trials and Demonstrations
In the reference scenario shown in the Figure 90, a Mobile Node (MN) moves across a hybrid network composed of: one satellite segment (SAT), which through the wide coverage of a GEO satellite reaches the MN in all its service area; n independent wireless LANs (WiFi) scattered (even partially overlapped) into the above defined satellite coverage area and identified by access points (APs).
Figure 90: Mobile environment
As term of reference the SAT technology adopts DVB-RCS mobile standard, WiFi adopts 802.11b standard, MIPv6 (Mobile IPv6) standard is considered and TCP is adopted as transport layer protocol.
Page 113
Mainly, MIP envisages the definition of a location management agent, called Home Agent (HA), which keeps the association between a home permanent IP address assigned to the Mobile Node (MN) in the home network and several care-of-address (CoA) assigned when visiting other networks. In this way, connection between MN and the Correspondent Node (CN) is kept alive irrespective of the access network serving the MN. During the TCP connection life, one or more handovers could be performed as a consequence of user mobility. Since WiFi networks usually provide higher bandwidth and are characterized by lower propagation delay with respect to satellite networks, switching from SAT to a WiFi access point is preferable when possible (overlapping of both WiFi and satellite coverage).
13.4 Results
To ensure continuous access to the Internet for mobile and nomadic users, it is necessary to consider integration among different kinds of telecommunications networks. In particular, switching between satellite and terrestrial networks, such as Wi-Fi, can represent an optimum solution because high capacity and low delays can be achieved under the WiFi Hot Spot coverage and long range mobility and service continuity can be ensured thanks to satellite links where WiFi access is not available. In this scenario a Handover (HO) must be performed when a Mobile Node (MN) switches from a point of access to another one of the same system, or between points of access belonging to different systems (even adopting different standards), keeping communication alive. If HO is performed in a network adopting the internet protocol stack and offering multimedia broadband IP services, also exploitation of upper layers functionality (network, transport and application) is affected and proper actions must be undertaken at each layer to keep the relative protocol performance unaltered. Mobile IP (MIP) protocol provides mobility support at network layer, allowing mobile nodes to change point of access to an IP network transparently. MIP presents a problem called HO Latency, or out of service time, and it is not able to mask the impairments of such latency to higher layers. In fact, a MIP handover results in an interruption of the communication at layer 3 with consequent packet losses. The duration of such interruption is usually composed of the time to connect MN (Mobile Node) to the new link (HO performed at layer 2) and the time needed to update routing (HO performed layer 3). At transport layer, some problems occur after a HO event, because TCP protocol is not designed to handle mobility. In particular, when HO is performed between links with different delay and bandwidth-delay product (BDP), HO causes reordering and generation of segment bursts, Bandwidth-Delay product sudden variation and Expiration of TCP's time-out. 13.4.1 Reordering and generation of segment bursts The packet reordering can occur after a HO, if consecutive packets are routed through different paths in case the delay of the new path is lower than the old one. This occurs only in the case of soft-HO, where the MN exchanges data with both satellite and WiFi link, before physically switching of the mobile device. Burst generation can be due either to TCP cumulative ACK scheme, where the acknowledgment for the first packet received after the switch will anticipate the acknowledgments still in transit over the old link, or due to the loss of several ACKs over the old link. 13.4.2 Bandwidth-Delay product variation The bandwidth-delay product (BDP) is a very important parameter in a window-based protocol such as TCP because it determines the amount of data that can be in transit in the network. After a HO occurrence some problem can be experienced:
Page 114
5. a large number of packets can drop when moving from satellite to WiFi, because BDPsat > BDPWiFi and then the most of the packets injected over the new network leads to buffers overflow increasing the experienced latency; 6. moving from WiFi to satellite, since TCP enters in Congestion Avoidance phase (linear cwnd increase on a RTT basis) when cwnd is far away from the BDPsat, the increase of the cwnd up to the optimum value requires long time, resulting in a temporary significant underutilization of the satellite resources. 13.4.3 Time-out expiration When a HO from WiFi network to satellite occurs, due to high delay of the new link, RTO expiration can be experienced because the last packets received through the old link can be acknowledged after that RTO, evaluated on the basis of the old link delay, expires. Due to standard TCP dynamics, shown in Figure 91, after a link disconnection, a certain number of sent packets/ACKs will be lost and RTO is initialized with reference to the first unacknowledged packet.
Figure 91: TCP standard behavior
Depending on the handover latency, one or more RTO expiration and consequent retransmissions can occur. When MN is reconnected to the new link, TCP sender might be not yet able to re-start the transmission since RTO is not yet expired. In this way, an additional contribution T* is generally added to the handover latency causing a further performance degradation in terms of throughput. This added time is a function of HO latency and varies from 0 to RTO K. At the end, transmission restarts with cwnd set to 1 and ssthresh halved as many times as the number of RTO expirations.
Page 115
To overcome inefficiency introduced by TCP standard, it is possible to introduce a Cross-Layer interaction between link, network and transport layers. The scope is to make TCP aware of the incoming HO in advance. In this way, TCP has enough time to do appropriated actions aiming to both avoid losses during HO and efficiently restart the transfer over the new link. To evaluate performance of such a method, NS 2 simulation platform has been improved with ad hoc modules that reproduce such cross layer interactions. Figure 11 and Figure 12 show the instantaneous throughput achieved over time during the data transfer by standard and cross-layer enabled stack from MN to CN (Correspondent Node) between WiFi to SAT link and vice versa respectively, assuming a SAT channel of 1 Mbit/s with RTT fixed to 500 ms and a Wi-Fi Hot Spot area with a bandwidth of 2 Mbit/s and a RTT delay of 20 ms. In these simulations, the disconnection event occur at 10 s where the MN moves from WiFi to SAT link and at 30 s where MN moves from SAT to WiFi link, considering for both a HO latency T HO = 5s. Both figures show a significant improvement of performance, after the disconnect event due to the cross-layer action. Performance degradation of TCP standard is due to the HO latency and T*.
Figure 92: Instantaneous throughput from WiFi to Satellite link
Page 116
Figure 93: Instantaneous throughput from Satellite to WiFi link
Page 117
14.
PROJECT SATNEX JA2240 - CROSS-LAYER IPSEC Overview
14.1
SatNEx (Satellite Network of Excellence) and its extension SatNEx II are two Network of Excellence (NoEs) funded by EC within FP6 IST program. In this framework, a particular attention is devoted here to the activities performed within Work Package (WP) 2200, titled Networking and, particularly, within the Joint Activity (JA) 2240, titled Network Security belonging to this WP. In particular, this section focuses on cross-layer IPSec issues addressed as part of SatNEx JA2240. The reference protocol stack is shown in Figure 94. Application layer At the application layer, error-tolerant protocols are considered. Modern multimedia codecs are designed to be error resilient. This is the case of MPEG video coding, which is based on three different frame types: I-, P- and B-frames. I-frames carry information about an entire video frame, while P- and B-frames only include the differences to other frames. Usually it is better to deliver damaged P- and B- frames than discarding them. MPEG-4 also includes new features allowing both error resilience and improved compression. In addition, Reliable Multicast Transport (RMT) protocols use various error/erasure correction codes to protect against channel impairments. In this frame, FLUTE protocol defines a specific file delivery application of Asynchronous Layered Coding (ALC), adding capability to deal with bit errors. Transport layer UDP-Lite is used instead of UDP. The main difference between UDP and UDPLite is the partition of each packet into two parts: sensitive and insensitive. Errors in the sensitive part result in a packet drop, while packets with errors in the insensitive part are forwarded to the application. Network layer Either IPv4 or IPv6 can be alternatively selected. IP checksum is computed only on the IP header field to verify that the IP header was not damaged. In IPv4, such a checksum is mandatory, while IPv6 relies on both the link CRC and transport checksum to assure IP header integrity. In addition, CL-IPsec is used to provide security services at the network layer. Herein, AH protocol in the transport mode is implemented. As a benchmark standard IPsec AH protocol is considered. Link layer Link layer must calculate the CRC according to the payload type. That is, in case of UDP-Lite a partial checksum must concern only the link layer header and UDP-Lite sensate part. Header protection techniques can help to avoid bit errors in the sensitive part (possibly used in combination with link header compression). This work focuses on the definition of the Cross Layer-IPsec Authentication Header (AH) protocol by proposing also the design of the Cross Layer (CL) signaling needed to get UDP-Lite checksum value in both sender and receiver sides.
Page 118
Figure 94: Cross-Layer (CL) protocol stack and related services
14.2
Testbed Description
CL-IPsec envisages modifications in the ah4 module of the Linux kernel and is implemented in the kernel release 2.6.20.1. In order to both validate the implementation and to evaluate benefits coming from the proposed CL architecture a satellite emulation platform has been set up. Specifically, 3 PCs have been interconnected, as shown in the Figure 95, with the following configuration: ST1 and ST2 represent the end-systems of a satellite link: e.g. satellite terminal and a satellite gateway. SAT represents a transparent GEO satellite and introduces physical delays in both the communication directions and bandwidth constraints. Either a CL-IPsec or an IPsec Security Association (SA) can be established between ST1 and ST2: the security protocol is AH and SPD/SAD databases are manually configured (no rekeying, infinite SA lifetime). UDP-Lite is run as transport protocol (a standard feature since 2.6.11), while both IPERF and VLC, patched to run over UDP-Lite, are used as applications. To emulate an error-tolerant link layer, possible bit errors are generated at the network layer (just before entering CL-IPsec/IPsec routines) of the receiving application end-systems (usually ST2) by using a random error generation with a uniform distribution.
Page 119
Figure 95: Testbed description
14.3
Today UDP is the preferred transport protocol to deliver multimedia as well as multicast packets over the Internet. However, due to its severe error check mechanism, even single bit error may lead to packet loss. A transport protocol called UDP-Lite was designed to replace UDP in architectures where applications can tolerate errors up to a certain amount in their payloads. UDPLite allows division of a datagram into a sensitive and an insensitive part. An application can use the Checksum Coverage field (replacing the length field in the UDP header) to indicate the number of bytes from the beginning of the UDP-Lite header that must be considered sensitive to bit errors. Receivers calculate the checksum only over the sensitive part and datagrams with bit errors only in the insensitive part are forwarded to the application. UDP-Lite and the IPsec protocol suite are intrinsically incompatible because IPsec authenticates (and optionally encrypts) the entire IP payload assuming that the entire IP payload is sensitive to unauthorized bit changes (due to either bit errors or malicious attacks). This conflicts with UDP-Lite which can tolerate bit errors in its payload. To adapt IPsec for UDP-Lite based applications a module to enable a cross Layer IPsec (CLIPsec) as modification to the linux kernel has been designed. The behavior of CL-IPsec is dependent on the cross layer signaling between network layer and higher layers. Specifically, IPsec needs to receive both explicit signaling from application, indicating the use of UDP-Lite, and implicit signaling from transport layer to get the coverage length value and then perform the security operations accordingly. Considering the AH protocol in transport mode, on the basis of the above mentioned signaling scheme, a CL-IPsec scheme of implementation is shown in Figure 96, where the insensitive part only involves the RMT payload. It allows partial authentication involving only AH, UDP-Lite and other sensitive bytes.
Page 120
Figure 96: Partial authentication using CL-IPsec in transport mode
14.4 Results
Figure 97 shows test results achieved over the linux satellite emulation platform in terms of packet loss rate perceived with an application of video streaming (Videolan) versus the BER of the satellite link. CL-IPsec to accept allows a higher number of packets, although corrupted in the insensitive part; IPsec instead drops all the corrupted packets.
Figure 97: Video Packet Loss rate with IPsec and CL-IPsec Figure 98 shows two frames relative to video streaming tests with BER=10-5, MPEG-2 video codec and both UDP-Lite/CL-IPsec and UDP-Lite/IPsec protocol stacks were alternatively configured. The improvement in terms of video quality when CL-IPsec is utilized with respect to the IPsec is due to an increased number of bytes passed to the application codec (MPEG-2).
Page 121
Figure 98: Frame of video streaming test with MPEG-2 and BER=10-5
Page 122
15.
PROJECT EMERSAT - EMULATION OF HETEROGENEOUS NETWORKS FOR EMERGENCY Overview
15.1
The EMERSAT (Satellite solutions for applications and communications services) project, supported by the Italian Space Agency (ASI), foresees as its primary objective, the development, integration and testing of satellite solutions for applications and communications services (especially mobile or relocatable) to national institutional agencies dedicated to security and emergency management. The project also provides for the development of a multiservice applications architecture that foresees providing integrated low-band communications (fixed, mobile or relocatable) of satellite navigation and georeferenced localization and high-definition remote sensing. The objective is give the institutional agencies operators devoted to emergency security and management all the technology for receiving and transmitting the information needed for the most effective and safest management of emergency interventions. The main objective in this scenario is the enhancement of the satellites role, the essential considering essential problems such as: interoperability between different networks, strength and "survival, security of communications and access, back up and complementariness of solutions, enhancement of all synergetic applications that optimizes the use of satellite technology. Analysis and design of complex heterogeneous networks should need of a confederation of tools heterogeneous as well. For several scenarios and applications to meet service requirements a network composed of different segments (which adopt different standards and technologies) must be set up. The presented work conducted as part of the EMERSAT project addresses particularly this framework and deals with the emulation of heterogeneous satellite-terrestrial networks to support emergency.
15.2
Testbed Description
For the scope of the EMERSAT project, the DVB-RCS emulation platform described in Section 4.2 has been integrated in a more extended platform based on the use of the Satellite ToolKit (STK). Specifically, a federation of simulation/emulation tools has been integrated to provide a flexible architecture well suited to support analysis of heterogeneous terrestrial-satellite scenarios. STK acts as coordinator of the whole platform, performing the following actions: Configurations of the application scenario; Scheduling of the simulated events (terminal motion, transfer start, parameter changes); Triggering of distributed tasks on the various federated tools Collections and visualization of results. STK interacts with the satellite emulation platform to activate services of a telecommunicationadvanced system: mechanisms at the network layer, transport layer, satellite resource management and implicit or explicit interaction among protocol layers. In this way, satellite emulator allows to investigate on most relevant issues of actual broadband satellite systems while interfacing with the largely deployed terrestrial systems. In addition, STK exploits three further tools focused on the control and management of the communications: Call Admission Control (CAC) tool - this tool enhances the platform with CAC procedures needed to guarantee target quality of service at the flow level in terms of guaranteed bandwidth and delays and at the call level in terms of blocking probability and call breaking down probability.
Page 123
Dynamic resource assignment tool this tool manages a dynamic assignment of resources available over the satellite link, based on both the control theory and methodologies of Operational Research. Algorithms to compute bandwidth requests can be properly integrated to scheduling algorithms that Earth Station runs at the IP level. Multidimensional link budget tool: this tool performs multi-dimensional link budgets for transponder in Ku/K/Ka bands, both bend-pipe and regenerative, which can be applied for different coverage areas and various propagation models. Such a tool is able to interface with external databases to retrieve data concerning large set of areas. In particular, it envisages an interface with a database concerning propagation models of satellite signal through the atmosphere.
Page 124
16.
PROJECT INTERSECTION- SATELLITE NETWORK PROTECTION Overview
16.1
INTERSECTION (INfrastructure for heTErogeneous, Resilient, SEcure, Complex, Tightly InterOperating Networks) is a Collaborative Project co-funded by the European Commission in the context of the Seventh Framework Programme under the "Secure, Dependable and Trusted Infrastructures" sub-programme area. From a security perspective, the utilization of a satellite segment in an integrated architecture leads to vulnerabilities that can be classified as follows: Satellite-specific vulnerabilities, which completely rely on technologies (usually involving lower protocol layers); satellite characteristics and
Non satellite-specific vulnerabilities, which are common to all the IP-based networks (i.e. IP data corruption, interception, etc.); Satellite intersection-based vulnerabilities, which rely on satellite technology needed to support interconnection with terrestrial networks. The latter class involves technology solutions aimed to guarantee good performance over the satellite link. In fact, the use of traditional TCP/IP stack and related paradigms implies poor performance since the basic features of the protocol design dont match with the actual environment. A common baseline to mitigate the problem envisages the use of Performance Enhancing Proxies (PEPs) at the edge of satellite links with the main scope to accelerate TCP over satellite. PEP is mainly based on a splitting architecture, which divides end-to-end connections into multiple sub-connections, each one adopting a transport protocol suited to the link characteristics (i.e. delay, bandwidth, BER). Over the satellite link, ad-hoc transport protocols usually replace standard TCP. Although performance improvement is significant, PEP-based architecture is intrinsically vulnerable due to the violation of the TCP end-to-end semantic. A PEP intentional or unintentional failure (i.e. dropping of locally acknowledged packet before reaching actual destination) leads to an irreversible break of the end-to-end reliability. Implications on security are straightforward since TCP is used to provide transport services also to comply with severe requirements in terms of reliability. Figure 99 shows a possible attack scenario.
Page 125
Figure 99:Threat exploiting PEP-related vulnerability Specifically, a malicious user in the same network of a target legitimate TCP source can access PEP in front of satellite gateway with the aim of installing a malware application that performs the task to drop either a part or all TCP packets flying towards Internet through the satellite link. Different harmful effects can be caused depending on both malware implementation and considered application protocol: loss of several packets within a connection, which causes continuous retransmissions, for instance after a retransmission timeout expiration, increasing transfer time; packet dropping, which does not allow the application to successfully conclude its operations and end-system is aware of the negative transfer outcome; packet dropping, which is transparent to applications that trusts on a successfully transfer. To face with the above described attack, an Intrusion Detection System (IDS) has been developed. It integrates different functions and components (monitoring, detection, reaction, remediation, visualization and topology discovery), which cooperate to increase network protection and security in a real-time and automated fashion. The goal is to gather data from probes and network elements, to analyze it, to detect intrusions, and to select the most suitable remediation action against the detected attack. In addition, off-line functions aim at using data coming from the network or provided by the real-time part of the framework in order to help the human operator in analyzing the network state and make the network more secure.
16.2
Testbed Description
Main contribution of this work to the INTERSECTION project was the design of an intrusion system based on the above architecture dealing with attacks exploiting PEP vulnerability. Satellite IDS exploits two types of probes based on OpenIMP: the SYN detector and the TCP traffic analyzer. The SYN detector is installed on the satellite gateway and is in charge to monitor all the TCP traffic in order to create an IPFIX record for every SYN/FIN exchange through satellite link. Each record includes the parameters identifying the specific connection and it is enhanced with the time information.
Page 126
TCP traffic analyzer probes run on the access router of all the networks interfaced to the satellite network. Such probes aim to collect statistics about TCP traffic coming from and going to the satellite network. Specifically, a TCP traffic analyzer grabs the number of transferred bytes over any active TCP connection. A time interval must be defined for such measurements. A large value allows a better measurement accuracy, but it slows down statistic updates for the attack detection matters. On the contrary, a low value could be affected by transitory traffic dynamics, as for instance unexpected traffic spikes or idle times. Therefore, a trade-off value of 10 s has been chosen as default. All the probe records are collected by a data broker, which represents the first functional element of the IDS. Data broker is in charge to forward the received records to the Detection Engine, which implements the following detection logic: Step 1 - Compare the number of SYN records with that of FIN records coming from the SYN detector probe; if #SYN #FIN, regular operations are assumed; otherwise (#SYN #FIN > threshold = 10) detection process moves to step 2; Step 2 - Delete <#SYN ; #FIN> pairs related to a same connection; residual SYN records will provide information on networks involved in possible attack. Step 3 - For each connection under investigation, compare the amount of bytes crossing corresponding source-destination networks; results are computed in the form of byte differences. So-achieved results are then forwarded to the decision maker that determines if, what has been detected as an anomaly can be forwarded as an attack to an external entity. The Reaction and Remediation (ReaRem) subsystem involves a Reaction Engine, a repository of scripts used for the attack remediation, and a Remediation Point, which represents the network element where such scripts will be run. Specifically, when an attack is detected (decision maker issues a trigger), the Reaction Engine downloads the appropriate script from its repository to stop PEP misbehavior. This script, executed in the Remediation Points/PEPs, performs a procedure aimed to temporary disable PEP involved in the attack in order to recover correct settings: delete of the malware and reset PEP routing tables. Deployment of the overall IDS system over the reference scenario is shown in the Figure 100.
Page 127
Figure 100:IDS for PEP-related vulnerability
16.3
Target vulnerability has been reproduced in a communication scenario where a satellite geostationary link, operated by Telespazio (TSP), is used to interconnect a remote terrestrial LAN of Polska Telefonia Cyfrowa (PTC) with an Internet Service Provider (ISP) represented by Telefonica (TID). TID interfaces the satellite terminal, while PTC interfaces satellite gateway. For both links, GRE tunnels are set up. Test bed core relies on hardware in the loop configuration where a real satellite link (Intelsat 901 @ 342 E) operating at Ku band with a channel of 600 kHz is accessed by two satellite modems. At the edges of such a satellite link, both a Satellite Gateway/Network Control Centre (satGW/NCC) and Return Channel Satellite Terminal (RCST) functionalities are emulated through Linux-based machines. The rationale is to add to satellite link features also a DVB-RCS-like access scheme. Briefly, RCST will require bandwidth for the return link on the basis of its actual needs (i.e. amount of bytes stored in the MAC queue). PEP agents are installed in both satGW/NCC and RCST machines. The overall test configuration with reference to IDS component location is shown in the Figure 101.
Page 128
Figure 101: Testbed configuration
Then, the overall routing results enough complex and envisages the following steps: 1. TID machines route traffic towards TIDs access router; 2. TIDs access router links a TSP access router (91.188.1.67) through a GRE tunnel; 3. Traffic coming from TSP access router is forwarded towards satellite modem through PEP machine; 4. Satellite modem is connected through satellite to a second satellite modem; 5. Second satellite modem is connected to a PEP machine; 6. PEP machine routes traffic to a further TSP access router (91.188.1.66); 7. TSP access router forwards traffic towards the server located in PTC premises. The application foresees a user in TID network that uploads files in an FTP server installed at PTC premises. A TCP connection is established to provide an end-to-end reliable byte stream. PEP agents running at the edges of the satellite link split end-to-end TCP connection, so that: an end-to-end TCP three-way handshake (TCP SYN flag on) is performed, three different sub-connections are created and managed by PEP agents, each PEP manages a local cache to store all the sent packets not yet acknowledged by the actual receiver.
Page 129
16.4 Results
The application implemented for test purposes is based on a traffic generator, running on a TID machine. Basically TCP connections with a machine installed in PTC are generated over different ports on the basis of the following input parameters: average rate of the overall data flow, the amount of bytes to transfer over any connection. In the tests presented below, the average rate is set to 200 kbit/s and the amount of byte in a single connection is taken equal to 100 kbytes. Results are summarized in Figure 102 and Figure 103. Over the first 210 s of simulation, ordinary operations are detected on the network: the number of active connections oscillates around the expected average (50) and throughput measured at both sides of the satellite link is similar. Selected IDS configuration envisages an active connection threshold of 90 s and a threshold for the throughput asymmetry equal to 75 kbit/s. In general, these values have to be tuned on the basis of a training period where characteristics of the ordinary traffic profile are observed. At 210 s, malware starts running. Malicious packet dropping does not allow correct connection terminations. As a consequence the number of active connections grows more and more (see Figure 18). At about 250 s, the number of the active connections overcomes the threshold value. Then, IDS performs the second step of the detection process comparing measured throughput at the edges of the PEP-PEP satellite link. From Figure 103, it is evident the high experienced asymmetry. During the attack, TCP senders (Figure 103-a) continue to transmit without suspecting any packet dropping. On the other side, TCP receivers receives only a minimum part of packets (attack is designed to allows transmission of sporadic packets in order to keep connections on) and experienced throughput in much lower than that measured at the sender side. The joint compliance of the above conditions with characteristics assumed for the attack profile leads to the issue of an alert message that, in turn, triggers the remediation procedure. Then, after a short time needed to disable PEPs instances involved in the attack, a reliable connectivity is restored and connections starting afterwards are successfully performed. With a particular reference to the Figure 103-b, it is possible to observe a decrease of the overall throughput due to the stop of TCP acceleration provided by PEPs.
Figure 102: Track of the SYN detector records
Page 130
(a) Throughput at the client side
(b) Throughput at the server side
Figure 103: Tracks of the TCP traffic analyzer records
Page 131
17.
PROJECT MOVISAT
17.1 Overview
MOVISAT is a research and development Spanish project aiming the study of the hybrid satelliteterrestrial technologies. It is a Singular and Strategic Project funded by the Spanish Ministry of Industry, Trade and Tourism, through the Plan avanz@ program me. The project it is performed by a consortium of Spanish entities covering several areas, from the definition of services from operators point of view, service and contents providers, broadcasters, and applications developers, to the system level including its constituent elements, architecture, management and network operation. MOVISAT studies consider mainly DVB-SH and ETSI-SDR standards in project developments. The increasing interest for these technologies gives a solid basis to the project. Among the main objectives, the next topics can be found: the study of networks and devices technological aspects; new business cases; regulatory aspects (at Spanish and European level); adoption and contribution to standards; definition of new applications; development of test-beds and validation tests of standards. This Project is in part the result of the work performed within the Satellite Digital Radio Working Group of the Spanish Technology Platform on Satellite Communications, eISI, mirror of the European Technology Platform ISI.

MOVISAT is developed functional prototypes that have been tested and evaluated in laboratory trials. Two setups modes have been tested. DVB-SH presents two configuration modes, SH-A (SHwaveform configuration A OFDM/OFDM) and SH-B (SH- waveform configuration B TDM/OFDM). Both of them are taken into account within MOVISAT tests. The figures below show the scenarios under test.
Page 132
Satellite Satellite Earth Station OFDM Services Provider IP Encapsulator SC OFDM Modulator
IP IP IP Encapsulator IP OFDM Terrestrial Transmitter CGC OFDM Modulator
OFDM
Terrestrial Repeater
Services & network Head-End
OFDM
Terminal
OFDM Demodulator
IP Decapsulator
DVB-SHA Receiver
Figure 104: Mode DVB-SH-A SH-A defines OFDM transmission mode for both satellite component (SC) and complementary ground component (CGC). SH-A scenario has been configured as a Single Frequency Network (SFN) between the SC signal and the CGC signal carrying the same content. The satellite signal is considered as additional repeater in a SFN.
Page 133
Satellite Satellite Earth Station Services Provider IP Encapsulator SC TDM Modulator
TDM
TDM IP IP IP Encapsulator IP OFDM Terrestrial Transmitter CGC OFDM Modulator Terrestrial Repeater
Services & network Head-End
TDM
Terminal
TDM & OFDM Hybrid Demodulator IP Decapsulator
DVB-SHB Receiver
Figure 105 : Mode DVB-SH-B SH-B defines TDM transmission mode for both satellite component (SC) and OFDM for complementary ground component (CGC). SH-B requires a distinct frequency band for the SC and the CGC since they transmit signals based on two different physical layers. The Setup in the laboratory follows the diagram shown in Figure 106. The main hardware elements integrated in the test-bed are: Emulator DVB-H/DVB-SH (Interactive Applications); Backend Server (Interactive Applications); client PC; Transmitter side PC; R&SSFU Broadcast Test System; SFU test equipment and SFQ SIDSA; Teamcast Modulator; Terrestrial channel emulator; Mixer; RX SIDSA Class 1 and Class 2. The main software elements involve in the tests is: Apache Tomcat 6; Mozilla Firefox 3.x; Java Runtime Environment (v6.13). The majority of tests have been performed in the same environment, adjusting the configuration to meet the different scenarios in focus. In some of the tests a real satellite is been involved.
Page 134
Figure 106: Laboratory Setup - Test-bed The functional scheme for the DVB-SH-A setup can be seen in the Figure 107. Satellite and complementary ground components are modulated in OFDM. The terrestrial and satellite channel are emulated. Models of different type of channels are during the tests. One modulator is enough to deal with both components.
SC OFDM Modulator
TS
Service Provider
IP
DVB-SH IP Encapsulator
CGC OFDM Modulator

RF
Terrestrial Channel Emulator DVB-SHA Receiver Terminal

IP
Satellite Channel Emulator

RF
DVB-SH IP Decapsulator
TS
OFDM Demodulator
App. Layer Component PHY Layer Component
Link Layer Component Channel
Terrestrial Link Satellite Link
Figure 107: Block diagram, DVB-SH A mode In case of SH-B architecture the satellite and terrestrial signal is demodulated by separate demodulators as shown in Figure 108.
Page 135
Service Provider
IP
DVB-SH IP Encapsulator
SC TDM Modulator
TS
CGC OFDM Modulator

RF
Terrestrial Channel Emulator DVB-SHB Receiver Terminal

IP
Satellite Channel Emulator

RF
DVB-SH IP Decapsulator
TS
OFDM Demodulator TDM Demodulator
App. Layer Component PHY Layer Component
Link Layer Component Channel
Terrestrial Link Satellite Link
Figure 108: diagram, DVB-SH B mode Following the DVB-SHs specifications, the scenarios for receptions conditions can be classified:
Reception Condition A B1 B2 C D
Situation Outdoor pedestrian Light-indoor Deep-indoor Mobile (vehicle) with roof-top antenna Mobile (portable) in-car
Characteristics Up to 3km/h Up to 3km/h, lightly shielded building Up to 3km/h, highly shielded building Up to 200 km/h Up to 130km/h

The DVB-SH Implementation Guidelines are taken as a reference in this test. The results obtained in the test have been compared with the pertinent values found in this document. Fulfilling these requirements is in the scope of this activity, and whether they are satisfied or not will comment hereafter. 17.3.1 SH-A Mode Tests 17.3.1.1 LMS channel, suburban, speed 3 km/h.
Page 136
Target ESR5 fulfillment. Scenario: Reception conditions A, suburban, speed 3 km/h. Parameters: Modulation: QPSK 1/3 y 16QAM 1/5 Guard time: 1/4 y 1/8 (baseline) Interleaving: 10 seconds (uniform / late interleaver) LMS satellite channel Satellite EIRP: 63dB C/N in satellite Terrestrial channel AWGN This test has been developed in the laboratory. The results obtained comply with the DVB-SH Implementation Guidelines. 17.3.1.2 Correct capacities at certain levels of C/N using uniform / late interleaver in reception conditions type A. Target capacity level. Scenario: Reception conditions A, suburban, speed 3 km/h. Parameters: Modulation: QPSK y 16QAM Guard time: 1/4 y 1/8 (baseline) Interleaving short or (uniform / late interleaver) TU6 satellite channel Satellite EIRP: 63dB C/N in satellite Terrestrial channel AWGN This test has been developed in the laboratory. The results obtained comply with the DVB-SH Implementation Guidelines. 17.3.1.3 Correct capacities at certain levels of C/N using uniform / late interleaver in reception conditions type B1. Target capacity level. Scenario: Reception condition B1, indoor with light fading.
Page 137
Parameters: Modulation: QPSK y 16QAM Guard time: 1/4 y 1/8 (baseline) Interleaving short or (uniform / late interleaver) TU6 satellite channel Satellite EIRP: 63dB C/N in satellite Terrestrial channel AWGN This test has been developed in the laboratory. The results obtained comply with the DVB-SH Implementation Guidelines. The same configuration is been used in scenarios B1, indoor with severe fading, obtaining equivalent results. 17.3.1.4 LMS channel, rural/suburban, speed 50 km/h.
Target ESR5 fulfillment. Scenario: Reception condition C, rural/suburban, speed 50 km/h. Parameters: Modulation: QPSK 1/3 and 16QAM for o o o { phy_cr=1/4 link_cr=2/3 } { phy_cr=2/7 link_cr=7/12 } phy_cr=1/5
Guard time: 1/4 y 1/8 (baseline) Interleaving: 10 seconds (uniform / late interleaver) LMS satellite channel Satellite EIRP: 63dB C/N in satellite Terrestrial channel AWGN This test has been developed in the laboratory. The results obtained comply with the DVB-SH Implementation Guidelines. The same configuration is been used in scenarios D, obtaining equivalent results. 17.3.1.5 BER performance over different channels using several Es/N0 in C scenarios.
Page 138
Target BER. Scenario: Reception condition C, rural/suburban, speed 50 km/h. Parameters: Modulation: QPSK 1/2 Guard time: 1/4 y 1/8 (baseline) Interleaving: 10 seconds Satellite EIRP: 63dB C/N in satellite Satellite channel: TU6 with Doppler of 50 /100 /200 /250 /300 Hz o Channel estimation: 1. 2. o Perfect Real
Satellite channel: AWGN with Doppler of 50 /100 /200 /250 /300 Hz Channel estimation: 1. 2. Perfect Real
This test has been developed in the laboratory. The results obtained comply with the DVB-SH Implementation Guidelines. The same configuration changing the FEC to 1/3 is been tested, obtaining equivalent results. 17.3.1.6 Target BER. Scenario: Reception condition D, rural/suburban, speed 50 100 km/h. Parameters: Modulation: QPSK 1/3 Guard time: 1/4 y 1/8 (baseline) Interleaving: 10 seconds Satellite EIRP: 63dB C/N in satellite Satellite channel Rice (k = 50) Satellite channel: TU6 with Doppler of 50 /100 /200 /250 /300 Hz o Channel estimation: 1. Perfect BER performance over different channels using several Es/N0 in D scenarios.
Page 139
2. o
Real
Satellite channel: AWGN with Doppler of 50 /100 /200 /250 /300 Hz Channel estimation: 1. 2. Perfect Real
This test has been developed in the laboratory. The results obtained comply with the DVB-SH Implementation Guidelines.
17.3.2 SH-B Mode Tests 17.3.2.1 LMS channel, suburban, speed 3 km/h.
Target ESR5 fulfillment. Scenario: Reception conditions A, suburban, speed 3 km/h. Parameters: Modulation: o QPSK: o 8PSK: phy_cr=1/3 link_cr=2/3 phy_cr=2/9 phy_cr=1/3 phy_cr=1/2 link_cr=2/3
Page 140
Guard time for CGC: 1/4 y 1/8 (baseline) Interleaving: 10 seconds (uniform / late interleaver) LMS satellite channel Satellite EIRP: 63dB C/N in satellite Terrestrial channel AWGN This test has been developed in the laboratory. The results obtained comply with the DVB-SH Implementation Guidelines. 17.3.2.2 LMS channel, rural/suburban, speed 50 km/h.
Target ESR5 fulfillment. Scenario: Reception condition C, rural/suburban, speed 50 km/h. Parameters: Modulation: o QPSK: o 8PSK: phy_cr=1/3 link_cr=2/3 phy_cr=2/9 phy_cr=1/3 phy_cr=1/2 link_cr=2/3
Guard time CGC: 1/4 y 1/8 (baseline) Interleaving: 10 seconds (uniform / late interleaver) LMS satellite channel Satellite EIRP: 63dB C/N in satellite Terrestrial channel AWGN This test has been developed in the laboratory. The results obtained comply with the DVB-SH Implementation Guidelines. The same configuration is been used in scenarios D, obtaining equivalent results.
Page 141
17.3.3 Services Tests 17.3.3.1 Bit rate at MPEG2-TS level in a LMS SU 5 MHz channel. SH-A. Receptor Class 1. Target: Bit rate between 2.2Mbps and 2.8Mbps. Number of services between 8 and 11. Configuration: SH-A Receptor Class 1 Parameter/Case name FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) OFDM Symbols Services Bitrate/services (at TS level)
MPEG TS total bit rate
16QAM_1/4_S 16QAM_2/7_S QPSK1/2_S QPSK2/3_S 2K+GI1/4 16QAM 1/4 2/3 8 8 279,8 kbps 3,357 Mbps 0 ms 211 ms 2K+GI1/4 16QAM 2/7 7/12 7 8 273,6 kbps 3,752 Mbps 0 ms 211 ms 2K+GI1/4 QPSK 1/2 2/3 8 8 279,8 kbps 3,357 Mbps 0 ms 211 ms 2K+GI1/4 QPSK 2/3 1/2 6 8 277,7 kbps 4,443 Mbps 0 ms 211 ms
Early Interleaver Duration Late Interleaver Duration
C/N values calculated in IG simulations for a Category 1 receptor (vehicles) Wave Shape Modulation Link budget LOS C/N (dB) Implementation Loss (dB) C/N for simulations SH-A 12,3 1,1 11,2 SH-A 12,3 1,5 10,8 QPSK 16QAM
C/I values used during the LMS channel simulations. Wave Shape Modulation Link budget uplink C/I (dB) Link budget Satellite C/I (dB) Link budget total C/I (dB) Implementation Loss (dB) SH-A 19,5 14 13 1,1 SH-A 19,5 14 13 1,5 QPSK 16QAM
Page 142
C/N for simulations Speed: 50 km/h Channel: LMS-SU Satellite ERIP: 63 dBW Results: Parameter/Case name Transmission Mode FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) TOTAL Capacity ESR fulfillment
11,9
11,5
16QAM_1/4_S 16QAM_2/7_S QPSK1/2_S OFDM 2K+GI1/4 16QAM 1/4 2/3 2,24 88,20% OFDM 2K+GI1/4 16QAM 2/7 7/12 2,19 93,30% OFDM 2K+GI1/4 QPSK 1/2 2/3 2,24 89,70%
17.3.3.2 Class 1.
Bit rate at MPEG2-TS level in a LMS ILS 5 MHz channel. SH-A. Receptor
The Target and Configurations (except the type of channel) are kept the same as the previous test. Results: Parameter/Case name Transmission Mode FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) TOTAL Capacity ESR fulfillment 16QAM_1/4_S 16QAM_2/7_S QPSK1/2_S OFDM 2K+GI1/4 16QAM 1/4 2/3 2,24 6,8% OFDM 2K+GI1/4 16QAM 2/7 7/12 2,19 6,40% OFDM 2K+GI1/4 QPSK 1/2 2/3 2,24 13,30%
Page 143
17.3.3.3 2
Bit rate at MPEG2-TS level in a LMS SU 5 MHz channel. SH-A. Receptor Class
Target: Bit rate and ESR5 measurement. Configuration: SH-A Receptor Class 2 Parameter/Case name FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) OFDM Symbols Services Bitrate/services (at TS level)
QPSK_1/3_U QPSK_1/3_UL 16QAM_1/5_U 16QAM_1/5_UL 2K+GI1/4 QPSK 1/3 1 12 8 277,7 kbps 2,222 Mbps 11000 ms 0 ms 2K+GI1/4 QPSK 1/3 1 12 8 277,7 kbps 2,222 Mbps 10000 ms 215 ms 2K+GI1/4 16QAM 1/5 1 10 9 296,2 kbps 2,666 Mbps 11000 ms 0 ms 2K+GI1/4 16QAM 1/5 1 10 9 296,2 kbps 2,666 Mbps 10000 ms 215 ms
C/N values calculated in IG simulations for a Category 1 receptor (vehicles) Wave Shape Modulation Link budget LOS C/N (dB) Implementation Loss (dB) C/N for simulations SH-A 12,3 1,1 11,2 SH-A 12,3 1,5 10,8 QPSK 16QAM
C/I values used during the LMS channel simulations. Wave Shape Modulation Link budget uplink C/I (dB) Link budget Satellite C/I (dB) Link budget total C/I (dB) Implementation Loss (dB) C/N for simulations SH-A 19,5 14 13 1,1 11,9 SH-A 19,5 14 13 1,5 11,5 QPSK 16QAM
Page 144
Speed: 50 km/h Channel: LMS-SU Satellite ERIP: 63 dBW Results: Parameter/Case name Transmission Mode FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) TOTAL Capacity ESR fulfillment 17.3.3.4 1 QPSK_1/3_U QPSK_1/3_UL 16QAM_1/5_U 16QAM_1/5_UL OFDM 2K+GI1/4 QPSK 1/3 2,22 100% OFDM 2K+GI1/4 QPSK 1/3 2,22 100% OFDM 2K+GI1/4 QAM 1/5 2,67 100% OFDM 2K+GI1/4 QAM 1/5 2,67 99%
Bit rate at MPEG2-TS level in a LMS SU 5 MHz channel. SH-B. Receptor Class
Target: Bit rate and ESR5 measurement. Configuration: SH-B Receptor Class 1. TDM compatible with OFDM QPSK (GI1/4) Parameter/Case name Bandwidth Modulation PHY FEC rate LL-FEC rate (recomm.) CW per SH-FRAME Services Bitrate/services (at TS level)
T-8PSK_1/3_S T-QPSK1/2_S 4,89 MHz 8PSK 1/3 2/3 79 9 288,9 kbps 3,9 Mbps 0 ms 190 ms 4,89 MHz QPSK 1/2 2/3 79 9 288,9 kbps 3,9 Mbps 0 ms 180 ms
Page 145
C/N values calculated in IG simulations for a Category 1 receptor (vehicles) Wave Shape Modulation Link budget LOS C/N (dB) Implementation Loss (dB) C/N for simulations SH-A 12,3 1,1 11,2 SH-A 12,3 1,5 10,8 SH-B 12,8 0,5 12,3 SH-B 12,8 1 11,8 QPSK 16QAM QPSK 8PSK
C/I values used during the LMS channel simulations. Wave Shape Modulation Link budget uplink C/I (dB) Link budget Satellite C/I (dB) Link budget total C/I (dB) Implementation Loss (dB) C/N for simulations Speed: 50 km/h Channel: LMS-SU Satellite ERIP: 63 dBW Results: Parameter/Case name Transmission Mode FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) TOTAL Capacity ESR fulfillment T-8PSK_1/3_S T-QPSK1/2_S TDM 2K+GI1/4 8PSK 1/3 2/3 2,60 96,7% TDM 2K+GI1/4 QPSK 1/2 2/3 2,60 95% SH-A 19,5 14 13 1,1 11,9 SH-A 19,5 14 13 1,5 11,5 SH-B 20 14 13 0,5 12,5 SH-B 20 14 13 1 12 QPSK 16QAM QSPK 8PSK
Page 146
17.3.3.5 2
Bit rate at MPEG2-TS level in a LMS SU 5 MHz channel. SH-B. Receptor Class
Target: Bit rate and ESR5 measurement. Configuration: SH-B Receptor Class 2. TDM compatible with OFDM QPSK (GI1/4) Parameter/Case name Bandwidth Modulation PHY FEC rate LL-FEC rate (recomm.) CW per SH-FRAME Services Bitrate/services (at TS level)
T-8PSK_2/9_U T-8PSK_2/9_UL T-QPSK_1/3_U T-QPSK1/3UL 4,89 MHz 8PSK 2/9 --52 9 285,2 kbps 2,567 Mbps 11000 ms 0 ms 4,89 MHz 8PSK 2/9 --52 9 285,2 kbps 2,567 Mbps 10000 ms 180 ms 4,89 MHz QPSK 1/3 ---52 9 285,2 kbps 2,567 Mbps 11000 ms 0 ms 4,89 MHz QPSK 1/3 ---52 9 285,2 kbps 2,567 Mbps 10000 ms 180 ms
C/N values calculated in IG simulations for a Category 1 receptor (vehicles) Wave Shape Modulation Link budget LOS C/N (dB) Implementation Loss (dB) C/N for simulations SH-A 12,3 1,1 11,2 SH-A 12,3 1,5 10,8 SH-B 12,8 0,5 12,3 SH-B 12,8 1 11,8 QPSK 16QAM QPSK 8PSK
C/I values used during the LMS channel simulations. Wave Shape Modulation Link budget uplink C/I (dB) Link budget Satellite C/I (dB) Link budget total C/I (dB) Implementation Loss (dB) C/N for simulations SH-A 19,5 14 13 1,1 11,9 SH-A 19,5 14 13 1,5 11,5 SH-B 20 14 13 0,5 12,5 SH-B 20 14 13 1 12 QPSK 16QAM QSPK 8PSK
Page 147
Speed: 50 km/h Channel: LMS-SU Satellite ERIP: 63 dBW Results: Parameter/Case name Transmission Mode FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) TOTAL Capacity ESR fulfillment T-8PSK_2/9U T-8PSK_2/9UL T-QPSK1/3U T-QPSK1/3UL TDM 2K+GI1/4 8PSK 2/9 -2,57 100% TDM 2K+GI1/4 8PSK 2/9 -2,57 100% TDM 2K+GI1/4 QPSK 1/3 -2,57 100% TDM 2K+GI1/4 QPSK 1/3 -2,57 100%
17.3.3.6 Bit rate at MPEG2-TS level in a LMS SU 5 MHz channel. SH-A and SH-B. Receptor Class 1 and 2 Target: Bit rate and ESR5 measurement. Configuration: Reception Category 2b will be tested. Receptor configuration will be the same used in the previous tests. C/N values calculated in IG simulations for a Category 2 receptor (handheld) Wave Shape Modulation Link budget LOS C/N (dB) Implementation Loss (dB) C/N for simulations SH-A 6,2 1,1 5,1 SH-A 6,2 1,5 4,7 SH-B 6,7 0,5 6,2 SH-B 6,7 1 5,7 QPSK 16QAM QPSK 8PSK
C/I values used during the LMS channel simulations. Wave Shape SH-A SH-A SH-B SH-B
Page 148
Modulation Link budget uplink C/I (dB) Link budget Satellite C/I (dB) Link budget total C/I (dB) Implementation Loss (dB) C/N for simulations Speed: 3 km/h Channel: LMS-SU Satellite ERIP: 68 dBW Interleaver: 10 s Results:
QPSK 16QAM QSPK 8PSK 19,5 14 13 1,1 11,9 19,5 14 13 1,5 11,5 20 14 13 0,5 12,5 20 14 13 1 12
TDM for Class 2 receptors and SH-B Parameter/Case name Transmission Mode FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) TOTAL Capacity ESR fulfillment T-8PSK_2/9U T-8PSK_2/9UL T-QPSK1/3U T-QPSK1/3UL TDM 2K+GI1/4 8PSK 2/9 -2,57 87,57% TDM 2K+GI1/4 8PSK 2/9 -2,57 84,43% TDM 2K+GI1/4 QPSK 1/3 -2,57 87,98% TDM 2K+GI1/4 QPSK 1/3 -2,57 86,89%
OFDM QPSK (GI1/4) for Class 1 receptors and SH-B Parameter/Case name Transmission Mode FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) TOTAL Capacity T-8PSK_1/3_S T-QPSK1/2_S TDM 2K+GI1/4 8PSK 1/3 2/3 2,60 TDM 2K+GI1/4 QPSK 1/2 2/3 2,60
Page 149
ESR fulfillment
48,9%
62,1%
OFDM for Class 2 receptors and SH-A Parameter/Case name Transmission Mode FFT Mode Modulation PHY FEC rate LL-FEC rate (recomm.) TOTAL Capacity ESR fulfillment QPSK_1/3_U QPSK_1/3_UL 16QAM_1/5_U 16QAM_1/5_UL OFDM 2K+GI1/4 QPSK 1/3 2,22 84% OFDM 2K+GI1/4 QPSK 1/3 2,22 75% OFDM 2K+GI1/4 QAM 1/5 2,67 51% OFDM 2K+GI1/4 QAM 1/5 2,67 42%
It can be noted that none for Category 2b, the ESR5 90% requirement is never fulfilled.
17.4 Results
Results described in the previous section, following the description of each test.
Page 150
18.
PROJECT SALICE
18.1 Overview
SALICE (Satellite-Assisted LocalIzation and Communication systems for Emergency services) is a two year (October 2008-September 2010) Italian National Research Project, which is funded by the Italian Ministry of University and Research (MIUR) in the framework of PRIN 2007 (Research Project of Relevant National Interest). The project consortium is made up by the following partners: University of Florence (coordinator), Polytechnic of Turin, University of Trento, Mediterranean University of Reggio Calabria, University of Rome Tor Vergata. The project aims at identifying the system architecture and the solutions that can be adopted in the future integrated reconfigurable NAV/COM systems and analyzing their feasibility in realistic emergency scenarios. In order to provide telecommunication facilities for an efficient emergency situation management, the integration between self-organizing space segments (satellite, HAPs - High Altitude Platform) and terrestrial segments (UMTS - Universal Mobile Telecommunications System, TETRA TErrestrial TRunked RAdio) in a single network infrastructure is investigated. Moreover the implementation of a reconfigurable SDR (Software Defined Radio) based terminal, which gathers both navigation and communication capabilities, is one of the main research area of the project. Particular attention is also given to the optimization of the resources management strategies and to the cooperative localization of rescue entities that intervene in emergency areas. 18.1.1 Baseline scenario and System Architecture In order to propose a feasible system the first activity of the project is the definition of the SALICE baseline scenario and the architectural specifications, which enable the design of new solutions to guarantee NAV/COM services in the area of intervention by effectively integrating heterogeneous technologies. The identification of the application scenarios is carried out through a deep analysis of the feedbacks coming from potential end users, which permit the definition of the emergency system requirements. Although the scenarios which can be considered in the SALICE project are multiple and differentiated, it is possible to describe the baseline scenario (Figure 109). The main actors involved in the Emergency Network are: Emergency Control Centre (ECC): facility used by emergency organizations to coordinate the intervention of the Authorized representatives. It is a permanent site, placed generally far from the disaster area. Mobile Master Node (MMN): communication facility employed to guarantee the connection between the ECC and the FRs personnel operating in the emergency area; it is a temporary, mobile station placed at the perimeter of the emergency area. Emergency Vehicle (EV): any kind of terrestrial or marine, generally but not necessarily manned, vehicle that intervenes directly in the emergency area to transport persons (rescuers and rescued people) and tools for the intervention (e.g., water, stretchers, etc). First Responder (FR): person belonging to an Authorized Representatives institution that directly intervenes on the emcergency area as soon as the emergency has occurred. First Responders may be organized in Teams, that intervene on the incident area from different locations, using different ways and possibly different transportation means.
Page 151
Figure 109: SALICE Baseline Scenario
The definition of the baseline scenario represents the input for the specification of algorithms and techniques developed in the project. The Emergency Network Architecture relies on the design of a very robust, reliable and flexible NAV/COM network among the FRs, the EVs and the ECC, which does not (necessarily) depend on the presence in-loco of pre-existing public or commercial services (e.g. GSM, UMTS networks). In several situations the direct radio communication between the Emergency Area and the ECC could be impossible or too expensive in terms of portable terminals battery; in this context an important role is played by the MMN, which guarantees the connection between the ECC and the personnel operating in the emergency area, through a satellite/HAP radio link or through a transportable UMTS Base Station. The HAP provides ad-hoc and temporary communications capabilities, connecting the MMN both with the ECC and with the EVs, while the satellite guarantees very long distance communications between the MMN and the ECC and the ECC and the EVs. In such heterogeneous network, it is possible and necessary to identify some different radio links, or communication modes: Short-range (intra-cluster) radio link: used to transmit voice, data and localization messages among the FRs belonging to the same Cluster.
Page 152
Medium-range (inter-cluster) radio link: used to communicate voice and data with the EVs and the FRs belonging to different clusters. Position information and localization messages also use this link. Long-range radio link EV/MMN-HAP: used to communicate voice and data from the area of intervention to the ECC in the case that EV/MMN cannot communicate with this system. Very-long-range radio link MMN-SAT: possibly used in the case that no HAP is available. Position information and localization messages also use this link.
18.1.2 SALICE Project Research Areas In order to give a brief overview of the project the main research areas, which are investigated in the SALICE framework, are listed, highlighting the aim of each one: Cooperative Localization. The design of a Core Localization Framework (CLF) able to seamlessly cope and self-adapt with a heterogeneous and time-varying operational condition is carried out and hybrid scenarios are considered together with it. The investigation of this topic is due to the requirement of a timely and precise localization of the rescuers for the coordination and planning of search, rescue and disaster relief operations, in terms of efficacy and safety for both rescuers and injured people. Reconfigurable NAV/COM System. The definition of a reconfigurable and flexible user terminal able to modify itself to cope with any NAV/COM requirements is carried out. In particular a feasibility study for a fully software handset based on SDR (Software Defined Radio) is performed. The investigation of this topic is due to the important requirement of the integration of communication systems and localization/navigation services for coordination of the emergency operations. System Integration by Space Segments. The design of an efficient and flexible NAV/COM network among the FRs, the EVs and the ECC, in the long range radio link, has been carried out through the system integration by space segments (satellite and HAPs). Both Radio Resources Management strategies and the implementation of mechanisms to deliver Multicast information to different groups of first responders are studied. The investigation of this topic is due to the requirement of the implementation of an efficient emergency network, which can substitute the damaged one, guaranteeing a global coverage of the emergency area and a mean to connect the incident area with external areas. Incident Area Network. The design and definition of the scenario for the Incident Area Network together with protocol solutions for location/environment data and information delivery through heterogeneous wireless networks is carried out. The most suitable PHY technologies as well as efficient coexistence mechanism for bridge devices are analyzed. The investigation of this topic is due to the requirement of improving the availability, the accuracy and the exploitation of context location and environmental information concerning the user, the surrounding area and the heterogeneous networks.

One of the aim of SALICE project is to develop and test a reconfigurable SDR (Software Defined Radio) based terminal, which integrates navigation and communication capabilities. In this section the NAV/COM architecture of the SALICE Terminal is analyzed. In particular the two logical and functional parts (navigation and communication component) and their integration, which involves the problem resolution of the interaction and interface between the two modules are described.
Page 153
18.2.1 Navigation Component The NAV component of the SALICE terminal is a SDR receiver. The SDR approach enables an easy customization and the investigation of different algorithms for the implementation of specific applications and new solution. Moreover the need to cope with any NAV/COM requirement and the aim of designing the Core Localization Framework lead to adopt SDR receivers for the definition of a reconfigurable and flexible user terminal. The SDR navigation component, which foresees the development of an innovative peer-aided GPS algorithm, is based on two different software receiver architectures: N-Grab N-Gene
N-Grab is a software tool developed by the NavSAS group of Polytechnic of Turin and ISMB (in Turin), able to store the SIS (Signal In Space) signal without any signal processing. The SIS signal detected by a commercial GPS L1 antenna is down-converted and sampled by means of a frontend (FE). Using a USB connection, N-Grab acquires and stores the stream of raw samples at the Analog to Digital Converter (ADC) output into a binary file. This is a fundamental tool for our research activity because it supplies portions of the SIS stored in binary files that can be used to off-line processing. N-Grab does not need any particular hardware platform but it can be executed by an off-the-shelf Linux personal computer (PC). A fast Hard Disk is required to avoid data loss. N-Gene is a fully software GNSS receiver able to perform all the processing needed for a navigation receiver. It has been developed by NavSAS group within the framework of the IRGAL (Innovation and Research on GALileo) project. As N-gene it is a SDR receiver, the signal processing (code and carrier wipe-off, acquisition, tracking, demodulation of the navigation message, pseudorange evaluation and PVT calculation) is performed through software implemented algorithm and included in the SW receiver architecture. N-Gene can run on a standard Linux PC. Besides the PC, the only needed hardware is the FE that down-converts and samples the received satellites signals. N-Gene can work with several kinds of FEs equipped with USB connection; both low cost front-ends, characterized by a few bits resolution and low sampling rate, and professional FEs with high sampling frequency and high bit resolution can be used. N-Gene is able to process GPS and Galileo signals on the L1/E1 bands. Moreover, it can demodulate the differential corrections broadcast at the same frequency by the EGNOS system. N-Gene can be logically divided in several modules combined together. The modules that work at low data rate are written in ANSI-C language whereas those working at higher rate are written in assembler to use processor specific optimizations. Besides N-Gene is split into two main blocks: one dedicated to the receiver functionalities and another dedicated to the output visualization, which is based on a Graphical User Interface (GUI) written in Java language to ensure portability among different operating systems.
Page 154
Figure 110: N-Gene Block Diagram In Figure 110 a high level block diagram of the N-Gene software architecture is depicted. Both the front end (left side of the diagram) and the N-Gene software routines (right side of the diagram) are shown, highlighting the USB 2.0 connection, which makes the receiver particularly versatile to be connected to any RF front-end with USB interface. At the moment the platform has been successfully tested with different commercial and prototype front-ends, featuring 3-to-6 MHz IF bandwidth @L1/L2 and 1-to-8 quantization bits using a sampling frequency in the range 13-to-20 MHz. In detail the USB driver controls the data flow from the ADC, while the acquisition and tracking blocks represent the core of the baseband signal processing. As soon as the receiver tracks at least four satellites, it is able to compute the user position and velocity, through the estimation of the distance between the user and the set of satellites (i.e.: pseudorange estimation). The receiver can be remotely controlled by the Graphical User Interface (GUI) through a TCP/IP protocol. This feature allows the implementation of a cooperative localization architecture among two or more terminals, which is one of the project research area. Thanks to the software flexibility, the user is allowed to configure the receiver by specifying a wide range of parameters, for example by assigning/excluding specific signals (i.e.: GPS, Galileo or EGNOS) or satellite codes to each channel, configuring thresholds and Doppler search of the signal acquisition, selecting the tracking loop bandwidths, the Delay Lock Loop (DLL) spacing and the integration time. Similar configuration rights could be assigned to an automatic procedure driven by a remote terminal that provides assistance to the receiver in case of critical LOS conditions, so as to implement a form of cooperative localization. On the other side, the N-Gene based assistance terminal is able to output its relevant parameters thanks to the same TCP/IP link to an additional virtual GUI represented in this setup by the impaired terminal. As far as the N-gene positioning performance is concerned, in open sky the receiver can achieve: a position accuracy lower than 10 meters rms and a Time-To-First-Fix (TTFF) with cold start condition lower than 45 s. These performance figures show that the receiver is surely competitive
Page 155
with respect to any other commercial/mass-market solution in terms of positioning performance, while it gains in versatility of use. Furthermore, the receiver is able to process many channels in real time, the max number of channels processed at the same time depends on the CPU speed. A common present PC can process up to 12 channels in real time. The state of the channel is managed by an activity manager. The possible states of the channels are: Idle mode: at the beginning after the receiver initialization. Acquisition mode: when a satellite PRN is assigned to the channel. Tracking mode: when a PRN is declared present and a refinement of the code delay and Doppler shift is found. Navigation mode: when the subframe synchronizations are achieved.
N-Gene is able to provide outputs as log files or through its GUI. The receiver measurements can be collected in the standard Rinex3 or NMEA formats or in proprietary formats. Furthermore, NGene is able to record the raw data at the FE output. The outputs displayed by the GUI are: user position on a digital map, GPS and UTC (Coordinated Universal Time) time, current dilution of precision, the satellites position on a polar diagram and the correlator outputs. 18.2.2 Communication Component The COM component of the SALICE terminal, developed at the University of Florence, is a SDR transceiver, based on the GNU radio platform. GNU Radio is an open source software toolkit created for building and deploying Software Defined Radios (SDR). When combined with a minimal hardware, it allows the construction of radios where the transmitted (and received) waveforms are defined by software. More in detail, GNU Radio is a hybrid system C++/Python. The radio communication chain can be represented by a graph where the vertexes are the signal processing blocks and the edges represent the data flow between them. The signal processing blocks are implemented in C++ and the graphs are constructed and run in Python. Therefore, Python is used to glue the signal processing blocks constituting the communication chain. The main feature of GNU Radio is that the parameters, and even the inner structure, of the graph can be changed on the fly, that is when the simulation is running. Therefore our terminal can change its inner structure to adapt to the existing communication systems, a very interesting feature for the architecture of a reconfigurable and flexible terminal like SALICE. The hardware combined is the Ettus Universal Software Radio Peripheral (USRP), a general purpose motherboard that gives access to the radio frequency spectrum and can be connected with any computer (that support GNU Radio software) with a USB 2.0 port.
Page 156
Figure 111: Universal Software Radio Peripheral (USRP) The USRP (Figure 111) is designed to allow general purpose computers to function as high bandwidth software radios. In essence, it serves as a digital baseband and IF section of a radio communication system. It has 4 high-speed analog to digital converters (ADCs), each at 12 bits per sample, 64MSamples/sec. There are also 4 high-speed digital to analog converters (DACs), each at 14 bits per sample, 128MSamples/sec. These 4 input and 4 output channels are connected to an Altera Cyclone EP1C12 FPGA. The FPGA, in turn, connects to a USB2 interface chip, the Cypress FX2, and on to the computer. The USRP motherboard supports four daughterboards, two for receiving side and two for transmitting side. RF front-ends are implemented on these daughterboards. We use daughterboards that operate in the 2.4 GHz band, with baseband bandwidth of 8 MHz. Another interesting feature of GNU Radio is the opportunity to have particular drivers, called universal TUN/TAP drivers for tunneling the packets from the USRP to the Linux kernel (via USB 2.0). These TUN/TAP drivers provide the reception and transmission of packet for user space processes. They can be seen as a simple Point-to-Point or Ethernet devices, which, instead of receiving packets from physical media, receive the packets from user space process and instead of sending packets via physical media writes the packets to the user space process. Depending on the type of device chosen, the user space program has to read/write IP packets (with TUN) or Ethernet frames (with TAP). GNU Radio, using these TUN/TAP drivers, can create a program that provides a framework for building our own MAC protocols. The Linux 2.6 kernel includes already the TUN module. Therefore running two copies of this program on two different machines, we can allow the communication between these. 18.2.3 Navigation and Communication Integration The integration of NAV and COM modules on the same terminal represents one of main objective of the project. As described in the previous sections, since both the NAV (N-Gene) and the COM (GNU Radio) modules work on the Linux OS, the use of Linux Ubuntu OS (in particular the first test campaign is made on Ubuntu 9.10) is chosen. Therefore, the interface between NAV/COM modules can be easily realized by TCP sockets realized through, for instance, Python routines (Figure 112).
Page 157
Figure 112: Integration of NAV/COM Systems in SALICE Terminal The main integration issues, which must be analysed, regards: the compatibility between the two modules and the synchronization performance among the users involved in the peer-based localization. Compatibility between the NAV and COM modules is essential to implement a single demonstrator that has both COM and NAV capability. Whereas the users synchronization is the main required condition to implement a reliable and efficient peers-based aiding GNSS algorithm. Furthermore, the synchronization features are very important to establish what aiding data have to be exchanged and how to use them.

In this section a detailed analysis of the demo architecture and preliminary test campaign, which is carried out in the SALICE framework, are reported. The preliminary test session was performed in Florence (April 2010). The test-bed is composed of two NAV/COM demonstration terminals, which represent two different SALICE Terminals used by two First Responders belonging to the same rescue team. As depicted in Figure 113 each demo terminal is represented by a laptop PC equipped with: a GPS patch antenna a GPS front-end N-Gene/N-Grab (NAV component) USRP + GNU Radio (COM component)
Page 158
Figure 113: SALICE Demonstrator A low cost patch antenna is used. It is a single frequency active antenna, with a built-in LNA that provides a gain equal to 35 dB on the L1 band. This kind of antenna is characterized by a small size (typ. 5x5 cm) and weight (typ. 40 grams). The used front-end is the GN3S sampler v2 that is a high-end research device for L1/E1 bands. It is based on the SiGe 4120L GPS ASIC and makes a single frequency conversion of the GPS signal. The scope of the front-end is to capture raw GPS data and to pass them in binary stream to the PC. A RF input is used for the antenna connection. The front-end has an USB connector as output. It allows to connect easily the front-end to a PC. The front-end is composed by the following parts: a Low Noise Amplifier (LNA) that amplifies the input RF signal a mixer that converts the input signal to an intermediate frequency (IF) an IF filter that provides interference rejection an Automatic Gain Control (AGC) and an Analog to Digital Converter (ADC) with serialized data output.
The main features of the front-end are: Sampling frequency of 16,368 MHz an I and Q samples of the signal are provided at nearzero IF a LNA with high gain (typ. 18,5 dB) is included
The PCs of the two demonstrators are equipped with a Linux Ubuntu 9.10 operating system and each PC has a 2 GHz processor. In the next subsections the two main tests, already carried out, are described, highlighting their aims and the steps that are followed.
Page 159
18.3.1 Compatibility test The Compatibility Test is performed to evaluate the possibility to use at the same time the NAV and the COM components in a single demonstrator. This is the preliminary integration test, which aims at highlighting the possible incompatibilities issues between the two modules.
Figure 114: Compatibility Test: Testbed Scheme The test is demonstrated running both the NAV and the COM modules at the same time in the same demonstrator (Figure 114). 18.3.2 Synchronization test The Synchronization Test is variance, maximum, minimum achieved through a standard different protocols are tested: Protocol) protocols. performed to characterize the synchronization error in terms of and mean value. The synchronization between the terminals is synchronization protocol commonly used in PC networks. Two the NTP (Network Time Protocol) and the PTP (Precise Time
The test involves two SALICE Terminals in open sky condition, receiving at least one common satellite (Figure 115). Furthermore the terminals must be quite close one another to detect GPS signals as similar as possible. Otherwise, a single GPS antenna for the two terminals could be used, followed by an RF signal splitter which feeds both the terminals.
Page 160
Figure 115: Synchronization Test: Testbed Scheme A TCP/IP connection is established by means of the COM modules. This communication link established by the USRP COM module is used to exchange NTP/PTP messages in order to make the two terminals synchronized. The NAV component is not used for positioning issue but it is only used to estimate the synchronization error. Both the NAV software tools, N-Grab and N-Gene, are used. The former is used to store the SIS signal in one PC and to store in a log file the time when the USB buffer is read. The latter is used to process the stored GPS signals. The results of this processing is a log file that identifies special samples inside the stored GPS signal. An algorithm implemented in C language uses this information to evaluate the synchronization error. In detail the Synchronization Test, which allow the estimation of the synchronization error, consists in the following steps: Launch NTPdate in order to synchronize the clocks of the two demonstrators. The synchronization is achieved with only one singular correction. After that the synchronization is not maintained. Launch NTPD in order to improve and maintain the synchronization. The COM modules are used to exchange synchronization messages. Launch N-Grab in order to store the GPS signal and a log file on the hard disk. The data recording must be collected in open sky. Use N-Gene to elaborate the stored signals creating the counters log file. Launch the C language script to estimate the synchronization error using the log files created in the previous steps. For the synchronization error calculation, the sampling period of the front-ends is used as reference.
Page 161
18.4 Results
The SALICE project first campaign test was performed in April 2010. In the following the preliminary results of the two performed tests are summarized: the Compatibility Test demonstrated the compatibility of the Navigation (NAV) and Communication (COM) modules. Both can run on the same PC at the same time without any problems. This result is achieved thanks to the preliminary attention given in the implementation phase of both the NAV and the COM component. the Synchronization Test demonstrated the possibility to synchronize the two terminals in clear sky; on-going activities are carried out to verify, and possibly improve, the synchronization in different propagation conditions.
The experimental activities are still on-going and the results from the field trials and demonstrations are still under analysis and could be reported in the subsequent releases of this document.
Page 162
19.
PROJECT E-SPONDER
19.1 Overview
The E-SPONDER A holistic approach towards the development of the first responder of the future project is a large scale IP funded under the FP7 in the call SEC-2009.4.2.1: First Response of the future. It started on July 2010 and it has a duration of 48 months. The ESPONDER is a suite of real-time data-centric technologies which will provide actionable information and communication support to first responders that act during abnormal events (crises) occurring in critical infrastructures. This information will enable improved control and management, resulting in real time synchronization between forces on the ground (police, rescue, firefighters) and out-of-theater command and control centers (C&C). ESPONDERs main objective is to research, develop and demonstrate the capabilities of a framework and congruent prototype that will enhance the effectiveness of operations of first responders (FR) operating in Critical Infrastructures

Within E-SPONDER, satellite communications play a vital part. They are the backbone communications that facilitate the availability of local awareness (from the operation theatres) to any given and remotely-located EOC (emergency operation centre) . Satellite communications are therefore of paramount importance, as the ability of the satellite signal to reach even the most isolated of regions (especially where other communication infrastructure is not present), so that they are crucial in ensuring the continuous monitoring of first response operations. Effective on-scene data transmission and voice communication is made feasible at all times with the use of satellites and this helps with ensuring the E-SPONDER will constantly support the work of first response crews. The suggested architecture (Figure 116) shows that data from the FRs is sent in real-time to the locally operating Mobile EOC and then filtered, grouped and relayed to the remote-located EOC. Maintaining the link between the dispersed FR Units (FRU) and the EOC is made feasible through the use of satellite communications at all times, given the fact that FRs normally act either in remotely located areas with limited communication infrastructure or in sites where existing communications might be crippled by the occurred disaster. One of the test-bed activities regards the network infrastructure at the MEOC. A possible approach is as follows: 1. At a first stage, we can insulate the core MEOC tasks, by assuming the MEOC as logically (de)composed by a conventional router interconnected (by the mean of Ethernet links) to external ``network portals'' (thus, keeping the transcoding functionalities at the portals and using Ethernet as an intermediate protocol among the portals and the MEOC router); 2. A step further is to substitute the physical network portals and their related inner networks with network emulators (one emulating the 802.11s mesh, an other one the satellite link, and so on), with the charge of producing or gathering traffic flowing through the router, to evaluate the most
Page 163
advantageous design choices for our infrastructure. Figure 117 depicts the logical schema of this approach; 3. As a final step towards the true MEOC implementation, the emulators can be gradually substituted by the authentic networks, bringing all the MEOC functionalities inside the all-in-one equipment
Figure 116: Emergency Network Architecture
Figure 117: Logical schema of the proposed MEOC testbed
Page 164
20.
FRAMEWORK FOR FUTURE WORK ON TRIALS AND DEMONSTRATIONS
In the previous sections we presented a considerable non-exhaustive number of projects dealing with mobile, broadband and broadcast satellite communication systems and services. The majority of these projects have conducted trials and/or demonstrations in order to validate specific concepts that constituted part of their primary objectives. Based on this considerable experience drawn in the SatCom trials and demonstration field, it is now important to highlight areas for possible synergies among these projects and the nature and subject area of potential follow-on projects in the scope of forthcoming EU and ESA calls. The revised ISI Strategic Research and Innovation Agenda (SRIA) focuses on particular application domains, which will contribute most to European competitiveness, economic growth and well being of the European citizens, and includes: Infotainment: The challenge ahead for broadcast satellite system to provide improved quality of experience while reducing the environmental impact associated to user terminal antennas and to support interactivity for value added services and personalisation; Broadband for All: The right of each European citizen to access to the Information society without any geographical discrimination, particularly for the new generation networks which will provide very high speed rates capacity for enterprises and citizens, as crucial tools for the economic development and social well being. This is in line with the Digital Agenda Policy targeting universal broadband coverage objectives with internet speeds gradually increasing around 30 Mbps at the horizon of 2013-2014, and up to 100Mbps in the longer term (post 2020). Security: The need to develop solutions to efficiently address Disaster management and External security actions, Border and maritime surveillance, Critical infrastructure protection and Transport security. This relates to the European Security and Defence Policy targeting an improve Europes capacity to prevent and respond to crisis or disaster situations wherever they may occur. FI-enabled Smart Infrastructures for healthcare, energy, transport or environmental protection: Combining their dependability/resilience and ubiquitous access properties, SatCom can be profitably exploited in smart infrastructures enabling a more sustainable and efficient economy, by ensuring harmonised use of natural resources, to mitigate the effects of climate change and to preserve our environment. Research and Innovation is needed to optimise the added value of SatCom thanks to appropriate FI terrestrial/satellite integration scenarios. Based on this revised ISI SRIA, we attempt below to categorize respectively the above listed projects in order to highlight areas for possible synergies among them as well as the nature and subject area of potential follow-on projects in the scope of forthcoming EU and ESA calls. Table 5: Possible Synergies among the Listed Projects ISI SRIA Application Domain Infotainment
MOVISAT
Listed Projects
-
Areas of Potential Follow-On Projects

Enhanced HDTV, 3DTV & higher multi-view TV Broadcast Enhanced Mobile Radio and TV
Page 165
ISI SRIA Application Domain
Listed Projects
Areas of Potential Follow-On Projects

broadcast service Smart FI-enabled content management systems for culture and knowledge Handheld services via terrestrial/satellite networks hybrid
NETADDED MOVISAT NETADDED, MULTESEM, DVBRCS Simulator/ Emulator, FT3 VoIP over Satcom, VOTOS, WICHMO, Satellite-WiFi Handover Simulation, INTERSECTION, Cross-Layer IPSec, MOVISAT, EGGS VOTOS SISTER EMERSAT, SALICE SISTER, WISECOM, SFEDONA, ESPONDER
High and very-high speed broadband Internet access
Broadband for All
IPTV convergence Enhanced connectivity buses and airplanes to trains,
Enhanced systems for defence and security Public Safety (Border & Maritime surveillance, Critical infrastructure protection, Transport security) Global Monitoring for Environment and Security (image for all, fast delivery and tasking, etc)
Security
TANGO SISTER, SALICE, WISECOM, SFEDONA, E-SPONDER MULTESEM, DVB-RCS Simulator/ Emulator, FT3 VoIP over Satcom, VOTOS, WICHMO, Satellite-WiFi Handover Simulation, INTERSECTION, Cross-Layer IPSec, EGGS
Integrated terrestrial/satellite Traffic Management (ATM)
Air
Hybridization of EO, navigation & telecom applications
Terrestrial/Satellite Network Integration within NGN and FI
FI-enabled Smart Infrastructures
NETADDED SISTER SFEDONA, E-SPONDER, TANGO
FI-enabled Smart Infrastructure for Healthcare FI-enabled Smart Infrastructure for Energy FI-enabled Smart Infrastructure for Transport FI-enabled Smart Infrastructure for Environmental protection
The definition of new trials and demonstrations scenarios that are proposed to be integrated in existing and future EU and ESA related activities is mainly driven by the research activities already
Page 166
undertaken and by those envisaged for the years to come. Based on the revised ISI SRIA, we attempt to identify in Table 6 below the scope of future possible trials and demonstrations in the SatCom field. Note that the majority of those scenarios are relevant to mainly all ISI SRIA Application Domains identified in Table 5 above. Table 6: Possible Future Demonstration Scenarios across Relevant Segments Possible Demonstration Scenarios across Space Segment Possible Demonstration Scenarios across Ground Infrastructure Possible Demonstration Scenarios across Radio Interfaces
Optimisation of in-orbit capability for broadband applications Terabit Satellite and, specifically, the reduction of beam size Impact of satellite platform performance Power, bandwidth and frequency allocation per beam flexibility Antenna reconfigurability Satellite payload and RF front-end flexibility On-board beamforming and multiuser detection Small satellites constellation cluster High capacity feeder links Higher frequency bands such as Q/V but also laser communications Multi-gateway architectures enabling distributed processing of feeder links signals Distributed radio resource management algorithms for fully meshed networks Advanced Interference management and cancellation techniques Flexible, dynamic, and efficient spectrum usage Spectrally efficient and flexible communication techniques Interference management techniques Flexible radio interfaces for QoS Scalable Video Coding combined with Variable Coding and Modulation (SVC/VCM) for Enhanced Broadcast Experience (SDTV/HDTV/3DTV) Network management protocols harmonisation between satellite and terrestrial networks Adaptive middleware to cope with new approaches such as dynamic spectrum management sharing between satellite and terrestrial networks and cooperative techniques De-centralised radio resource management algorithms Flexible resource management among different radio interfaces Efficient protocol stacks for MANETs Vertical handover techniques between terrestrial and satellite interfaces FI network integration techniques Consumer Handheld Terminal Professional Handheld Collective Terminal Mobile Broadband and Broadcast Terminal Fixed Broadband and Broadcast Terminal SCADA/M2M Terminal
Possible Demonstration Scenarios across Networking
Possible Demonstration Scenarios across Terminals
Last, with respect to future EU and ESA programmes where new proposals focusing on the previously identified SatCom related fields can request for funding, a non-exhaustive list of such funding schemes is provided below: EC FP7/FP8 o ICT
Page 167
o FI PPP o SPACE o SECURITY o SST (Transport) o SME ESA o ARTES o IAP Ambient Assisted Living (AAL)
Page 168
21.
CONCLUSIONS
In the present ISI Trials & Demonstrations Report, a survey of existing EU, ESA, National and InHouse R&D projects relevant to SatCom was carried out. The main focus was on the testbed configurations that were used by each project, the demonstrations and trials that were conducted (or were planned to be conducted), and an overview of the available results wherever available. After the detailed presentation of each contributing project, the report indicated also the areas for possible synergies among the listed contributing projects as well as the subject area of potential follow-on projects in the scope of forthcoming EU and ESA calls. Last, possible trials and demonstrations scenarios were identified, which need to be further conducted in order to actively promote and secure the future commercial SatCom systems and services.
Page 169

Sister Project

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sister Project

Caricato da

Copyright:

Formati disponibili

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Report on Trials and Demonstrations

List of Contributing Projects

URL www.satnex.org www.satnex.org

www.satnex.org www.satnex.org www.satnex.org www.wisecom-fp6.eu telecom.esa.int www.netadded-project.eu www.sister-project.org www.teladnetgo.eu

www.satnex.org www.asi.it/en/activity/telecommunications/emersat_ http://www.intersection-project.eu

Report on Trials and Demonstrations

Italian Ministry of University and Research EC FP7 SECURITY

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Project SATNEX JA2410 FT5 MULTESEM...................................................................... 20

Project DVB-RCS Simulator/Emulator ............................................................................ 26

Project SATNEX JA2410 FT3 VoIP over Satcom ........................................................... 34

Project SATNEX JA2410 FT4 VOTOS ............................................................................. 41

Project SATNEX JA2410 FT1 WICHMO .......................................................................... 45

Project WISECOM ............................................................................................................ 50

Report on Trials and Demonstrations

Project SFEDONA ............................................................................................................ 63

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Report on Trials and Demonstrations

PROJECT SATNEX JA2410 EGGS

Report on Trials and Demonstrations

2.2 Testbed Description

Report on Trials and Demonstrations

2.3 Trials and Demonstrations

Report on Trials and Demonstrations

Data Transmitted [Kbytes]

0 0 200 400 600 Time [s] 800 1000 1200

Figure 1: Diagram sequence for the four investigated scenarios.

Report on Trials and Demonstrations

Figure 3: Received datagrams vs. time for the DTN/TCP trial.

Report on Trials and Demonstrations

PROJECT SATNEX JA2410 FT5 MULTESEM

3.2 Testbed Description

Report on Trials and Demonstrations

Report on Trials and Demonstrations

3.3 Trials and Demonstrations

Report on Trials and Demonstrations

Tx sequence number (bytes)

2.5E+07 cwnd 2.0E+07

cwnd, ssthresh (segments)

0.0E+00 0 50 100 Time (s) 150

Report on Trials and Demonstrations

Report on Trials and Demonstrations

50.0% 45.0% 40.0% 35.0%

30.0% 25.0% 20.0% 15.0% 10.0% 5.0% 0.0%

Report on Trials and Demonstrations

PROJECT DVB-RCS SIMULATOR/EMULATOR

Report on Trials and Demonstrations

4.2 Testbed Description

Report on Trials and Demonstrations

Report on Trials and Demonstrations

Figure 10: Conceptual Emulator Architecture

Report on Trials and Demonstrations

Figure 11: Real Emulator Layout