Phoenix Communication System Architecture and … Communication System Architecture ... Presentation Outline ... Key Design Elements for AMSS+ (2): Queuing Analysis / Meeting Delay

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed

Robert Schweikert (AUDENS ACT)Markus Werner (TriaGnoSys)

ESTEC, Noordwijk 06.02.2009

ESA Artes-10 “Iris”

PhoenixCommunication System Architecture and Protocols Consolidated Design

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed

Phoenix Final Presentation ESTEC, Noordwijk, 06.02.2009 2

Presentation Outline

Overview of objectives and scope of workAMSS basicsEnhanced AMSS (“AMSS+”) designSystem dimensioningSensitivity studiesSummary and Conclusions

(AMSS = Aeronautical Mobile Satellite Service)

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Objectives and Work Performed

Based on existing “Aeronautical Mobile Satellite Service” (AMSS) as specified in ICAO SARPS:► Development of extensions to meet future key user

requirements► Reuse as much AMSS protocol design as appropriate ► Focus on lower layers:

● Physical & link layer, incl. FEC coding● Channel structure and rates

Communication system architecture & dimensioning► Protocol design impact► Capacity analysis, channel & bandwidth dimensioning► Link budgets & satellite parameters► Sensitivity analyses

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Aeronautical Mobile Satellite Service (AMSS)Key Characteristics

ICAO approved air-ground data & voice communications including safety-critical servicesP- channel (≤ 10.5 kbps)► Forward (FWD) direction, user traffic and signaling► Time Division Multiplexing (TDM)

T- channel (≤ 10.5 kbps)► Return (RTN) direction, user data/messages► Time Division Multiple Access (TDMA)

R- channel (≤ 10.5 kbps)► Return (RTN) direction, signaling/system managm. & user data► Random Access (slotted ALOHA) channel (contention based)

C- channel (≤ 21 kbps)► Bi-directional circuit mode voice and data

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Requirements, Assumptions, Constraints

Phoenix key input and requirements► COCR

● mainly short messages● stringent delay requirements

► Voice comm.: a few seconds lasting message exchange

Phoenix key challenges► Increase bandwidth efficiency (e.g. reduction of guard

spaces)► Login, initial terminal acquisition without any navigation aid► Meet specific AES terminal constraints

● Single TX channel● Low gain antenna

► Tackle inherent multiple access efficiency issue <-> resource management

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Key Design Elements for AMSS+ (1)

Removal of the C-Channel concept;incorporation of voice data onto the P-channel in forward, and in the T-channel in return direction, respectively,

Introduction of a modified P-channel with a channel bit rate of 42 kbps in forward direction,

Introduction of 21 kbps modified T- and R- channel in return direction

Proposed channel rates are a result of trade-off mainly between delay requirements and link budget limitations

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Key Design Elements for AMSS+ (2):Queuing Analysis / Meeting Delay Requirements

Strictly following the COCR queuing analysis, adapted to satellite caseConsidering all applicable message/packet overheads

Key requirementis the total delay(TT95)

including alldelay elements

Forward Return21 42 10,5 21

