technical results of sdls activities - esa artes · iris workshop 18th september 2007 3 technical...

IRIS Workshop 18th September 2007 1

Technical results of SDLS activities

Claude Loisy, Erling Kristiansen

Iris workshop, ESTEC, September 18th 2007


Chapter 1: SDLS Historical context


Technical results of SDLSChapter 1: SDLS Historical context

Brief history and main characteristics of “AMSS”(Aeronautical Mobile Satellite Service)● System proposed by Inmarsat to ICAO for standardisation and targeting

operation in oceanic airspace (Standards And Recommended Practices (SARPs) ready in 1994)

● “AMSS” is derived from the Inmarsat Maritime communication system with main adaptations relating to vocoder, modulation schemes and message priority handling (14 levels)

● “AMSS” was conceived as an open standard designed to operate in a multiple operator environment worldwide

● “AMSS” uses “bent pipe” (transparent) type transponders on-board GEO satellites

● Service link is operated at L-Band



“AMSS” for Air Traffic Management operations● ATM service is piggy-backed on a commercial passenger telephony

service● AES (standard H) design aims at providing simultaneous operation of

several voice channels (up to seven) in FDMA mode● Linear HPA and high gain steerable antenna are required● Aero-H AESs did represent a considerable investment for air transport

(typically half a million $ range per aircraft)● No scope for installing satcom for ATM alone ● High tariffs (typically ~ 12 $ / minute for voice)● Motivation by airlines for installing satcoms was primarily based on the

impact upon the airline commercial “image” in the competitive air transport environment



“AMSS” performance in ATM functions● Voice service is PSTN commercial telephony

○ Quality of service not in line with Aviation requirements○ Difficult to integrate in the existing operational environment

● Data service does not provide guaranteed response time○ Unsuitable for reliable position reporting excl.oceanic airspace○ Unsuitable for high density airspace

● Sensitive to space segment failures○ No hot redundancy○ No guaranteed time for service restoration



SDLS approach for deploying Satellite Service for ATMTailored design to aviation requirementsAddress all types of aircraft or at least a vast majority of themBe capable of offering ATM service compatible with high density airspaceDedicated protocols for optimised transmission delaysHave a scope for mandating carriage in the futureAdapt the AES design to the strict data link capacityrequirements of the ATM function:● some 3 to 4 Kb/s peak per aircraft● From a few tens to a few hundreds b/s average per aircraft



SDLS approach for deploying Satellite Service for ATM (cont.)Provide voice service capability● Voice service requirements other than existing VHF (DSB PTT) are not

defined by aviation● Voice service will still be required as a complement operating data link

for non routine procedures● Satcom should provide voice service where VHF is not deployed (in

particular oceanic and remote areas)Achieve AES costs including installation consistent with those of terrestrially based communication system avionicsSecuring undisputed access to L-Band radio spectrum● ITU grants priority access to aeronautical safety of life communications

only in frequency bands 1545 to 1555 MHz and 1646.5 to 1656.5 MHz● Systems dedicated to safety communications should therefore enjoy the

benefit of the priority clause without major difficulty



SDLS major overall design features

Link dimensioning● Avionics (AES)

○ Isotropically radiating aircraft antenna (no steering requirement)○ LNA co-located with antenna (minimise cable losses for maximum

G/T)○ High efficiency HPA not requiring forced air cooling and installed

close to antenna (minimise cable losses)• Saturated HPA • Single carrier operation• RF power not exceeding some 40W




Link dimensioning● Space segment

○ Wide beams (global if possible) to economically cover low traffic density areas

• In line with low capacity requirement and low cost space segment○ Narrower beams (not overlapping) for the higher traffic density areas

• Allows through frequency re-use to match overall capacity requirement with available radio spectrum




Sharing space segment resources● Multiple GES access (de-centralised architecture)

○ Service availability requirements will impose provision of redundantaccesses to satellite

○ In regions with scarce terrestrial communication infrastructure multiple accesses typically one access point per major ATCC may be desirable

○ In regions with highly developed infrastructure service availabilityrequirements combined with political constraints may also lead to prefer a de-centralised architecture

○ De-centralised architecture can default to single access




Agility of resource management● GES access

○ De-centralised management of channel resources• Faster response (saves the NCS channel management function)• Higher robustness to equipment failures

