1

/
International Civil Aviation Organization
WORKING PAPER / ACP-WGW02/WP-05
9April 2008

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

Working Group of the Whole (WG-W)

SECOND MEETING

April2008

Agenda Item : / 1 Finalisation of the Future Communications Study

Analysis ofB-AMC Performance

(Presented by UK NATS)

SUMMARY
NATS commissioned a model of B-AMC (Broadband Aeronautical Multicarrier Communications) to provide independent confirmation of the performance results of the EUROCONTROL sponsored B-AMC study that were presented in the ACP/WG-T/1 meeting in October 2007. The simulation development activity was undertaken by Helios between December 2007 and February 2008.The goal of this activity was to build a high fidelity protocol simulator of the B-AMC system using equivalent working assumptions to those taken in the previous B-AMC investigations and provide performance results with a focus on throughput and latency as a means of validating the previous results. This paper outlines the work that was undertaken to model B-AMC and describes the results thus obtained.
During the course of the study it was found that the user demand profiles used in the former B-AMC simulation activity were different to those developed for the current simulations. The main difference was in the length of the service messages, which in the present case was modelled closely upon the COCR figures. As a consequence the latencies observed in the current simulations were larger than the ones observed in the previous simulations. However the results show that the performance figures offered by B-AMC in a 500kHz channel configuration meet the COCRv2 requirements.

1.INTRODUCTION

1.1This paper provides a synthesis of information from coordinated investigations on B-AMC, P34 and AMACS. This paper was initially published with a comparison of P34 and AMACS and presented in ACP WG-T/1. This update injects further equivalent information on B-AMC.

1.2It describes the results of a B-AMC simulation campaign, commissioned by NATSand carried out by Helios, to provide an independent verification of the technical performance of the B-AMC system as specified in [10] [11]. It is intended that this information will contribute towards the planning of practical validation and prototyping activities foreseen in the next phase of the technology investigations (extending on the former Action Plan 17 investigations).

1.3A B-AMC simulator has been developed that simulates the point-to-point B-AMC protocol between ground stations and aircraft on a forward link and a reverse link and an outbound channel for a static scenario. The simulator is able to calculate:

  1. Actual throughput compared to load.
  2. TT95 Latency for each scenario (e.g. time between requesting reserved channel time and receiving an acknowledgement).
  3. Latency (time between requesting reserved channel time and peer reception of data).

1.4The simulator models the data link layer comprising the air-ground protocol suite. The physical layer is not modelled in detail. Instead, the performance is represented by a threshold frame error rate that was found to provide error free performance. The team evaluated the proposed figure and deemed it to be a reasonable figure for orthogonal frequency-division mulitiplexing (OFDM) performance.

1.5During the development of the simulation software, close coordination was maintained with the B-AMC consortium (Frequentis/DLR/USG) in order to ensure that consistent interpretation of the B-AMC specifications was carried onto the software implementation of the protocols. The Helios team is grateful to the B-AMC consortium team members for the feedback they kindly provided during the course of the development campaign. The questions raised by the Helios team and the associated resolutions are documented in [8].

1.6The scenarios used in the simulations are equivalent, in terms of message and aircraft traffic loading, to the ones previously used in the AMACS and P34 analysis.

1.7The values of the required latencies as specified in the COCRv2 [4] are given below for those messages used in these scenarios:

Message Type / Latency (secs) (95%)
ACL / 1.4
ACM / 1.4
AMC / 3.8
COTRAC / 2.4
D-ATIS / 2.4
DLL / 4.7
D-ORIS / 2.4
D-OTIS / 2.4
D_RVR / 2.4
D-SIGMET / 2.4
DYNAV / 4.7
FLIPINT / 2.4
PPD / 4.7
ENGINE / 26.5
FLTPLAN / 13.6
FLTSTAT / 13.6
FREETEXT / 26.5
FUEL / 26.5
GATES / 13.6
MAINTPR / 13.6
MAINTRT / 26.5
NOTAM / 26.5
POSRPT / 26.5
WXGRAPH / 13.6
WXRT / 13.6
WXTEXT / 13.6