NETCONN DG-A 0,19 0,10 0,47 0,26 9,43 8,73NETKEEP DG-A 0,12 0,06 0,34 0,19 9,47 8,80ACL DG-C 0,12 0,06 0,34 0,19 1,07 0,40ACM DG-C 0,16 0,08 0,34 0,19 1,05 0,40AMC DG-D 0,12 0,06 0,00 0,00 3,47 2,99ARMAND DG-D 0,31 0,16 0,34 0,19 4,27 3,70C&P ACL DG-D 0,12 0,06 0,34 0,19 2,07 1,40COTRAC (interactive) DG-D 2,32 1,17 4,03 2,13 0,96 -0,54COTRAC (Wilco) DG-D 1,91 0,96 4,03 2,13 1,17 -0,54D-ALERT DG-D 0,11 0,06 3,36 1,78 2,07 -0,19D-ATIS (arrival) DG-D 0,13 0,06 0,34 0,19 2,07 1,40DLL DG-D 0,58 0,29 0,64 0,34 4,14 3,55D-ORIS DG-D 0,56 0,28 0,34 0,19 1,85 1,40D-OTIS DG-D 0,24 0,12 0,38 0,21 2,01 1,38D-RVR DG-D 0,15 0,07 0,42 0,23 2,06 1,36DSC DG-D 0,12 0,06 0,32 0,18 8,87 8,21D-SIGMET DG-D 0,16 0,08 0,43 0,24 2,05 1,35DYNAV DG-D 0,62 0,31 0,32 0,18 4,12 3,71FLIPCY DG-D 0,13 0,07 0,53 0,28 2,06 1,31FLIPINT DG-D 0,18 0,09 8,07 4,27 2,04 -2,68ITP ACL DG-D 0,12 0,06 0,34 0,19 2,07 1,40M&S ACL DG-D 0,12 0,06 0,34 0,19 2,07 1,40PPD DG-D 0,13 0,07 0,87 0,47 4,36 3,42SAP (Contract Establishment) DG-D 0,12 0,06 0,36 0,20 2,07 1,39SAP (Periodic Report) DG-D 0,00 0,00 0,38 0,21 2,13 1,38URCO DG-D 0,13 0,06 0,32 0,18 2,07 1,41

P-channel rates (kbps)

Available delay for queuing (sec)Service

T-channel rates (kbps)

Tx delay (sec)Class

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Key Design Elements for AMSS+ (3)