● AES access○ SDLS maintains a continuous virtual connection between logged-in

AESs and the GES which allows “near instantaneous” access to the resource

○ Synchronisation data packets for the QS-CDMA are also used for signaling

○ Performance requirement for voice service (time to establish a voice channel) can be made comparable with existing voice service at VHF


Chapter 2: Radio link Design

Major option selection to lead to both a performance level and economical

satellite communication system


Technical results of SDLSChapter 2: Radio Link Design

SDLS overall design features

Satellite orbits● Geostationary orbits are preferred

○ Most economical constellation for worldwide coverage• Investment• Operations

○ Allows deployment on a regional basis○ Geostationary loop delay is compatible with service requirements

including radio-telephony (voice) serviceTransponders● Bent pipe (transparent transponders) are preferred

○ Proven and widely deployed technique (simplicity and robustness)○ Potential benefit of regenerative transponders not significant due to

• low traffic volume• Limited interest of beam to beam switching




Two-way communication● MSS (Mobile Satellite Service) allocates separate frequency bands for

Forward and Return Links● Full-duplex is selected rather than Semi-duplex

○ Although semi-duplex potentially saves on AES costs (diplexer)○ Protocols in Full-duplex have higher performance (no receiver

blanking)AES Transmit mode● Single carrier is selected with time multiplex of channels (i.e. voice and

data)○ Allows to operate the HPA in saturated mode (power efficiency)○ Allows also to prevent spurious emissions in other bands (ref: “AMSS” interfering into adjacent bands e.g.Iridium)




AES Receive mode● Several channels (carriers) can be received simultaneously

○ Allows easy combinations of• Simultaneous voice and data transmission• Broadcast and point to point transmission

○ Allows an easy implementation of satellite diversity• Reception from two satellites (on different frequencies)• Transmission only through the better received satellite (single carrier

requirement)




Multiple access from AESs● Combination of QS-CDMA and TDMA

○ QS-CDMA is preferred to FDMA due to• Its ability to separate out in the receiver overlapping transmissions in the

same channel (code)• The resulting high performance in random access (absence of collisions)

○ QS-CDMA synchronisation remotely controlled by GES• Relatively infrequent frequency and timing corrections when “En route”

due to flight geometry (range linearly varying with time, Doppler rate is nil)

○ QS-CDMA carrier power leveling remotely controlled by GES• Very slow varying evolution (variations due to antenna pattern

modulation and HPA temperature only)• No significant Near/Far effect (in contrast with terrestrial systems)




Multiple access from GESs● Combination of S-CDMA and TDMA

○ S-CDMA is preferred to FDMA due to• Harmonised frequency planning with the Return Link• Simpler RF equipment design (one frequency)

○ S-CDMA synchronisation directly controlled by GES• Based on pilot signals generated by the NMS

○ S-CDMA carrier power leveling directly controlled by GES• Slow varying evolution (modulation only by variation of atmospheric

losses in the feeder link (Ku-Band))




Multiple access from GESs● One (or two for redundancy) GESs have a Network Master Station

(NMS) function● Channel allocation among GESs can be managed in a distributed fashion

(GESs can share allocation requests and apply a common priority algorithm)○ No need for a NCS (Network Control Station of “AMSS”) to manage

the pool of channels○ Faster and more reliable channel allocation process




Feeder Links between GESs and satellites● Frequency bands allocated to the FSS must be used

○ C-Band (e.g. Inmarsat)○ Ku-Band

● Ku-band allows low cost GES antenna implementation (VSAT type)● Ku-band has however limitations w.r.t. service availability under heavy

rain● GES redundancy including site diversity will to be required in the case of

Ku-band




Link level specific issues (data service)

● Channel coding○ FEC is used for error detection and ARQ

● CDMA codes○ A family of spreading sequences with optimum orthogonality

properties when synchronised has been selected ● Carrier Modulation

○ QPSK for message core transmission at ~ 6 Kb/s○ BPSK for preamble transmission at ~ 3 Kb/s

• Preamble is used for signal acquisition in asynchronous environment with 3 dB power advantage




Link level specific issues (voice service)

● Vocoder○ Vocoders at 4800 b/s (ICAO standardised) are used○ Vocoders at 2400 b/s or possibly lower rate may be feasible

