Iris Event 11 THAUMAS

Transcription

1 Iris Event 11 THAUMAS Tailored and Harmonised satcom for Atm Uses, Maximising re-use of Aero Swiftbroadband 10 th October, 2011

2 Agenda 1. Overview 2. Updates on Inmarsat progress and perspectives 3. Presentation of future activities -2-

3 Overall schedule May-10 Iris Event #1 Oct-11 Iris Event #2 THAUMAS Ph. 0 THAUMAS Ph. 1 Jan 2010 Jan 2011 Jan 2012 Jan 2013 Nov-09 Mar-10 Jul-11 Mar-13 Summary of phase 0 outputs (presentation, part 1) Updates on SwiftBroadband oceanic safety (presentation, part 2) Overview of phase 1 (presentation, part 3) -3-

4 What is THAUMAS about? Inmarsat 3 MT-SAT Inmarsat 4 Alphasat Aircraft terminal Services Satellite Performances (G/T) Services requirements More stringent than RCP240 (Continental airspaces) RCP240 compliant (Oceanic airspaces) Performances (Antenna) HGA >10dB Classic Aero Safety services 6dB Baseline for satellite performances IGA THAUMAS=SB-S SwiftBroadband Oceanic Safety 6dB LGA Available by

5 Key outcomes of phase 0 Current Iris requirements have to be clarified/confirmed to avoid system design over sizing Dual-link concept Service area Performances expectations SwiftBroadband is flexible baseline: it is expected that SB-S will be compliant with the current requirements Pending on the updated expression of requirements expected from SESAR Detailed verification and validation of the compliance to be done in next phases Upgrades to the SB system have been identified based on an analysis of the compliance to the SRD requirements The THAUMAS consortium has defined an achievable roadmap to SB-S Proof of Concept The resulting SB-S protocol will be an open standard -5-

6 Agenda 1. Overview 2. Updates on Inmarsat progress and perspectives 3. Presentation of future activities -6-

7 Key Considerations Inmarsat s Swift Broadband Aeronautical Oceanic Safety Programme provides risk mitigations for Iris both in terms of technology and schedule The ESA Alphasat-Extension Programme already underway under ARTES 8.4 addresses key components for implementation of Aero Safety The overall SB approach (SB Oceanic Safety and SB-S) to Aero Safety provides an evolutionary path as well as a cost efficient and spectrum efficient solution for European continental aero safety -7-

8 Inmarsat Swift Broadband Oceanic Safety Programme will provide airlines and ATSPs with a new RCP240- compliant forward solution via a primary service over SB with the capability to fall back to Classic Aero New IPS service to the cockpit to support new aero safety applications New SB200 service provided over smaller, lighter, cheaper terminal Start of operational SB Oceanic Safety service: Q Currently in final stages of system design and procurement Development supported by ESA ARTES 8.4 programme Industry Partners Committed Built-in aircraft positioning function supports SESAR JU s SAT-OPTIMI objectives for improved aero safety through satcom -8-

9 Avionics Class 6 (High Gain) Class 7 (Intermediate Gain) SB200 Alphasat-X Activity 1: System Design A range of antenna systems already exist for SwiftBroadband services Manufacturers are currently prototyping new antennas SB200 that will improve performance at low elevations Extensions to the Swift Broadband air interface New bearer types THAUMAS phase 1 will be around Taking into account multipath from earth and aircraft surfaces Helicopter waveform to optimise operation on rotary wing -9-

10 SB Oceanic Safety Services - Products SB Safety Services RCP 240 Efficiency RCP 240 Safety Class 6 (HGA) SB/Classic Class 6 (HGA) SB Only Class 7 (IGA) SB Only SB (small antenna) SB Only All will support the following sub-services: ACARS Data and prioritized IP Data 2-channels of voice (one CS, one digital voice) Down to 5 degrees elevation -10-

11 Agenda 1. Overview 2. Updates on Inmarsat progress and perspective 3. Presentation of future activities -11-