Table 11: Required latencies for ATS and AOC messages

1

2.Creation of scenarios

2.1Traffic

2.1.1Static simulations were created for all scenarios; aircraft were distributed randomly within 150 NM of the single ground station. An illustration of the distribution of the aircraft in relation to the ground station is shown below.

Figure 21: Distribution of aircraft around ground station.

2.2Types of scenarios

2.2.1Five different scenarios have been run to investigate the performance of B-AMC and provide the widest possible cross section of results in the available time for comparison with the results in [4].The scenarios were selected from the ones specified in the FCI Evaluation Scenarios document [1]. The scenarios are:

  1. Large TMA (TMA LRG)
  1. Small Enroute sector (ENR SML)
  2. Medium Enroute sector (ENR MED)
  3. Large Enroute Sector (ENR LRG)
  4. Superlarge Enroute Sector (ENR SLG)

2.2.2Each scenario has been run with ATS traffic only as well as with a combination of ATS and AOC traffic. This allowed the performance of B-AMC to be evaluated across a large range of user demand in the given scenarios.

2.2.3The following table illustrates the scenarios that were evaluated in this campaign of simulations, against the scenarios that were evaluated in [1].

Scenario / PIAC / Present campaign / Comments
APT SFC / 264 /  / Covered by ENR LRG and ENR SLG
APT ZON / 26 /  / Presents a relatively small load – for protocol simulations performance regime is the same as TMA SML
TMA SML / 44 /  / Covered by ENR SML
TMA LRG / 53 /  / -
ENR SML / 45 /  / -
ENR MED / 62 /  / -
ENR LRG / 204 /  / -
ENR SLG / 522 /  / -

Table 21: Current scenarios compared to Evaluation scenarios [1]

2.2.4In addition, some scenarios have been run at the reduced bandwidth configurations of 250 kHz on the reverse link, to see how B-AMC would perform in this state.

2.2.5At smaller bandwidths, the structure of the slot map changes in two main ways:

  1. The amount of data that a given OFDM frame can hold decreases.
  1. The number of available channel request opportunities in a multiframe decreases
  2. Message profile

2.3.1The message profile was derived from the COCR v2 [4]. The en-route messages for P2-HD were used to create a table (shown below) indicating the probability of a message being sent in a sector during the approximately 16 minute en-route time. It was assumed that one ground station would cover a sector. This scenario was then increased to cover a 60 minute time period by creating four different 16 minute en-route profiles and running them consecutively.

