Technical results of SDLS activities

Transcription

1 activities Claude Loisy, Erling Kristiansen Iris workshop, ESTEC, September 18 th 2007 IRIS Workshop 18th September

2 Chapter 1: SDLS Historical context IRIS Workshop 18th September

3 Chapter 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

4 Chapter 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

5 Chapter 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

6 Chapter 1: SDLS Historical context SDLS approach for deploying Satellite Service for ATM Tailored design to aviation requirements Address all types of aircraft or at least a vast majority of them Be capable of offering ATM service compatible with high density airspace Dedicated protocols for optimised transmission delays Have a scope for mandating carriage in the future Adapt the AES design to the strict data link capacity requirements 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

7 Chapter 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 avionics Securing 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 to MHz Systems dedicated to safety communications should therefore enjoy the benefit of the priority clause without major difficulty IRIS Workshop 18th September

8 Chapter 1: SDLS Historical context Link dimensioning SDLS major overall design features 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

9 Chapter 1: SDLS Historical context Link dimensioning SDLS major overall design features 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

10 Chapter 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 redundant accesses 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 availability requirements 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

11 Chapter 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

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

13 Chapter 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) service Transponders 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

14 Chapter 2: Radio Link Design IRIS Workshop 18th September

15 Chapter 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

16 AES Receive mode Technical results of SDLS Chapter 2: Radio Link Design SDLS overall design features 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

17 Chapter 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

18 Multiple access from GESs Technical results of SDLS Chapter 2: Radio Link Design SDLS overall design features 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

19 Multiple access from GESs Technical results of SDLS Chapter 2: Radio Link Design SDLS overall design features 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

20 Chapter 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

21 Chapter 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

22 Chapter 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

23 Chapter 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

24 Chapter 2: Radio Link Design Conclusions and Caveats Link margins are however small in a global beam therefore Any unexpected inefficiency (either from RF link or protocol design) 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/s IRIS Workshop 18th September

25 Chapter 2: Radio Link Design Conclusions and Caveats Regional beams deployed for continental airspace Provide adequate margin for 8 Kb/s user data rate Regional Beam 8 Kb/s IRIS Workshop 18th September

26 Chapter 2: Radio Link Design Conclusions and Caveats Regional beams deployed for continental airspace Provide high latitude coverage capability Uncovered area limited by aircraft optical horizon IRIS Workshop 18th September

27 Chapter 2: Radio Link Design Conclusions and Caveats 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) Sub-regional Beams 64 Kb/s IRIS Workshop 18th September

28 Chapter 3: Network issues IRIS Workshop 18th September

29 Chapter 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

30 Chapter 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

31 ATN reference model Technical results of SDLS Chapter 3.1: SDLS services IRIS Workshop 18th September

32 Chapter 3.1: SDLS services When SDLS started, ATN was seen as the technology of choice by aviation There is now a shift of emphasis towards IP-based solutions An 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

33 SDLS ATN and its environment We should distinguish between Technical results of SDLS Chapter 3.2: SDLS ATN 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

34 Chapter 3.2: SDLS ATN The yellow part is SDLS. Everything else is environment IRIS Workshop 18th September

35 Chapter 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

36 Chapter 4: SDLS Services and protocols IRIS Workshop 18th September

37 Chapter 4.1: SDLS Services Original SDLS data link services ATN-compliant CLNP packet forwarding APR (Automatic Position Reporting) Later additions Ground handover (strictly speaking, not an SDLS service) Application layer gateway Voice services Point-to-point voice service Party line push-to-talk voice service (Point-to-point push-to-talk not explicitly addressed; similar to party line protocol) IRIS Workshop 18th September

38 Chapter 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

39 Chapter 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

40 Chapter 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

41 Chapter 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 long messages Inter-message interval is large (seconds to minutes) Many aircraft sharing a narrow channel, each generating very thin traffic IRIS Workshop 18th September

42 Chapter 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

43 Chapter 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

44 Chapter 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

45 Chapter 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 usage 2 solutions possible 1. 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

46 Chapter 4.3: SDLS APR service SDLS APR implements option 2 (broadcasting transmission schedule) APR does not match completely any ATN service The 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

47 Chapter 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

48 Chapter 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 reporting APR is similar in concept to radar Mode-S IRIS Workshop 18th September

49 Chapter 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

50 Chapter 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

51 Chapter 4.5: Transport layer issues The ATN protocol model assumes all data traffic is carried over the reliable end-to-end transport protocol TP4 ATM 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

52 Chapter 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

53 Chapter 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

54 Chapter 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

55 Chapter 4.5: Transport layer issues In summary: 2 problems: 1. Congestion control is ineffective for the traffic pattern 2. 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

56 Chapter 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 environment Does not solve problem 2: The incompatibility between inelastic traffic and elastic transport. IRIS Workshop 18th September

57 Chapter 4.7: Application gateway (AGW) Rationale for AGW In the absence of an extremely high over-provisioning of bandwidth, one has to assume that Congestion will happen And it will happen when it is least wanted: In an unusual operational situation such as massive flight re-routing due to weather or an incident the 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