● Bit error rate○ BER of 10-2 is sufficient for voice quality ○ Checksum to reject packets is sufficient (vodecoder interpolates)



Conclusions and Caveats

User data rates in the order of 5 Kb/s peak appear adequate● Confirmed a posteriori by requirement document (COCR)

Multiplexing with low usage rate voice service● Does not impact significantly on the throughput requirement● Remains compatible with the single carrier requirement

Limited power AES HPA (max 40 W) appears to be compatible with:● Identified service requirements (assuming 1.2 Kb/s data rate in oceanic)● Isotropic AES antenna● Achievable G/T in satellite Global Beam (oceanic airspace)



Link margins are however smallin a global beam therefore● Any unexpected inefficiency

(either from RF link or protocoldesign) may dramatically impact the overall cost in forcing:○ The need for narrower beams

than global for the coverage of oceanic airspace or

○ The need for directive antenna for AESs in oceanic airspace


Global Beam 1.2 Kb/sGlobal Beam 1.2 Kb/s



Regional beams deployed for continental airspace● Provide adequate margin for

8 Kb/s user data rate


Regional Beam 8 Kb/sRegional Beam 8 Kb/s



Regional beams deployed for continental airspace● Provide high latitude coverage

capability


Uncovered area limited by aircraft Uncovered area limited by aircraft optical horizonoptical horizon



Sub-regional beams● Will allow further expansion of

user data rate to 64 Kb/s and or● Overall capacity increase (number

of served aircraft) within the same occupied RF spectrum (frequency re-use)


SubSub--regional Beamsregional Beams64 Kb/s64 Kb/s


Chapter 3: Network issues


Technical results of SDLSChapter 3.1: SDLS services

Basic data link services● Basic assumption: Network is “native” end-to-end ATN● SDLS is an ATN air/ground subnetwork● Fully compliant with ATN SARPs● It is assumed that both ATS and AOC will use ATN

Additional SDLS-specific data link service● SDLS APR (Automatic Position reporting) (Not to be confused with

various other aviation-related APR acronyms)



SDLS voice services● ATN SARPs does not cover voice● No generally used standard exists that we know of● The SDLS voice services are modelled on aviation VHF voice service

○ Connection oriented point-to-point voice○ push-to-talk voice○ Party line voice



ATN reference model



When SDLS started, ATN was seen as the technology of choice by aviationThere is now a shift of emphasis towards IP-based solutionsAn intermediate step seems to be emerging: ATN over IP● One likely scenario is to tunnel ATN CLNP packets through IP

Any long-term technology today may need to be capable of supporting both ATN and TCP/IP, and possibly some intermediate technologies● A particular problem is how to support a network path that contains more

than one of these technologies○ E.g. aircraft is ATN-equipped, the ground network is TCP/IP

● Conceptually, not the problem of the satellite network, but if it can offer something, this may be welcomed.


Technical results of SDLSChapter 3.2: SDLS ATN

SDLS ATN and its environmentWe should distinguish between ● The SDLS system proper● Its environment, as implemented in the demonstrator

For the purpose of this presentation, we define the interface points to be the ATN network interface between ● On ground: The Air/Ground router and the GES ● On the aircraft: The Air/Ground router and the AES

The following slides will discuss the SDLS proper. The SDLS demonstrator will be addressed in chapter 6


Technical results of SDLSChapter 3.2: SDLS ATN

The yellow part is SDLS. Everything else is environment


Technical results of SDLSChapter 3.3: System sizing

System capacity and sizing were studied in SDLS slice 3● Reference: SDLS-ASP-TN-0017

Key issues:● Modularity● Phased deployment capability● Which traffic to size for?

○ Primary means of communication?○ Supplementary means of communication?○ In which geographic regions?


Chapter 4: SDLS Services and protocols


Technical results of SDLSChapter 4.1: SDLS Services

Original SDLS data link servicesATN-compliant CLNP packet forwardingAPR (Automatic Position Reporting)

Later additionsGround handover (strictly speaking, not an SDLS service)Application layer gateway

Voice servicesPoint-to-point voice serviceParty line push-to-talk voice service(Point-to-point push-to-talk not explicitly addressed; similar to party line protocol)


Technical results of SDLSChapter 4.2: SDLS bearer services