Name of transfer / Number of repetitions / Transmitter / Receiver / Size (bytes) / Probability
ACL uplink / 2 / GS / Mob / 93 / 0.20
ACL downlink / 2 / Mob / GS / 93 / 0.20
ACM uplink / 1 / GS / Mob / 126 / 1.00
ACM downlink / 1 / Mob / GS / 88 / 1.00
AMC uplink / 1 / GS / Mob / 89 / 0.02
COTRAC (interactive) (25%) / 3 / GS / Mob / 1969 / 0.25
COTRAC (interactive) (25%) / 4 / Mob / GS / 1380 / 0.25
COTRAC (Wilco) (75%) / 2 / GS / Mob / 1613 / 0.75
COTRAC (Wilco) (75%) / 2 / Mob / GS / 1380 / 0.75
D-ALERT uplink / 1 / GS / Mob / 88 / 0.00
D-ALERT downlink / 1 / Mob / GS / 1000 / 0.00
D-ATIS (arrival) (30% of aircraft) uplink / 5 / GS / Mob / 100 / 0.06
D-ATIS (arrival) (30% of aircraft) downlink / 3 / Mob / GS / 93 / 0.06
DLL uplink / 1 / GS / Mob / 491 / 0.06
DLL downlink / 1 / Mob / GS / 222 / 0.06
D-ORIS uplink / 9 / GS / Mob / 478 / 0.20
D-ORIS downlink / 3 / Mob / GS / 93 / 0.20
D-OTIS uplink / 11 / GS / Mob / 193 / 0.14
D-OTIS downlink / 3 / Mob / GS / 107 / 0.14
D-RVR uplink / 4 / GS / Mob / 116 / 0.06
D-RVR downlink / 3 / Mob / GS / 121 / 0.06
D-SIGMET uplink / 4 / GS / Mob / 130 / 0.06
D-SIGMET downlink / 3 / Mob / GS / 129 / 0.06
DYNAV / 1 / GS / Mob / 515 / 0.06
DYNAV / 1 / Mob / GS / 82 / 0.06
FLIPINT uplink / 4 / GS / Mob / 143 / 1.00
FLIPINT downlink / 4 / Mob / GS / 2763 / 1.00
PPD uplink / 1 / GS / Mob / 105 / 0.20
PPD downlink / 1 / Mob / GS / 227 / 0.20
ENGINE uplink / 2 / GS / Mob / 88 / 0.20
ENGINE downlink / 2 / Mob / GS / 727 / 0.20
FLTPLAN uplink / 9 / GS / Mob / 968 / 0.20
FLTPLAN downlink / 9 / Mob / GS / 92 / 0.20
FLTSTAT downlink / 1 / Mob / GS / 157 / 0.2
FREETEXT uplink / 1 / GS / Mob / 377 / 0.2
FREETEXT downlink / 1 / Mob / GS / 377 / 0.2
FUEL downlink / 3 / Mob / GS / 127 / 0.4
GATES uplink / 1 / GS / Mob / 589 / 1
MAINTPR uplink / 4 / GS / Mob / 233 / 0.01
MAINTPR downlink / 4 / Mob / GS / 233 / 0.01
MAINTRT uplink / 5 / GS / Mob / 88 / 0.4
MAINTRT downlink / 5 / Mob / GS / 127 / 0.4
NOTAM uplink / 4 / GS / Mob / 287 / 0.4
NOTAM downlink / 2 / Mob / GS / 134 / 0.4
POSRPT uplink / 1 / GS / Mob / 88 / 1
POSRPT downlink / 1 / Mob / GS / 338 / 1
WXGRAPH uplink / 5 / GS / Mob / 21077 / 0.82
WXGRAPH downlink / 6 / Mob / GS / 93 / 0.82
WXRT downlink / 5 / Mob / GS / 103 / 1
WXTEXT uplink / 5 / GS / Mob / 680 / 0.4
WXTEXT downlink / 2 / Mob / GS / 103 / 0.4

Table 2-2: Probability of each application being included in the message profile.

2.3.2The COTRAC application was treated slightly differently as it is stated in the COCR v2 that 25% of the aircraft will use COTRAC interactive and 75% will use COTRAC Wilco. Once the random number had been generated, only one of the versions of COTRAC was used for that 16 minute profile.

2.3.3It should be noted that this user demand profile did not include the use of Auto-Exec, given that the probability of service invocation specified in the COCR is of 1 instance per year (per ATSU). It is considered that even in the case of a whole scale invocation of this service the relatively modest size of this message would not present a large increase in channel demand.

2.3.4The user message profiles used in the present campaign were identical to those used in the AMACS and P34 simulations. These profiles attempt to replicate the COCR traffic loading (both in terms of message frequency and message length) considering the pool of ATS and AOC specified in the COCR. The user demand profile is calculated on a per aircraft basis such that the load imposed on the system across the whole scenario is a multiple of the load placed on each aircraft. In this respect the loading on each aircraft is constant. The following figure extracts a one minute sample of the user demand profile for a typical simulation.

Figure 02: Sample of user demand (ATS+AOC)

2.4Parameters

The following table contains the main parameters used in the simulations.

Parameter description / Default Value / Notes
Number of subcarriers used for the Reverse Link / 48 / For the 500kHz scenarios 48 subcarriers were used, for the 50kHz scenarios 5 subcarriers were used etc…
Number of subcarriers used for the Forward Link / 48
Number of user data bits in one slot on one subcarrier for the forward link / 38 bits / The total amount of bits that can fit into this space is 48 bits. However a 10% overhead has been removed.
Number of user data bits in one slot on one subcarrier for the reverse link / 38 bits / The total amount of bits that can fit into this space is 48 bits. However a 10% overhead has been removed.
SuperFrame length / 37 slots / This value wasn’t changed for any of the simulations.
Initial value for the RTT timer / 620ms
Maximum number of retries / 10
Total number of aircraft on the RL / User defined and should correspond with the station’s file.