12 THAUMAS phase1: Overview Partners EADS Astrium Satellites: Prime and coordinator, management of system requirements (critical review and system compliance), system verification plan and verification test bed specification, system simulator design and development Inmarsat: System architecture definition, SwiftBroadband air interface and protocol adaptation, functional test bed design and development, Costing, Service deployment plan DEIMOS: definition and classification of hazards, apportionment of the RTCP parameters. Safety assessment as well as the consolidation of the Dependability and Certification Plan Logica: dependability analysis to determine the reliability, availability and maintainability of the SB-S against a set of derived dependability requirements. IT security assessment of the system against the defined security requirements. SITA: definition of the EATMS architecture by the time needed for enhanced SB-S integration into EATMS. University of Salzburg: review of the Long Term Forecast and refinement of application, creation of traffic scenario for validation activities -12-

13 THAUMAS phase1: Schedule Jul-11 Kick-off Mar-12 Partial System Architecture review Feb-13 Partial Design Review/Final Review Jul-11 - Mar-12 Part 1 Mar-12 - Feb-13 Part 2 janv.-12 janv.-13 juil.-11 Sep-12 Development report Oct-12 Early Prototype Review févr.-13 System Requirements Analysis and Specification System architecture definition Communication standard upgrades and specifications System verification plan and verification test bed specification Costing Service Deployment Plan Verification test bed design and development System verification Costing Consolidation -13-

14 Technical updates for ATM services -14-

15 THAUMAS phase 1 SoW: Technical improvements/new items vs SB Oceanic Safety Random Access MUD & short latency New TCDMA waveforms to support highly efficient low latency signalling, transaction-oriented data, and party-line voice services Decentralized ground segment Not required/less critical in oceanic airspace Fast System Recovery Definition of failover scenarios and identify the transient system loads that result in each scenario to determine whether start-up existing mechanisms are sufficient for ATM applications Multicast services Optimisation of resource management algorithms for large scale transactionoriented communications -15-

16 Random Access MUD & short latency Random Access Multi User Detection Multi-User Detection receivers in the Radio Access Network can support highly efficient low latency signalling, transaction-oriented data, and partyline voice services. The physical bearer designs have been completed under Alphasat extension and initial simulation framework createdsimulation framework has been created for testing in maritime and vehicular scenarios development of the Link Budget Simulation Tools for operation with aeronautical and helicopter channel models will be done, to assess the performance and capacity of the physical bearers Short Latency Support The default behaviour of the Swift Broadband system is to release the Radio Access Bearers after typically 60 seconds Low-latency requirements of the COCR traffic requires mechanisms to ensure RABs remain persistent Design and validation of modifications to the RRM algorithms and state machines in the CN and MT to minimise signalling will be undertaken. -16-

17 Decentralized ground segment Seamless Satellite and Inter-RNC Handover Regional SAS operation without service interruption, requires seamless handover mechanisms in the RNC and to utilise the techniques which are already available in the 3GPP Core Network that is used to support Swift Broadband. Initiation of detailed design of the inter-rnc interface and detailed specification of the air interface signalling and MT requirements will be undertaken Fully Decentralized, Fully Interconnected Ground Segment Utilising the concept of a fully interconnected ground segment allows seamless handover to take place in normal operation without requiring the mobility and network routing updates offered by the ATN-OSI and ATN-IPS networks to be activated, thereby reducing latency for handover and ensuring continuity of service operation. The design and implementation of seamless inter-rnc handover and the implementation and configuration of mobility within the SB core network will be assessed -17-

18 Multicast Services Multicast services are anticipated to be required to efficiently support new AOC applications and potentially partly-line voice. Multicast bearer services have been defined, implemented and validated using end-end applications on a proof-of-concept system within the BGAN-extension phase 2 ARTES-3/4 programme. Future design activities are associated with optimisation of resource management algorithms for large scale transactionoriented communications -18-

19 Fast System Recovery The SwiftBroadband system includes a mechanism that provides a means of controlling the rate at which mobile terminals register during system recovery requirements will be determined subject to analysis of the load associated with the start up procedure for individual RNCs, as determined by the scalability simulations to be undertaken during THAUMAS and conclusions on the distributed topology of the ground segment. definition of the failover scenarios and identification the transient system loads that result in each scenario to determine whether start-up existing mechanisms are sufficient. -19-