SDLS inherited most of its bearer services from MSBN(“Mobile Satellite Business Network” was an earlier ESA development for Land Mobile Satellite communications)

SDLS incorporates the following bearer services:● Bi-directional circuit mode point-to-point reliable data service● Bi-directional packet mode point-to-point data service● Unidirectional (AES → GES) packet mode point-to-multipoint data

service (for APR, will be discussed a few slides further on)● Bi-directional circuit mode point-to-point voice service● Party line voice service



GES → AES broadcast/multicast bearer services were not included because their use was not foreseen within the ATN environment● MSBN did support both data and voice broadcast● Broadcast/multicast is an easy addition, if deemed useful



The point to point services definitions are rather straightforward● The main design challenge is to utilize satellite resources efficiently with

the rather unusual traffic profile of ATM.

Two services are somewhat unusual, and will be described later:● Point-to-multipoint service for APR● Party line voice



The ATM data traffic profile is unusual and requires special attention● Mostly short messages (<100 bytes)● Occasional (much) longer messages (>1000 bytes)● Few messages of intermediate size

○ Suggests considering separate bearer services for short and longmessages

● Inter-message interval is large (seconds to minutes)● Many aircraft sharing a narrow channel, each generating very thin traffic



Forward data link sharing● One or more forward CDMA channels are provisioned, depending on

overall capacity needs● Several GESs may share a forward CDMA channel in TDMA

○ Semi-static TDMA ● Traffic to multiple aircraft is TDM multiplexed within the TDMA time

slots of the GES



Efficient Return data link sharing is a real challenge● Needs to be agile (no long wait between wanting a channel, and getting

it)● Should not occupy resources, even briefly, when there is no data to send● Needs to resolve contention efficiently, without wasting resources● Must not be susceptible to congestion collapse

ATN (and IP) headers are comparable to the body size of most short messages



Voice services, in particular for ATS, must be agile● No complicated call setup and release● Considering voice services in relation to their operational environment is

essential


Technical results of SDLSChapter 4.3: SDLS APR service

APR: The problem● Regular reporting by aircraft of e.g. position can be optimized if

transmissions are scheduled by a central entity to be collision/overlap free● Contention random access on the return channel leads to sub-optimal

resource usage2 solutions possible1. The GES polls aircraft for each report

– Very simple and agile. Ground has full, instantaneous control. But loads forward link with polls.

2. A schedule is compiled by the GES and broadcast to all aircraft. The schedule remains in force until updated.– More complex to manage, but more efficient in forward link usage, in

particular if schedules do not change often



SDLS APR implements option 2 (broadcasting transmission schedule)APR does not match completely any ATN serviceThe concept is similar to ADS-C contract reporting● But in ADS-C it is the aircraft that takes the initiative to send reports, at

the time instant decided by the ATS-C application● Since the ATS-C applications of different aircraft are not synchronized,

contention access is implied



The problem of integrating APR with ATN was studied by National Avionics (now AIRTEL)● Reference: Contract 11967/96/NL/US

The study also looked at proxying a native ATN ADS-C service.● Was rejected due to synchronization problems between the ADS service

and the APR service.



APR enables highly efficient utilization of return link● As opposed to contention based random access

Integration of APR into the ATN environment is not trivial● Does not fit the ADS-C model well

With APR, it is the network that drives the timing of reportingAPR is similar in concept to radar Mode-S


Technical results of SDLSChapter 4.4: SDLS Party line voice service

Principles:● One controller, one voice channel● Return link voice is re-broadcast in forward link● The controller “owns” the channel

○ Controller voice takes priority for forward link○ If contention for return link: two options supported:

• controller decides priorities • automatic first-come-first-served• Priority for urgent access

● Normally no overlap between forward and return link voice due to voice dialogue procedures


Technical results of SDLSChapter 4.4: SDLS Party line voice service

Conclusions for voice services● ATS and AOC voice have very different requirements● ATS voice service consists mainly of dialogues of very short

commands/requests/responses○ The service must be highly agile○ The service must be easy to use, not distract the user○ Future trends??

● Little is known about AOC voice○ It is thought to be more like a telephony service, involving more

elaborate conversations, longer sessions.


Technical results of SDLSChapter 4.5: Transport layer issues

The ATN protocol model assumes all data traffic is carried over the reliable end-to-end transport protocol TP4ATM traffic is inelastic● Traffic is generated by events● (Time-triggered messages are also considered “events”)

