The ESA Iris Programme: a new satellite communication
system for Air Traffic Management
EIWAC, Tokyo – 12 Nov. 2010
1

ESA Iris Programme: activities status
1. What is the Iris Programme?
2. Requirements and hypotheses
3. Next steps

2Satellite Communications services in SESAR
Continental airspace + oceanic
Terminal Manoeuvering Area / En-route(continental area: dual link )AirportOceanic, Remote & Polar

Login (no traffic)

Airportnetwork

Future terrestrial
network

System Wide Information Management (SWIM)
European AOC Centre

European Air Traffic Control CentreSatcom3

ESA Iris Programme
Dedicated ESA programme to support SESAR under the umbrella ofESA’s ARTES programme (ARTES 10), named “Iris”:– Commitment of ESA Member States in Sept. 2007
– Definition Phase (Phase 1) completed in Jan. 2009
– Development Phase (Phase 2) approved by ESA Member States inNov.2008, with funding committed for Phase 2.1 until 2011

Budget of Phase 2.1 is ca. EUR 40m (2009 economic conditions)

12 Participating States:
Austria, Czech Republic, France, Germany
Ireland, Italy, Norway, Portugal, Luxemburg,Spain, Switzerland, UK4

Technical interface with SESAR JU• User requirements are being defined by SESAR JU• ESA translates them into system requirements, carries out design,development and verification (i.e. under ESA funding)• SESAR will carry out the service validation end-to-end
Userrequirements

Servicevalidation

Iris Programme5Iris design activities: 2 approaches considered
Purpose-built system and open service model

ANTARES System Design Phase B study

3 Satellite System
Operations studies
HERMES, OPERA, SIRIOInteractions

SBS Com.
SystemSatellite
SystemEATMS
Preliminary
Aircraft terminal
DesignPreliminary Design
Specifications

Preliminary
DesignSpecifications

Service provision +Business case model
3 study teams
Who operates what?

ICAO
Standardisation(by SJU/EC)

DevelopAircraftterminals(with industry)

Satellite system
Phase C/D/E1
in Iris Phase 2.2

THAUMAS study...011010
1001010..

...011010
1001010..

Com.
SystemModified commercialsystem

Who procures what?
Financing scheme?...
(+) Partnership proposal ofeach team for Iris Phase 2.2+
SatelliteSystem

SwiftBroadband
Safety system
Preliminary
DesignSpecifications

Use Inmarsat Satellites
and SwiftBroadband
Safety protocols(to be standardised)6Requirements and hypotheses for the system design7Requirements and system options

Design of options to face main uncertainties on system-level
requirements from SESAR:
1-23-

45-

Security requirements with regards to the protection of thedata transmitted via the satellite system
Security with regard to the transmission of the signal i.e.
robustness to intentional and unintentional jamming
Capacity of the satellite system in terms of amount of user
data traffic on forward and return links at peak times of use
Capabilities of the aircraft terminal in terms of power
available while still operating without forced-air cooling;
Architecture of the ground segment: several service
providers with distribution of elements, or concentration
under a single entity8Service Provision requirements:
geographical area
Iris focus on SES/ECAC service area but the communication system is foreseen to
become a worldwide standard (ICAO standardisation) so that other world regions
could implement compatible systems using the very same terminals on-board aircraft

Possible extensions ofcoverage considered inIris studies:- Visible Earth from GEO
orbit- Northern latitudes areasby agreement with othercountries operating HEO
satellite systems9

Information throughput requirements:
ATS and AOC messages as in COCRv2
Aircraft fleet
Air Traffic density in 2025
(cf.Eurocontrol Long Term Forecast)Communication traffic model
Communication pattern (ATS & AOCmessages cf. COCR) of all aircraft
flying simultaneously is combined toderive the Information throughput
flight - 1
timeflight - 2
time

...
flight - itime...
flight - N
time

Total instantaneousthroughput=> Peak capacity requirements for ECAC:•4.6 Mbps on the Forward Link
•0.8 Mbps on the Return Link

time
00:00

24:00

10

Boundaries of Communication System Design11

Communication system
Forward link design status• Detailed design is on-going until end 2010; the following
elements have been selected so far:
– LDPC code with several block lengths (under definition as well asinterleaving strategy) and code rates– Linear modulations (min QPSK and 8PSK, might be more); option forvariability and adaptivity to be in the CS as option– Encapsulation GSE-like with likely use of a CRC– TDMA-based access scheme to allow several GES to access thesame frame for spectrum and satellite payload amplification– Likely no ARQ (TBC as might be needed for some QoS)

12

Communication system
Return link design status
Some decisions are still open and choices may not be based onlyon technical (performances) results:– Encapsulation RGSE-like with likely use of a CRC– Likely ARQ for most or all traffic (TBC cf random access choices)– Option for variability and adaptivity of the modulation (TBC)– Joint modulation and access optimisation is on-going with 2 choices:• MF-TDMA with advanced constant envelope modulations andeBCH code
• A-CDMA with linear modulations and turbo-code
Note: non-binary LDPC could be an attractive alternative on a pure
performance basis but there are many doubts on theirimplementation
13

Communication system
Control & Management planes design
Detailed design is on-going until end 2010, notably:• Definition of the DAMA for accommodating multiple access (on-going)• Handovers: detection and recommendations to be aircraft initiatedexcept maybe for “bulk handovers” (many aircraft from one GES toanother or one satellite to another)• Compression (OSI and IP): selection of algorithms on-going• Management plane (on-going)• Information security: use of CRC from encapsulation but unclear if
more is needed? (needs SESAR inputs cf risk analysis)• Detailed RRM design requires inputs from SESAR on CoS definitions(Inputs expected end September)