20 THAUMAS phase 1 SoW: Operational aspects Dependability analysis a dependability analysis to determine the reliability, availability and maintainability of the SB-S against a set of derived dependability requirements allocate software assurance levels (SWALs) to SB-S components according to defined criteria conduct an IT security assessment of the system against the defined security requirements Costing Cost estimation of the SB-S upgrades and modifications to comply with the SRD Estimation of deployment costs Estimation of cost of operations Service deployment plan Definition and maintenance of an end-to-end schedule for deployment of the SB-S system -20-

21 THAUMAS phase 1 SoW: Validation aspects Validation activities will be based on: Inmarsat hardware test bed Astrium software simulator Objective: justify compliance matrix -21-

22 THAUMAS Testbed overview: waveform Hardware Proof-of-Concept (PoC) App data FWD bearer modulator Forward Link Physical Layer Proof-of-Concept (FWD PoC) (GES to UT) Channel Emulator FWD bearer demodulator Performance Results Verification PHY simulation tool (by WIS) SPCI s BGAN Physical Layer Tester (BPLT) product Performance Results Verification Statistics Analyzer Return Link Physical Layer Proof-of-Concept (RTN PoC) (UT to GES) RTN multi-user detection demodulator/decoder Channel Emulator Arbitrary Waveform Generator Scenarios PHY simulation tool (by WIS) SPCI s Multi-Channel Platform Channel Units SPCI s BPLT Legend: COTS product NEW development UPGRADE Objectives: validation of physical layer performances -22-

23 THAUMAS Testbed overview: protocols Overall Presentation of Simulation Scenario Run -23-

24 THAUMAS Testbed overview: protocols Software Network Simulator Return carrier router Satellite Beams Maps (Global, Regional, Narrow) Forward carrier router Will be used to validate proposed upgrades Reference BGAN network scenario will be validated using existing Inmarsat s BGAN test bench Once validated, the simulator will be extended with the new SB-S specific functionality Terminal Physical Transmitter Receiver Layer (L1) Forward link Es/N0 measur. Control Layer BoD scheduler / (L2) requester Connections handler Connection QoS mgt / various Layer (L2) connection types PDCP (L2) Adaptation Layer (L2.5) IP and above Non Access (simplified model) Stratum Layers (simplified model) L3 SB(-S) Control and User planes information Gateway (RNC) Physical Transmitter Receiver Layer (L1) Return links Es/N0 measur. Control Layer System & terminal RRM algos (L2) info. scheduler handler Connections handler Connection QoS mgt / various Layer (L2) connection types PDCP (L2) Adaptation Layer (L2.5) Map of Gateway Control Area Simulations will be focused on signalling & layer 2 aspects Physical layer aspects (i.e. demodulation performances) will be considered from a statistical point of view Terminal Generator Time Management Application traffic generator Traffic Generator Satlink Management Non Access Stratum Layers (simplified model) Core Network Network Handler Scenario Configuration IP and above (simplified model) Application traffic generator Trace Control Event Management L3 Objective: validation of system performances & capacity requirements under full load nominal/fallback conditions Traffic Session Position File File Files USBG Pre-processed Traffic files Configuration Files -24-

25 Summary Attractiveness of THAUMAS is that it is based on existing technology and use of existing, powerful spacecraft that are ideally-suited for low-cost avionics less technical risk, and is less costly Commercial risks are also reduced in that the cost of the satellites are shared with others if the final service is delayed then the satellites can probably be redeployed, thus reducing the need for example for guaranteed payments from public bodies Supply chain of Inmarsat avionics already exists There will be improved interoperability with Oceanic Service, where Swift Broadband safety service will be deployed well in advanced of the continental system THAUMAS phase 1 has been defined to formally confirm the soundness of this approach -25-

26 Questions -26-

27 Contacts Laurent Bouscary Thanks! -27-

28 Back-up -28-

29 Why THAUMAS? Application Layer Presentation Layer Session Layer Transport Layer Network Layer Data Link Layer Physical layer To be defined by SESAR 4D trajectories CONOPS and applications Top-Down system design difficult to handle ACARS and/or ATN and/or IPS Improving an existing system selected as the preferred option Satcom data link To be defined by Artes 10 «Dual link router» LDACS data link Initial 4D demonstration planned end 2011, final CONOPS still under definition Network layer selection still not defined/selected Dual link concept still under definition LDACS selection process on-going -29-