ATN TP4 reliable transport was designed for elastic traffic (by the way, so was TCP)● Rate of transmission is driven by the transport protocol● Source is capable of slowing down if the transport tells it to● Reliable transport insists on delivering all data, and delivering it in

sequence.



There is a fundamental incompatibility between inelastic sources and elastic transport● As long as traffic volume is well below network capacity, and no

significant volume of retransmission takes place, all is well● But if even mild congestion is encountered, all traffic is delayed.● Significant congestion, even for a short time, may cause very large delays

to all traffic. Timeouts may expire, causing unnecessary retransmissions, thus increasing congestion further.



Congestion control● ATM traffic to/from any given aircraft is very “thin”

○ Infrequent, mostly short messages● TP4 (and TCP) congestion control was designed for regulating the flow

of a continuous stream of traffic● It does not work with thin, bursty, inelastic traffic

○ Knowing that there was/wasn’t congestion one minute ago says nothing about now.

○ And, anyway, what can the sender do about congestion with inelastic traffic?



ATN SARPs does away with congestion in one sentence:

“It is assumed that sufficient bandwidth is made available”



In summary: 2 problems:

1. Congestion control is ineffective for the traffic pattern2. Inelastic traffic over an elastic transport protocol

– Two approaches to mitigate this situation were investigated:

– Transport relay (“PEP”)– Application layer gateway (“AGW”)


Technical results of SDLSChapter 4.6: Transport relay (PEP)

The PEP is a transport layer proxy● The PEP intercepts the TP4 connection● Transports the data to the peer PEP at the other end of the satellite link

○ May use a PEP-PEP TP4 (easy)○ May also use another protocol that is better optimized for the

environment (more performant)● The peer PEP opens a TP4 connection to the destination● The peer PEP sends the data to the destination

Solves problem 1: the inadequacy of TP4 congestion control in the short, infrequent message environmentDoes not solve problem 2: The incompatibility between inelastic traffic and elastic transport.


Technical results of SDLSChapter 4.7: Application gateway (AGW)

Rationale for AGWIn the absence of an extremely high over-provisioning of bandwidth, one has to assume that Congestion will happenAnd it will happen when it is least wanted: In an unusual operational situation such as massive flight re-routing due to weather or an incidentthe incidence rate can be reduced by providing more bandwidth, but cannot be reduced to zero.The only thing one can do when congestion happens is to discard messages. Randomly or intelligently.With e2e reliable transport, there is no way the network can discard traffic. Only the sending application can.The AGW can re-order and discard traffic selectively



The AGW is an application layer message proxy● The AGW has a complete protocol stack, including an application layer

entity● The AGW intercepts the TP4 connection and the higher layer protocols● Decodes the message ● Applies a set of rules to its queue of messages ● Transports the message to the peer AGW at the other end of the satellite

link○ May use an ATN stack (easy)○ May also use another message transfer protocol that is better

optimized for the environment (more performant)● The peer AGW opens a connection (all 7 layers) to the destination (if one

does not already exist)● The peer AWG sends the message to the destination



AGW functionality● The AGW builds a queue of messages to be sent over the satellite link● The AGW attempts to build a schedule for transmission that meets the

QoS requirements for all messages● If such a schedule cannot be built, congestion is present● In case of congestion, the AGW will discard messages according to set

rules



AGW rules may consider such elements as:● Priority● Time-to-live● Context

AGW rules might include such features as● Try to deliver all within time-to-live (deadline scheduling), even if it

means low priority before high● High priority before low if both meet deadline● If a message supersedes another one (e.g. new position vs. old position),

new goes before old● If the first message in a dialogue was successful, subsequent messages

have higher value (otherwise, the dialogue will be re-started from the beginning by the user or application)

● Etc. etc. etc.



Solves both problem 1 and 2Drawbacks:● AGW needs to know message formats

○ Must be updated if new messages are introduced● For some rules, AGW needs to know message context● Incompatible with end-to-end encryption

○ The AGW must be the end point of security associations○ i.e. it must be a trusted entity

Extra benefits● May serve as interface between heterogeneous technologies

○ E.g. ATN in the aircraft, TCP/IP on the ground○ Eurocontrol study on IP for ATM by HELIOS suggested similar gateway for