Table 23 - B-AMC parameters used

2.5Assumptions

2.5.1The following assumptions were made:

  1. At the start of the simulation, it is assumed that all the aircraft have already set up a link with the ground station. The link is never reset.
  1. The scenarios simulated are static i.e. the aircraft are distributed randomly within the service volume and remain in the same position for the duration of the simulation.
  2. The simulation time was set to 1 hour and the whole of the scenario was analysed.
  3. The entire aircraft population in a given scenario is always within reception range.
  4. The amount of user data that can fit in one subcarrier in one slot is 38 bits. This is due to the removal of a 10% header.
  5. No parameters changed from their initial values during the scenario.

1

3.Modelling B-AMC

3.1Introduction

3.1.1The code for the simulator has been written based on the B-AMC high level specifications documented in [2].

3.1.2Modifications made to the simulator are listed below:

  1. In the DLR/Frequentis B-AMC simulator an acknowledgement (ACK) is sent by the ground station after every data packet sent by the aircraft. In addition cumulative ACKs sent by the ground station to multiple aircraft were implemented. In this simulator an ACK is only sent at the end of the message from the aircraft and it is not possible for the ground station to send multiple ACKs.
  1. In the DLR/Frequentis B-AMC simulator it is possible for an aircraft to send more than one message in the data slot. This is not implemented in this simulator. It is not felt that this will impact the simulator significantly as the majority of the messages are larger than one slot.
  2. Methods and assumptions in the simulator

3.2.1.1The following methods and assumptions were made for the design of the simulator. For a more detailed description of the simulator see [8].

3.2.2Physical Layer

3.2.2.1The physical layer was written to match the performance of the simulator created by DLR and Frequentis. Accordingly the performance was fixed at a rate of 10-2 FER. The exceptions to this were SA, CC and DC slots where the FER was set to 0.

3.2.2.2OFDM ideal conditions were assumed i.e. no intercarrier interference was modelled.

3.2.3Breathing cycle

3.2.3.1SA, DC and CC slots are all linked.

Figure 03: A Multiframe [11]

3.2.3.2In order to explain how these slots are allocated the SA slot will be taken as an example. Aircraft are allocated subcarriers in the SA slot starting with the first aircraft in the scenario. When the subcarriers have all been allocated the next SA slot is used. Once all the aircraft have been assigned a subcarrier allocation begins with the first aircraft again. Every subcarrier has an aircraft allocated to it. The aircraft allocated to the first subcarrier in the SA slot is assigned data slots first. As it is likely that each SA slot will begin with a different aircraft, each aircraft is given fair access to the slot map.

3.2.3.3Each aircraft is allotted at most one slot for transmission in every multiframe (in order to limit the duty cycle of cosite transmissions). The transmission in this slot may be across one or a multiple of sub channels.

3.2.4Duplex

3.2.4.1The system operates in full duplex mode (the ground station may transmit to a mobile on the forward link while that mobile is also transmitting in the corresponding slots on the reverse link).

3.2.5Karn’s algorithm

3.2.5.1Karn’s algorithm will be used to calculate the time that a station waits for an ACK, having sent a data packet before it retransmits. It has been configured to reduce over reaction to occasional fluctuations in the round trip time. As retransmissions occur the timer will be increased by a factor of 2. The timer remains at this larger value until a successful round trip can be measured and then the timer is adjusted using Karn’s algorithm. Karn’s algorithm allows the RTT timer to react dynamically to the changing load on the channel.

1

4.Results

4.1Introduction

4.1.1This section presents the results of the simulation campaign where results are compared to the results in D5 and the required latencies in the COCR.