58 Chapter 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

59 Chapter 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

60 Chapter 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

61 Chapter 4.7: Application gateway (AGW) Solves both problem 1 and 2 Drawbacks: 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

62 Chapter 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 congestion But 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 bandwidth Very simple, off-the-shelf solution. Is not susceptible to problem 1 Solves problem 2, but in a more crude way than AGW IRIS Workshop 18th September

63 Chapter 5: History of Aeronautical activities Summary of the study contracts IRIS Workshop 18th September

64 History of Aeronautical activities Study of Aeronautical Data Link System ( ) Feasibility study of a ATS dedicated communication system Requirements and cost benefit analysis Communication system design analysis Specifications of a demonstration system Budget : 200KAU Contractual action: Competitive tender : AO/1-2902/94/NL/US Contract: 11225/94/NL/US Contractor: Aerospatiale S.A. (F) Europe Aero-Conseil S.A. (F) Alcatel Espace S.A. (F) Racal Research Ltd (UK) 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

65 History of Aeronautical activities Aeronautical Satellite Data Link System For Air Traffic Management (Phase 1) 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/ / 97/ NL/ US Contract: 12472/97/NL/US Contractor: Alenia Spatio (I) ENAV (I) RTSN / Skysoft (P) Space Engineering (I) NAL / Airtel (Irl) Alenia Marconi Systems (I) Alenia Marconi Systems (I) 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

66 History of Aeronautical activities High Performance Mobile System ( ) 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/ / 97/ NL/ US Contract: 13019/98/NL/US Contractor: 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 Comaerosat study sponsored by CNES IRIS Workshop 18th September

67 History of Aeronautical activities Aeronautical Satellite Data Link System For Air Traffic Management ( ) Slice2: Service Demonstrator Budget : 3.6 M Contractual action: AO/1-3596/99/NL/US Contract: 14202/00/NL/US Contractor: Alcatel Space Industries (F) Airtel (Irl) Alcatel Bell (B) Skysoft (P) Vitrociset (I) Indra Espacio / Sema (E) Comments: Corresponds with Slice 2 of the original call for tender: AO/ / 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

68 History of Aeronautical activities SDLS Operational System Preliminary Definition ( ) Slice3: Upgrade the SDLS definition and specifications to the level required for an operational system in view of comparison with other candidate satellite systems Budget : 4,5 M Contractual action: Direct negotiation Contract: 17004/02/NL/US Contractor: Alcatel Space Industries (F) Sofreavia (F) Airtel (Irl) Skysoft (P) Vitrociset (I) Indra Espacio / Schlumberger Sema (E) Comments: Following the creation by Eurocontrol of the Nexsat working group 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

69 History of Aeronautical activities Air Traffic Management Systems for 2020 and beyond The expected role of satellites (VISTA) ( ) 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/us Contract: 17610/03/NL/US Contractor: 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

70 Chapter 6: SDLS Demonstrator IRIS Workshop 18th September

71 Chapter 6.1: Demonstrator goals On-ground realistic demonstration of the viability of the SDLS concepts Demonstrating over a real satellite link adds credibility Demonstrates 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

72 Chapter 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 system Some shortcuts were taken in the design, but services and performances largely remain representative The SDLS demonstrator will not directly scale to a full system, but the underlying concepts will. IRIS Workshop 18th September

73 Chapter 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

74 Chapter 6.3: Demonstrator overview AT ATS Applicatio S Application n Aeronautical communication system ATS AT Application Applicatio S n SDLS APR applicarions GE S Satellit e AE S SDLS APR application AO Applicatio AOC C Application n Internal services AO AOC Applicatio C Application n Voice applications Voice applications End to end applications IRIS Workshop 18th September

75 Chapter 7: Application gateway and ground handover extension IRIS Workshop 18th September

76 Chapter 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

77 Chapter 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

78 Chapter 7.3: AGW results Comparison was made between end-to-end TCP and TCP with the use of AWG 3 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 lowpriority 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

79 Chapter 7.4: Ground handover Demonstration of handover of control from one ATCC to another Satellite link over Artemis Makes use of the APR service to track flights and initiate handover when passing from one sector to the next Not really an SDLS core function; rather, an application of APR Handover between GESs in Toulouse and Rome Uses 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

80 Chapter 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

81 Chapter 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 21 st September kathleen.gerlo@esa.int IRIS Workshop 18th September

82 Chapter 8: Overall Conclusions Lessons learnt from SDLS For consideration in the future system design IRIS Workshop 18th September

83 Chapter 8: Overall Conclusions Feasibility of RF link dimensioning based upon isotropically radiating aircraft antenna and 40W max saturated HPA confirmed 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

84 Chapter 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

85 Chapter 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 20 years 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

86 Chapter 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

87 Chapter 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

88 Chapter 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

89 Chapter 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

90 Chapter 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

91 Chapter 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

92 Chapter 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

93 Chapter 8: Overall Conclusions All these issues are highly inter-related, and cannot be dealt with in isolation IRIS Workshop 18th September