this purpose● “Future proof” for future network technologies● Effectively decouples ground, satellite link, on-board network● The AGW could also serve as APR controller



Comparison with UDP approach (and ATN CLTP)● (This was not studied in SDLS, but is included to complete the picture)

UDP allows dropping packets in case of congestionBut packets are dropped randomly (possibly taking into account priority)● No intelligence concerning message context or time-to-live● For multi-packet messages, may drop parts of a message, rendering the

remainder useless, but consuming bandwidthVery simple, off-the-shelf solution.Is not susceptible to problem 1Solves problem 2, but in a more crude way than AGW


Chapter 5: History of Aeronautical activities

Summary of the study contracts


Technical results of SDLSHistory of Aeronautical activities

Study of Aeronautical Data Link System (1994-1995)Feasibility study of a ATS dedicated communication system● Requirements and cost benefit analysis● Communication system design analysis● Specifications of a demonstration system

Budget : 200KAUContractual action: Competitive tender : AO/1-2902/94/NL/US

Contract: 11225/94/NL/US

Contractor: Alcatel Espace S.A. (F)Aerospatiale S.A. (F) Racal Research Ltd (UK)Europe Aero-Conseil S.A. (F) Sainco (E)Sofreavia S.A. (F)

Comment: A system architecture had been suggested as a baseline, extrapolated from

earlier ESA work on communication system for Land Mobiles (MSBN)



Aeronautical Satellite Data Link System For Air Traffic Management (Phase 1) 1997-1999

Slice 1: Study work● Validity of concept● Achievable performance levels● Trade-off studies● System design

Slice2: Service Demonstrator (not financed under the contract)Budget : 1.1 M€Contractual action: Competitive tender: AO/ 1-3222/ 97/ NL/ USContract: 12472/97/NL/USContractor: Alenia Spatio (I) ENAV (I)

RTSN / Skysoft (P) Alenia Marconi Systems (I)Space Engineering (I) Alenia Marconi Systems (I)NAL / Airtel (Irl) Alcatel Bell (B)

Comment: ESA was assisted by an Aviation Expert Group (CAAs and Eurocontrol) to define the service requirements and monitor the results of the work



High Performance Mobile System (1997-1999)Potential Applicability to SDLS

Study work● Service requirement review● System requirements● Trade-off studies CDMA vs. FDMA● Spectrum requirements

Budget : 460 K€Contractual action: AO/ 1-3222/ 97/ NL/ USContract: 13019/98/NL/USContractor: Alcatel Espace (F)Comments: In depth technical study taking advantage of the consolidated service requirements of the SDLS Slice 1 work and also of the Comaerosatstudy sponsored by CNES



Aeronautical Satellite Data Link SystemFor Air Traffic Management (2000-2002)

Slice2: Service DemonstratorBudget : 3.6 M€Contractual action: AO/1-3596/99/NL/USContract: 14202/00/NL/US

Contractor: Alcatel Space Industries (F)Airtel (Irl) Skysoft (P)Alcatel Bell (B) Vitrociset (I) Indra Espacio / Sema (E)

Comments:Corresponds with Slice 2 of the original call for tender: AO/ 1-3222/ 97/ NL/ US with some de-scoping of the initial target i.e.aircraft terminals on ground, due to

limitation of resources



SDLS Operational System Preliminary Definition (2003-2004)

Slice3: Upgrade the SDLS definition and specifications to the level required for an operational system in view of comparison with other candidate satellite systemsBudget : 4,5 M€Contractual action: Direct negotiationContract: 17004/02/NL/USContractor: Alcatel Space Industries (F)

Sofreavia (F) Skysoft (P)Airtel (Irl) Vitrociset (I)Indra Espacio / Schlumberger Sema (E)

Comments: Following the creation by Eurocontrol of the “Nexsat”workinggroup in order to study the suitability of various satellite systems for ATM, it was considered necessary to promote the SDLS concept in this context



Air Traffic Management Systems for 2020 and beyond The expected role of satellites (VISTA) (2003-2005)Study:● ATM methodology and systems● Potential contributions of space technology to ATM/CNS systems● Vision of a global ATM system for the period 2020 and beyond