In forward and return direction, the application of more efficient FEC, (such as turbo coding, rate 1/2 (data), rate 2/3 (voice)

In forward direction, pre-compensation of the Doppler on the feeder uplink due to satellite motions as well as satellite oscillator drifts

In return direction, establishment of closed loop (GES –AES) frequency & timing control

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Key Design Elements for AMSS+ (4):Random Access

Because of permissible traffic load ≤ ~ 20% ! of channel capacity

► on R/A -channel only signaling/system management data but no user data;

► For services requiring e.g. a periodic message transfer over a longer period of time (such as reporting type service) the allocation of a fixed resource share on the T-channel;

Signaling on R/A channel (resource request, termination info) only at beginning and end of the service

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Key Design Elements for AMSS+ (5):P- and T- Channel Parameters

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Key Design Elements for AMSS+ (6):R/A-Channel Concept and Parameters

Supports fixedassignment andrandom access

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Handover and Mobility

Handover of AES between (i) ground earth stations (GES) and (ii) beams/satellites is basically supported in AMSSBeam and GES handovers in current AMSS ► require log-off/log-on of AES► with corresponding communication interruptionTo meet future ATM comms requirements, further work on AMSS+ should include “seamless” handover► frequency/timing synchronisation between intra-GES and inter-

GES carriers Integration with higher-layer mobility (e.g., mobile IP) is important for future work► consider existing frameworks (ETSI-BSM/SI-SAP, IEEE 802.21)► consider ongoing project work (NEWSKY etc.)

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


System-Level Issues of Comms System Design

Overall capacity and bandwidth requirements► over space and time► break-down into

channels and services

Potential offrequency reuse

Link budgets(for spot beams)

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


ATS (addressed) data - COCR message/queuing modelsAOC (addressed) data - COCR message/queuing modelsATS voice - COCR voice parameters/Erlang modelAOC voice - ECTL voice parameters/Erlang model(Broadcast and surveillance) - COCR message/queuing models

Domain-specific message and call parameters according to COCRCompletely parametric calculation/simulation throughoutPropagation, MAC, and transmission delays considered before queuing analysis!

Considered Services and Modelling Approach

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Spot Beam System and Frequency Plan

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Reference Results: Normalized Worst CaseCapacity and Channels

Beam/AreaFWD RTN RTN Reservat. P T T R/A

(voice+data) (voice+data) (surv.) Requests (v.+d.) (v.+d.) (surv.)[kbit/s] [kbit/s] [kbit/s] [req./s]

S1 14,2% 11,4% 6,0% 0,8% 6,7% 10,5% 6,2% 1,6%S2 4,0% 3,0% 0,8% 0,1% 2,0% 3,0% 1,0% 0,2%S3 8,4% 5,1% 2,0% 0,4% 3,8% 4,8% 2,0% 0,8%S4 38,0% 28,9% 19,0% 2,7% 16,7% 26,8% 19,2% 4,8%S5 10,5% 7,1% 3,2% 0,5% 4,8% 6,5% 3,4% 1,0%S6 7,6% 4,6% 1,7% 0,3% 3,6% 4,4% 1,8% 0,6%

ECAC non-adaptive 82,8% 60,1% 32,5% 4,8% 37,5% 56,0% 33,5% 8,9%ECAC adaptive 76,8% 56,5% 30,3% 4,3% 34,1% 52,2% 30,8% 7,7%

R1 1,9% 1,4% 1,0% 0,2% 1,0% 1,4% 1,0% 0,4%R2 2,3% 1,1% 0,3% 0,1% 1,0% 1,2% 0,4% 0,4%R3 2,6% 1,2% 0,3% 0,2% 1,2% 1,2% 0,4% 0,4%R4 1,5% 0,9% 0,1% 0,1% 0,8% 1,0% 0,2% 0,2%R5 1,1% 0,9% 0,1% 0,0% 0,6% 1,0% 0,2% 0,2%R6 1,2% 0,9% 0,1% 0,0% 0,6% 1,0% 0,2% 0,2%R7 1,7% 0,9% 0,1% 0,1% 0,8% 1,0% 0,2% 0,2%

SAT non-adaptive 95,1% 67,4% 34,6% 5,4% 43,5% 63,7% 36,1% 10,9%SAT adaptive 87,2% 63,1% 32,0% 4,8% 38,7% 58,7% 32,5% 8,7%

Worst Case Capacities Required Number of Channels

Normalized RTN capacity 100% Normalized RTN channels 100%

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Conclusions from Numerical Results

Exclusion of surveillance services 30% less mobile uplink bandwidth Dominance of ECAC over rest of satellite/regional beams

Dominance of ECAC center beam S4 > 50% of total trafficHence, frequency reuse ► will be heavily limited by the inhomogeneous traffic demand► saves some 30% in the overall bandwidth requirements, and thus

achieves the upper limit of possible gain (for this number of beams)

Adaptive configuration is supposed to gain some 10%, exploiting peak loads per beam appearing at different times of the day

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Sensitivity Analysis (1):Scenario / Airspace Partitioning

Worst-case scenario: ► satellite serves 100% of the traffic in all domains

Reduced scenario: ► satellite does not serve APT, 5% of TMA, 5% of ENR voice,

50% of ENR data, and 100% of ORP traffic.






100% 100%






15% 17%

87% 87%

27% 12%

RTN RTNFWD FWD

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Sensitivity Analysis (2):Service Parameter Values

There are some dominating /critical servicesTheir inclusion and/or specific parameter values may influence the total capacity requirements significantlyThe design freedom to slightly exceed a particular message delay requirement may impact significantly as wellSome sensitivity studies have shown tens of percent or even a few orders of magnitude differencesThere are other less impacting servicesFor instance, the exact ‘call duration’ of AOC/ATC voice is not that critical

©20

09 -

Tria

Gno

Sys

Gm

bH -

All

right

sre

serv

ed


Summary & Conclusions

Work done► Enhanced AMSS (AMSS+) protocol design► Comm. system architecture and dimensioning

Main findings► A workable solution extending an existing protocol is

possible► Approach selected so far is considered a good starting point

for potential further optimisation / efficiency increase

Recommendations for future work► Many of the lessons learnt applicable to both

● other starting points/ existing protocols● new protocol design

► Impact factors to be monitored and/or fixed● COCR message set and detailed requirements● technology/user terminal development …

Documents

Phoenix Communication System Architecture and … Communication System Architecture ... Presentation Outline ... Key Design Elements for AMSS+ (2): Queuing Analysis / Meeting Delay