4.2Explanation of terms

  1. Latency – This is defined as the time between submission and reception of data, measured at the 95th percentile.
  1. TT95 – This is defined, as stated in the COCRv2, as half the time between submission and the reception of ACK, measured at the 95th percentile.
  2. Demand load (kbps) – The throughput present in the message script as an average over the whole scenario.
  3. Achieved throughput (kbps) – The sent and acknowledged messages as an average over the whole scenario.
  4. Results

4.3.1The results from the simulations are provided below. Shaded cells in the case of latency indicate requirements that are not met. Shaded cells in the case of throughput indicate less than 95% throughput.

4.3.2A one to one comparison has been carried out by constructing a message profile that is as similar as possible to the one used in the D5 simulations. The purpose of these simulations was to build confidence in the results of the simulator and ensure consistent behaviour with respect to the protocol implementations against those of the USG simulator. The remaining simulations have been run with input profiles based on the COCRv2 [3].

4.3.2Simulations using equivalent message profiles

4.3.2.1These one to one comparison simulations were run using message profiles that were generated as closely as possible to those used to generate the results in D5 [9]. These runs are based on the ENR SML and ENR LRG scenarios, and the channel sizes are 500 kHz (each for RL and FL). Every message transmitted in the simulation is 1000 bits long and for this simulation only it is assumed that 48 user data bits can fit into a subcarrier during the period of a slot.

Scenario / D5 simulations / Current Simulations
Demand (kbps) / Achieved (kbps) / Latency (ms) / Demand (kbps) / Achieved (kbps) / Latency (ms)
FL / RL / FL / RL / FL / RL / FL / RL / FL / RL / FL / RL
ENR SML / 33 / 33 / 32.96 / 32.98 / 18 / 153 / 30 / 30 / 30.00 / 30.00 / 28 / 140
ENR LRG / 33 / 44 / 32.97 / 44.01 / 18 / 832 / 33 / 44 / 32.98 / 43.97 / 26 / 490

Table 41: Simulation results, throughput and latencies

1

4.3.3Performance comparison using COCR defined message profiles for a forward and reverse channel size of 500 kHz

4.3.3.1The results presented in this section were obtained using message profiles that mimic exactly those specified in the COCR, as described in 2.3.The following tables illustrate the throughput and latency results.

Throughput

Scenarios / Channel size (kHz) / No of aircraft / D5 simulations
(demand based on COCR Table 6-28) / Current Simulations
(demand based on service invocation profile specified in COCR Tables 6-3 and 6-4)
Demand (kbps) / Achieved (kbps) / Demand (kbps) / Achieved (kbps)
FL / RL / FL / RL / FL / RL / FL / RL
TMA LRG ATS / 500 / 53 / 33 / 33 / 32.94 / 32.97 / 2.78 / 6.49 / 2.78 / 6.49
TMA LRG ATS and AOC / 500 / 53 / 33 / 33 / 32.94 / 32.97 / 44.81 / 7.31 / 44.81 / 7.31
ENR SML ATS / 500 / 45 / 33 / 33 / 32.95 / 32.98 / 2.22 / 5.45 / 2.22 / 5.45
ENR SML ATS and AOC / 500 / 45 / 88 / 33 / 88.07 / 32.98 / 36.75 / 6.15 / 36.75 / 6.15
ENR MED ATS / 500 / 62 / 33 / 33 / 32.97 / 32.99 / 3.17 / 7.62 / 3.17 / 7.62
ENR MED ATS and AOC / 500 / 62 / 110 / 33 / 109.93 / 32.99 / 47.89 / 8.64 / 47.89 / 8.64
ENR LRG ATS / 500 / 204 / 33 / 44 / 32.97 / 44.01 / 9.94 / 24.82 / 9.94 / 24.80
ENR LRG ATS and AOC / 500 / 204 / 220 / 44 / 220.02 / 44.01 / 159.88 / 27.88 / 159.83 / 27.84
ENR SLG ATS / 500 / 522 / 44 / 55 / 43.95 / 54.92 / 24.92 / 62.77 / 24.92 / 60.63

Table 42: Simulation results, throughputs