Budget : 250 K€Contractual action: competitive tender:AO/1-4380/03/NL/USContract: 17610/03/NL/USContractor: EADS ASTRIUM (D) / THALES ATM (D)

Comments: This study did help priming the consideration of satellite systems in the “ATM Alliance” which has become a key player of SESAR


Chapter 6: SDLS Demonstrator


Technical results of SDLSChapter 6.1: Demonstrator goals

On-ground realistic demonstration of the viability of the SDLS conceptsDemonstrating over a real satellite link adds credibilityDemonstrates the following services:● ATN compliant data link

○ ATS applications○ AOC applications

● APR service as an SDLS specific service● Point-to-point voice● Party line voice

Later additions:● Ground handover● Application layer gateway


Technical results of SDLSChapter 6.2: Demonstrator limitations

2 GESs (Later 3)2 AESs (on ground)For economical reasons, the satellite link design has a heritage from MSBN● Constrains the range of some parameters● Constrains the bearer services available

Even with these constrains, given the small number of AESs, the demonstrator is quite representative of a real-life systemSome shortcuts were taken in the design, but services and performances largely remain representativeThe SDLS demonstrator will not directly scale to a full system, but the underlying concepts will.


Technical results of SDLSChapter 6.2: Demonstrator limitations

Main limitations:● Return link multiple access was not fully developed, and permanent

connections were used for some purposes that would normally use dynamic allocations

● APR was not fully integrated into the ATN environment● Only the reporting capability of APR was developed, not the control part● MMIs are computer screens, not realistic ATCC and cockpit MMIs

(though quite a good emulation of most were done, e.g. an MCDU on a screen; “radar” display of aircraft positions).

● Voice MMI was a mix of headset and screen controls


Technical results of SDLS

GES

AES

Satellite

Internal services

End to end applications

Aeronautical communication system

AOCApplication

ATSApplication

SDLS APRapplicarions

Voice applications

ATSApplication

SDLS APRapplication

Voice applications

AOCApplication

Chapter 6.3: Demonstrator overview

ATSApplication

ATSApplication

AOCApplication

AOCApplication


Chapter 7: Application gateway and ground handover extension


Technical results of SDLSChapter 7.1: Extension overview

After completion of the main SDLS activities, an extension was undertaken. Objectives:● Installation of a third GES at a different location● Development of the Application Layer Gateway (AGW) demonstrator● Development of the OLDI ground handover protocol as an application of

the APR service● Setting up a realistic demonstration environment, including the above

items plus realistic controller work station and a “pseudo pilot”application


Technical results of SDLSChapter 7.2: AGW demonstrator

Objectives● Demonstrate the viability of the AGW concept in a realistic environment● Measure achievable performances● Demonstrate operational benefits of the AGW

Main components● Two AGWs (ground and air)● Satellite link emulator● APR application● Pseudo-pilot application● ATCC controller position● ATS and AOC applications● Traffic generator● Analysis tools


Technical results of SDLSChapter 7.3: AGW results

Comparison was made between end-to-end TCP and TCP with the use of AWG3 cases were tested:● No congestion

○ With e2e TCP, messages delivered in sequence○ With AGW, high priority goes before low priority

● Light congestion○ With e2e TCP, messages delivered in sequence, but some exceed

their time-to-live○ With AGW, messages are re-ordered to meet time-to-live, a few low-

priority messages are discarded● Heavy, persistent congestion (not really an operational situation)

○ With e2e TCP, all messages delivered, but delay gets longer and longer as test progresses

○ With AGW, all high priority messages delivered, many low priority discarded. All messages that make it are within time-to-live


Technical results of SDLSChapter 7.4: Ground handover

Demonstration of handover of control from one ATCC to anotherSatellite link over ArtemisMakes use of the APR service to track flights and initiate handover when passing from one sector to the nextNot really an SDLS core function; rather, an application of APRHandover between GESs in Toulouse and RomeUses the OLDI protocol (Eurocontrol standard)Includes:● APR from aircraft to both ATCCs (broadcast)● CPDLC● Voice capability● OLDI over ISDN between Toulouse and Rome


Technical results of SDLSChapter 7.5: Ground handover results

The assumption for the demo is that the two ATCCs use different GESs.● Scenario is also valid if they use the same GES, just simpler

Shows the usefulness of APR as a broadcast (ADS-B like) service● Current and next GES/ATCC both receive the position data● No extra capacity needed to do this

