iris event ’11 thaumas

THA-PS-AST-010

10th October, 2011

Iris Event ’11 THAUMAS

Tailored and Harmonised satcom for Atm Uses, Maximising re-use of Aero Swiftbroadband

THA-PS-AST-010- 2 -

Agenda

1. Overview

2. Updates on Inmarsat progress and perspectives

3. Presentation of future activities

THA-PS-AST-010- 3 -

Overall schedule

Jul-11 Mar-13

Jan 2012 Jan 2013Jan 2011

Nov-09 Mar-10

Jan 2010

THAUMAS Ph. 0 THAUMAS Ph. 1

May-10Iris Event #1

Oct-11Iris Event #2

Summary of phase 0 outputs(presentation, part 1)

Updates on SwiftBroadband oceanic safety(presentation, part 2)

Overview of phase 1(presentation, part 3)

THA-PS-AST-010- 4 -

RCP240 compliant(Oceanic airspaces)

What is THAUMAS about ?A

ircra

ft te

rmin

alSe

rvic

esSa

telli

te

Classic Aero Safety services

LGAIGA

Inmarsat 3 MT-SAT Inmarsat 4 Alphasat

6dB

>10dBPerformances

(G/T)

Services requirements

Performances (Antenna)

Baseline for satellite

performances

More stringent than RCP240 (Continental airspaces)

SwiftBroadband Oceanic Safety

THAUMAS=SB-SAvailable by 2013

HGA

6dB

THA-PS-AST-010- 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

THA-PS-AST-010- 6 -

Agenda

1. Overview

2. Updates on Inmarsat progress and perspectives


THA-PS-AST-010- 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

THA-PS-AST-010- 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: Q1 2013

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

THA-PS-AST-010- 9 -

Avionics

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

Class 6 (High Gain) Class 7 (Intermediate Gain) SB200

THA-PS-AST-010- 10 -

SB Oceanic Safety Services - Products

SB Safety Services

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

RCP 240 Efficiency 0.9999 RCP 240 Safety 0.999

Class 6 (HGA)

SB/Classic

SB200 15-2 (small antenna)

SB Only

Class 7 (IGA)

SB Only

Class 6 (HGA)

SB Only


Agenda

1. Overview

2. Updates on Inmarsat progress and perspective



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


THAUMAS phase1: Schedule

févr.-13juil.-11

janv.-12 janv.-13

Mar-12 - Feb-13Part 2

Oct-12Early Prototype

Review

Sep-12Development

report

Jul-11 - Mar-12Part 1

Jul-11Kick-off

Mar-12Partial System

Architecture review

Feb-13Partial Design

Review/Final Review

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


Technical updates for ATM services


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 transaction- oriented communications

THA-PS-AST-010- 16 -- 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 party- line 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.

THA-PS-AST-010- 17 -- 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

THA-PS-AST-010- 18 -- 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 transaction- oriented communications

THA-PS-AST-010- 19 -- 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.


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


THAUMAS phase 1 SoW: “Validation” aspects

Validation activities will be based on:

Inmarsat hardware test bed

Astrium software simulator

Objective: justify compliance matrix


THAUMAS Testbed overview: waveform Hardware Proof-of-Concept (PoC)

FWD bearer modulator

Channel Emulator

FWD bearer demodulator

Forward Link Physical Layer Proof-of-Concept (FWD PoC)(GES to UT)

App data

PerformanceResults

Verification PHY simulation tool

(by WIS)

Arbitrary Waveform Generator

ScenariosChannel Emulator

StatisticsAnalyzer

PHY simulation tool

(by WIS)

Return Link Physical Layer Proof-of-Concept (RTN PoC)(UT to GES)

RTN multi-user detection demodulator/decoder

Legend:COTS product

NEW development

UPGRADE

SPCI’s BGAN Physical Layer Tester (BPLT) product

SPCI’s BPLTSPCI’s Multi-Channel Platform

Channel Units

PerformanceResults

Verification

Objectives: validation of physical layer performances


THAUMAS Testbed overview: protocols Overall Presentation of Simulation Scenario Run


THAUMAS Testbed overview: protocols Software Network Simulator

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

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

Objective: validation of system performances & capacity requirements under full load nominal/fallback conditions

USBG Pre-processed Traffic files

Satellite

Return carrier router

Forward carrier router

Terminal Gateway (RNC)

Core Network

Transmitter Receiver

Connections handlerQoS mgt / various connection types

PhysicalLayer (L1)

ControlLayer (L2)

ConnectionLayer (L2)

Forward linkEs/N0 measur.

BoD scheduler / requester

Non Access Stratum Layers

(simplified model)

Adaptation Layer (L2.5)

Application traffic generator

PDCP (L2)

L3IP and above(simplified model)

Transmitter Receiver

Connections handlerQoS mgt / various connection types

PhysicalLayer (L1)

ControlLayer (L2)

ConnectionLayer (L2)

Return linksEs/N0 measur.

System & terminal info. scheduler

Application traffic generator

PDCP (L2)

L3IP and above(simplified model)

RRM algoshandler

Non Access Stratum Layers

(simplified model)

Adaptation Layer (L2.5)

Traffic Generator

Time Management

Satlink Management

Terminal Generator

Network Handler

Event Management

Scenario Configuration

ConfigurationFiles

SessionFile

TrafficFile

PositionFiles

BeamsMaps

(Global,Regional,Narrow)

Map of GatewayControl

Area

Trace Control

SB(-S) Control and User planes information


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


Questions


Contacts

Laurent Bouscary

[email protected]

Thanks !

mailto:[email protected]


Back-up


Why THAUMAS ?

Application Layer

Presentation Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical layer

« Dual link router »

Satcom data link

LDACS data link

4D trajectories CONOPS and applications

ACARS and/or ATN and/or IPS

To be defined by SESAR

To be defined by Artes 10

“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

Top-Down system design difficult to handle

Improving an existing system selected as the

preferred option

iris event ’11 thaumas

Documents