View
6
Download
0
Category
Preview:
Citation preview
IRIS Workshop 18th September 2007 1
Technical results of SDLS activities
Claude Loisy, Erling Kristiansen
Iris workshop, ESTEC, September 18th 2007
IRIS Workshop 18th September 2007 2
Chapter 1: SDLS Historical context
IRIS Workshop 18th September 2007 3
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
IRIS Workshop 18th September 2007 4
Technical results of SDLSChapter 1: SDLS Historical context
“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
IRIS Workshop 18th September 2007 5
Technical results of SDLSChapter 1: SDLS Historical context
“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
IRIS Workshop 18th September 2007 6
Technical results of SDLSChapter 1: SDLS Historical context
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
IRIS Workshop 18th September 2007 7
Technical results of SDLSChapter 1: SDLS Historical context
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
IRIS Workshop 18th September 2007 8
Technical results of SDLSChapter 1: SDLS Historical context
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
IRIS Workshop 18th September 2007 9
Technical results of SDLSChapter 1: SDLS Historical context
SDLS major overall design features
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
IRIS Workshop 18th September 2007 10
Technical results of SDLSChapter 1: SDLS Historical context
SDLS major overall design features
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
IRIS Workshop 18th September 2007 11
Technical results of SDLSChapter 1: SDLS Historical context
SDLS major overall design features
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
IRIS Workshop 18th September 2007 12
Chapter 2: Radio link Design
Major option selection to lead to both a performance level and economical
satellite communication system
IRIS Workshop 18th September 2007 13
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
IRIS Workshop 18th September 2007 14
Technical results of SDLSChapter 2: Radio Link Design
IRIS Workshop 18th September 2007 15
Technical results of SDLSChapter 2: Radio Link Design
SDLS overall design features
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)
IRIS Workshop 18th September 2007 16
Technical results of SDLSChapter 2: Radio Link Design
SDLS overall design features
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)
IRIS Workshop 18th September 2007 17
Technical results of SDLSChapter 2: Radio Link Design
SDLS overall design features
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)
IRIS Workshop 18th September 2007 18
Technical results of SDLSChapter 2: Radio Link Design
SDLS overall design features
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))
IRIS Workshop 18th September 2007 19
Technical results of SDLSChapter 2: Radio Link Design
SDLS overall design features
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
IRIS Workshop 18th September 2007 20
Technical results of SDLSChapter 2: Radio Link Design
SDLS overall design features
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
IRIS Workshop 18th September 2007 21
Technical results of SDLSChapter 2: Radio Link Design
SDLS overall design features
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
IRIS Workshop 18th September 2007 22
Technical results of SDLSChapter 2: Radio Link Design
SDLS overall design features
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)
IRIS Workshop 18th September 2007 23
Technical results of SDLSChapter 2: Radio Link Design
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)
IRIS Workshop 18th September 2007 24
Technical results of SDLSChapter 2: Radio Link Design
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
Conclusions and Caveats
Global Beam 1.2 Kb/sGlobal Beam 1.2 Kb/s
IRIS Workshop 18th September 2007 25
Technical results of SDLSChapter 2: Radio Link Design
Regional beams deployed for continental airspace● Provide adequate margin for
8 Kb/s user data rate
Conclusions and Caveats
Regional Beam 8 Kb/sRegional Beam 8 Kb/s
IRIS Workshop 18th September 2007 26
Technical results of SDLSChapter 2: Radio Link Design
Regional beams deployed for continental airspace● Provide high latitude coverage
capability
Conclusions and Caveats
Uncovered area limited by aircraft Uncovered area limited by aircraft optical horizonoptical horizon
IRIS Workshop 18th September 2007 27
Technical results of SDLSChapter 2: Radio Link Design
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)
Conclusions and Caveats
SubSub--regional Beamsregional Beams64 Kb/s64 Kb/s
IRIS Workshop 18th September 2007 28
Chapter 3: Network issues
IRIS Workshop 18th September 2007 29
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)
IRIS Workshop 18th September 2007 30
Technical results of SDLSChapter 3.1: SDLS services
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
IRIS Workshop 18th September 2007 31
Technical results of SDLSChapter 3.1: SDLS services
ATN reference model
IRIS Workshop 18th September 2007 32
Technical results of SDLSChapter 3.1: SDLS services
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.
IRIS Workshop 18th September 2007 33
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
IRIS Workshop 18th September 2007 34
Technical results of SDLSChapter 3.2: SDLS ATN
The yellow part is SDLS. Everything else is environment
IRIS Workshop 18th September 2007 35
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?
IRIS Workshop 18th September 2007 36
Chapter 4: SDLS Services and protocols
IRIS Workshop 18th September 2007 37
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)
IRIS Workshop 18th September 2007 38
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
IRIS Workshop 18th September 2007 39
Technical results of SDLSChapter 4.2: SDLS bearer services
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
IRIS Workshop 18th September 2007 40
Technical results of SDLSChapter 4.2: SDLS bearer services
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
IRIS Workshop 18th September 2007 41
Technical results of SDLSChapter 4.2: SDLS bearer services
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
IRIS Workshop 18th September 2007 42
Technical results of SDLSChapter 4.2: SDLS bearer services
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
IRIS Workshop 18th September 2007 43
Technical results of SDLSChapter 4.2: SDLS bearer services
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
IRIS Workshop 18th September 2007 44
Technical results of SDLSChapter 4.2: SDLS bearer services
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
IRIS Workshop 18th September 2007 45
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
IRIS Workshop 18th September 2007 46
Technical results of SDLSChapter 4.3: SDLS APR service
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
IRIS Workshop 18th September 2007 47
Technical results of SDLSChapter 4.3: SDLS APR service
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.
IRIS Workshop 18th September 2007 48
Technical results of SDLSChapter 4.3: SDLS 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
IRIS Workshop 18th September 2007 49
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
IRIS Workshop 18th September 2007 50
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.
IRIS Workshop 18th September 2007 51
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.
IRIS Workshop 18th September 2007 52
Technical results of SDLSChapter 4.5: Transport layer issues
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.
IRIS Workshop 18th September 2007 53
Technical results of SDLSChapter 4.5: Transport layer issues
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?
IRIS Workshop 18th September 2007 54
Technical results of SDLSChapter 4.5: Transport layer issues
ATN SARPs does away with congestion in one sentence:
“It is assumed that sufficient bandwidth is made available”
IRIS Workshop 18th September 2007 55
Technical results of SDLSChapter 4.5: Transport layer issues
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”)
IRIS Workshop 18th September 2007 56
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.
IRIS Workshop 18th September 2007 57
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
IRIS Workshop 18th September 2007 58
Technical results of SDLSChapter 4.7: Application gateway (AGW)
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
IRIS Workshop 18th September 2007 59
Technical results of SDLSChapter 4.7: Application gateway (AGW)
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
IRIS Workshop 18th September 2007 60
Technical results of SDLSChapter 4.7: Application gateway (AGW)
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.
IRIS Workshop 18th September 2007 61
Technical results of SDLSChapter 4.7: Application gateway (AGW)
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
IRIS Workshop 18th September 2007 62
Technical results of SDLSChapter 4.7: Application gateway (AGW)
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
IRIS Workshop 18th September 2007 63
Chapter 5: History of Aeronautical activities
Summary of the study contracts
IRIS Workshop 18th September 2007 64
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)
IRIS Workshop 18th September 2007 65
Technical results of SDLSHistory of Aeronautical activities
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
IRIS Workshop 18th September 2007 66
Technical results of SDLSHistory of Aeronautical activities
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
IRIS Workshop 18th September 2007 67
Technical results of SDLSHistory of Aeronautical activities
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
IRIS Workshop 18th September 2007 68
Technical results of SDLSHistory of Aeronautical activities
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
IRIS Workshop 18th September 2007 69
Technical results of SDLSHistory of Aeronautical activities
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
IRIS Workshop 18th September 2007 70
Chapter 6: SDLS Demonstrator
IRIS Workshop 18th September 2007 71
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
IRIS Workshop 18th September 2007 72
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.
IRIS Workshop 18th September 2007 73
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
IRIS Workshop 18th September 2007 74
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
IRIS Workshop 18th September 2007 75
Chapter 7: Application gateway and ground handover extension
IRIS Workshop 18th September 2007 76
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
IRIS Workshop 18th September 2007 77
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
IRIS Workshop 18th September 2007 78
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
IRIS Workshop 18th September 2007 79
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
IRIS Workshop 18th September 2007 80
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
IRIS Workshop 18th September 2007 81
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 kathleen.gerlo@esa.int
+31 71 565 3781
IRIS Workshop 18th September 2007 82
Chapter 8: Overall Conclusions
Lessons learnt from SDLSFor consideration in the future
system design
IRIS Workshop 18th September 2007 83
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
IRIS Workshop 18th September 2007 84
Technical results of SDLSChapter 8: Overall Conclusions
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
IRIS Workshop 18th September 2007 85
Technical results of SDLSChapter 8: Overall Conclusions
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
IRIS Workshop 18th September 2007 86
Technical results of SDLSChapter 8: Overall Conclusions
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
IRIS Workshop 18th September 2007 87
Technical results of SDLSChapter 8: Overall Conclusions
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
IRIS Workshop 18th September 2007 88
Technical results of SDLSChapter 8: Overall Conclusions
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
IRIS Workshop 18th September 2007 89
Technical results of SDLSChapter 8: Overall Conclusions
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
IRIS Workshop 18th September 2007 90
Technical results of SDLSChapter 8: Overall Conclusions
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?
IRIS Workshop 18th September 2007 91
Technical results of SDLSChapter 8: Overall Conclusions
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
IRIS Workshop 18th September 2007 92
Technical results of SDLSChapter 8: Overall Conclusions
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”
IRIS Workshop 18th September 2007 93
Technical results of SDLSChapter 8: Overall Conclusions
All these issues are highly inter-related, and cannot be dealt with in isolation
Recommended