The OLDI protocol implements a two-stage handover:● A pre-warning some minutes before the actual handover● The operational handover

Having APR data before handover is equivalent to having incoming aircraft on the radar display before they enter the sector


Technical results of SDLSChapter 7.3: AGW results

A workshop is planned for

27 September 2007 at Vitrociset, Rome

to demonstrate the AGW and GHO and discuss their merits

Please register by 21st September [email protected]

+31 71 565 3781


Chapter 8: Overall Conclusions

Lessons learnt from SDLSFor consideration in the future

system design


Technical results of SDLSChapter 8: Overall Conclusions

Feasibility of RF link dimensioning based upon isotropicallyradiating aircraft antenna and 40W max saturated HPAconfirmed● Provides 1.2 Kb/s and voice service in a global beam (oceanic airspace)● Complies with COCR requirements in a regional beam (continental

airspace)● Can offer even higher capacity in sub-regional beams (for the future)

Feasibility of multiple GES access to a common regional satellite resource confirmed● Easy implementation of decentralised network configurations ● Simple implementation of GES redundancies with site diversity● Capability for straight-forward satellite diversity deployment



Satcom avionics could now compare with avionics of terrestrial systems (volume, mass and costs)● They can provide same service (also QOS) as terrestrial in high density

continental airspace● They also provide service in oceanic airspace and remote areas with the

same equipment



The SDLS project extended over a rather long time period, including various extensions of the original scope. SDLS was built with a heritage:● MSBN ● Earlier studies by e.g. National Avionics (IRL)

● Experience from PRODAT (ESA actually did ATM over satellite 20years ago)

For practical and economical reasons, bearer services were taken over almost unchanged from MSBN● This was fully appropriate for a limited-scale demonstrator● But not really optimized for scalability



Multiple access on the Return link● Taking into account the specific traffic pattern of ATM

○ Mostly short messages○ Some long messages○ Relatively long inter-message time○ Highly agile voice service

● Optimizing for efficient link usage● Optimizing for fast response and low overall latency● This is really a key issue for success● It is also one of the most difficult and challenging issues to be dealt with● This should likely be a main design driver for the overall future design



End-to-end ATN (and TCP) does not handle congestion appropriately● Is this the problem of the communication system?

○ At which protocol layer does IRIS interface to data link services network?

• Network layer• Application layer

● An AGW could provide a solution. ● CLTP or UDP also provide a solution, but a less performant one● Transport layer PEP is not a solution



Protocol overhead● Most traffic is short messages● ATN and IP headers are about as large as the message text

○ An ATN address is 20 bytes● VoIP also has large overhead● ATN stack has ACKs at several layers

● Therefore, solutions that reduce this overhead are to be preferred



Voice protocols● SDLS uses proprietary voice protocols with low overhead and high

agility● For a future system, VoIP looks attractive at a first glance

○ Protocols and standards exist○ COTS equipment is available○ Integrates easily into an IP network



Voice protocols● But

○ VoIP protocol overhead is about 100% (~300% for IPsec)○ Bit errors cause loss of the whole packet

• Voice codecs are quite tolerant to bit errors, much less so to packet loss• Aeronautical vocoders perform acceptably at BER around 10-2

○ VoIP signalling for agile services like push-to-talk and party line is far from trivial and will likely require non-standard additions to protocols

○ IPsec VoIP security is not optimized for the application● Considering the operational environment, is VoIP really an option?



Voice protocols● A hybrid solution could be considered:

○ VoIP on terrestrial tail○ VoIP (or not) on aircraft internal network○ Proprietary, optimized voice protocol over the satellite link

• Voice proxy gateways at GES and AES○ This kind of setup is quite common in telephony today



Quality of Service management● Internet-style QoS management was not considered in SDLS

○ Technology was in its infancy at the time○ Was not felt to be applicable○ No equivalent concept in ATN

● Why is Internet-style QoS not a good match for ATM?○ Highly bursty, thin traffic does not fit traffic assumptions of QoS

management○ CAC is not acceptable

• “I want to declare an emergency”• “Sorry, line is busy”



All these issues are highly inter-related, and cannot be dealt with in isolation

technical results of sdls activities - esa artes · iris workshop 18th september 2007 3 technical...

Documents