14

Requirements for user terminals design• Mobile link in L-band– Mature, reliable, proven equipment(e.g. no cause of interference)– Low cost
• Key assumptions– Use omni-directional aircraft antennas (suitable for all IFR aircraft)• Low power consumption, highly reliable, low drag– No forced air cooling required• Power likely limited to 40W– Co-primary means of communication• Software certification probably at level C– User terminal developed for airliners but also General Aviation (i.e.
business jets, rotorcraft, etc)
• Probably at least two types of user terminals
15

Critical parameters for the system design

The size of the antenna
for the return link is driven
by the user terminal peak rate
Linked to application
maximum acceptable delay
In COCRv2

The payload mass+poweris driven by the capacity
on the forward linki.e. the number of aircraft
communicating
simultaneously
16Infrastructure deployment

Subset SpaceSegment
Test flights

Deployment
2015-2020+

Subset Ground
Segment (2 GES,NMC, NCC)

System validated (2015)

Pre-operational phase

Operational System (2020)

for Certification17

Next steps

18

Standardisation process

19

Iris - Contact Points

ESA Iris Programme
Franco.Ongaro@esa.int
Nathalie.Ricard@esa.int

ESA Iris System Design Studies
Andrea.Santovincenzo@esa.int (System Engineer)
Catherine.Morlet@esa.int (Communication System)

Documentation of recent public information event is available via
www.telecom.esa.int/iris
20

Back-up: industrial teams of Iris Phase 2.1 studies

21

THAUMAS• EADS Astrium Satellites: Prime and coordinator, Critical review of therequirements, SwiftBroadband air interface validation, Validation plandevelopment, Ground segment analysis (satellite operation)• Inmarsat: Critical review of the requirements, SwiftBroadband airinterface and protocol adaptation, Validation test bed design,
Decentralised ground segment design, Interoperability with ATMnetworks• Airbus: Critical review of the requirements, AES installation
requirements, Interoperability with ATM networks• EMS: Critical review of the requirements, AES design requirements
specification• SITA: Critical review of the requirements, Interoperability with ATMnetworks• SINTEF: Air interface design, propagation modelling• DEIMOS: Critical review of the requirements, Dependability & safety
analysis22

ANTARES (1/2)
Thales Alenia Space Italia: Prime
Overall System, Space Segment, RAMS, Verification Test Bed, GS external I/F

Indra: Communication standard responsible
Waveform, Network Synchronization, Ctrl Plane, Management Plane, Data link

Thales Avionics UK: User Terminal Civil Aviation responsible
CA UT elements design, CA UT Proof of Concept, CA UT Prototype development

Honeywell: User Terminal General Aviation responsibleGA UT elements design, GA UT Proof of Concept, GA UT Prototype development

Thales Alenia Space France: Ground Segment responsible
GS Architecture, GS Design options, GS architecture for pre-op system, GS Verification,GES design, NCC design, NMCdesign
23

ANTARES (2/2)
Airtel: Support for Network layer, transportlayer, external networks
Aedel: Contribution to Space Segment
operations
Capgemini Norway: Support to RAMS
Analysis & Safety Case Definition
Evolving Systems Consulting: GUI &support to test Results, Satellite
Emulator Definition
Commsonic: support to GES modem
firmware development
Modulator/Demodulator

IZT: Satellite channel emulator
physical layer
Iguassu: Support to Satellite
channel emulator & Test Manager
detalied design and development

Next: Satellite Emulator Definitionand development
OHB: Small GEO Platform
Accommodation Report
Space Engineering: contribution
to repeater analyses, Antenna
Space Engineering S.p.A.

Farm RF/Electrical trade-off & initialdesignDLR: Channel and Traffic model, support forMultiple access scheme (OFDMA), Channel
coding and error detection (LDPC), Satellite
channel emulator

Syderal: support to GES modem
firmware development

Frequentis: Support to System Baseline Designfor ATM aspects, Support for Network layer andUpper layers (Voice), Operational scenarios, GS
operations consolidation

Thales Alenia Space España:
Contribution to Space Segment andSatellite Options Definitions,contribution to trade off

GMV: Support to GS Emulation (NMC&WANand Service tool), G/S Emulation
THLJ: Support to System Options andpreliminary design for Security, Support toSystem Design for Security Aspects.

Univ. Salzburg: Traffic analysis,
Traffic Model, End user & AES
traffic emulators
Sintef: Support for Security

24

HERMES• Inmarsat Global Limited: Prime– Satellite Operations Impact on System Design– Strategic Analysis• AENA Internacional– Regulatory– Timeline– Responsibilities and Liabilities• ARINC– Service Model– Revenue Model• Helios– Business Case
– Sensitivity Analysis

25

OPERA

SITA: PrimeOverall Management
Service definition
Regulatory constraints

Financial impact and strategic analysis

SES-ASTRA
Definition of operations
Impact of the operations on the system design
Financial impact and strategic analysis

26

SIRIO• TELESPAZIO: Prime - Satellite Service Provider
Service model, Business case, Strategic Analysis• EGIS AVIA: ATM Consultancy
Service Provision Analysis (Interoperability and standardisation),
Certification and regulatory issues, Revenue Model• HISPASAT: Satellite Operator
Engineering analyses, system verification and validation activities• NATS: ANSP consultancy
Regulatory activities, service certification and validation. Interface
to Regulators, Certification Issues.

• TELESPAZIO France: Service Model, Business case support
27