REPORT D 3 System Specification Including … · REPORT D 3 System Specification Including...

REPORT D 3 System Specification Including Standardization

and Certification Considerations

PROJECT TITLE: BROADBAND AERONAUTICAL MULTI-CARRIER

COMMUNICATIONS SYSTEM

PROJECT ACRONYM: B-AMC

PROJECT CO-ORDINATOR:

FREQUENTIS AG FRQ A

PRINCIPAL

CONTRACTORS: DEUTSCHES ZENTRUM FÜR LUFT UND RAUMFAHRT E.V. DLR D

PARIS LODRON UNIVERSITAET SALZBURG USG A

MILERIDGE LIMITED MIL UK

DOCUMENT IDENTIFIER: D 3

ISSUE: REV 1.0

ISSUE DATE: 14.08.2007

AUTHOR: DLR

DISSEMINATION

STATUS: PUBLIC

DOCUMENT REF: CIEA15_EN505.10

Dieses Dokument ist elektronisch freigegeben.

This document is released electronically.

Report number: D 3 Issue: Rev 1.0

File: Final_D3_V10.doc Author: DLR

Page: I

History Chart

Issue Date Changed Page (s) Cause of Change Implemented by

Rev 01 29.05.2007 All sections TOC for new document

DLR

Rev 02 19.06.2007 All sections First draft version DLR, USG

Rev 03 28.06.2007 All sections Review comments DLR, USG

Rev 1.0 08.08.2007 All sections Completion, including review comments on Rev 03 from ECTL and FAA

DLR, USG, FRQ

Authorisation

No. Action Name Signature Date

1 Prepared M. Schnell (DLR), S. Gligorevic (DLR), S. Brandes (DLR), C.-H. Rokitansky (USG), M. Ehammer (USG), T. Gräupl (USG), C. Rihacek (FRQ) M. Sajatovic (FRQ)

08.08.2007

2 Approved M. Schnell (DLR) 08.08.2007

3 Released C. Rihacek (FRQ) 09.08.2007

The information in this document is subject to change without notice.



Page: II

Contents

1. Executive Summary.......................................................1-1

2. Introduction .................................................................2-1

3. Physical Layer Specification ............................................3-1 3.1. Identification of Required Adjustments.............................................. 3-1 3.1.1. Special L-band Conditions ............................................................... 3-1 3.1.2. Required Adjustments .................................................................... 3-2 3.1.2.1. Duplex Scheme for A/G Communication ............................................ 3-2 3.1.2.2. Forward Link Access-scheme ........................................................... 3-2 3.1.2.3. OFDM Parameters .......................................................................... 3-2 3.1.2.4. Framing Structure.......................................................................... 3-3 3.2. Adapted OFDM Parameter Set for B-AMC........................................... 3-3 3.3. Adaptive Coding and Modulation ...................................................... 3-6 3.4. Code Design for Strong Interference................................................. 3-8 3.4.1. Outer Code Design......................................................................... 3-9 3.4.2. Inner Code Design ....................................................................... 3-10 3.4.3. Code Performance........................................................................ 3-13 3.4.4. Additional Code Performance Improvement ..................................... 3-17 3.5. Channel Estimation and Equalization............................................... 3-17 3.6. Synchronization........................................................................... 3-18 3.7. Sidelobe Suppression Techniques ................................................... 3-20 3.8. Physical Layer Frame Structure...................................................... 3-22

4. Protocol Specification.....................................................4-1 4.1. B-AMC Medium Access Sub-Layer..................................................... 4-2 4.1.1. Communications Channels - Overview............................................... 4-2 4.1.2. BSS Entity - Overview .................................................................... 4-2 4.1.3. A/G Mode MAC Entity - Overview ..................................................... 4-3 4.1.4. A/A Mode MAC Entity - Overview...................................................... 4-4 4.2. Air/Ground Medium Access Sub-Layer............................................... 4-4



Page: III

4.2.1. A/G MAC Frame Structure ............................................................... 4-6 4.2.1.1. Transfer of User Data ..................................................................... 4-7 4.2.1.2. Transfer of Voice............................................................................ 4-8 4.2.1.3. Transfer of Signalling Data .............................................................. 4-9 4.2.2. Resource Allocation for the RL ......................................................... 4-9 4.2.3. The Role of the BSS in the Resource Allocation on the RL................... 4-11 4.2.4. Additional Medium Access Performance Improvements ...................... 4-12 4.3. B-AMC Logical Link Control Sub-Layer............................................. 4-13 4.3.1. A/G Mode LLC ............................................................................. 4-14 4.3.2. DLS ........................................................................................... 4-14 4.3.3. LME ........................................................................................... 4-14 4.3.4. Voice Interface ............................................................................ 4-14 4.3.5. Interface to the Upper Layers ........................................................ 4-14 4.4. Description of Protocol Message Flow and Interface .......................... 4-16 4.4.1. Primitives of the Physical Layer ...................................................... 4-16 4.4.2. Primitives of the MAC-Entity .......................................................... 4-17 4.4.3. Primitives of the BSS.................................................................... 4-18 4.4.4. Message Flow of the DLS .............................................................. 4-19 4.4.5. Message Flow of the LME .............................................................. 4-20 4.4.6. Primitives Offered by the A/G B-AMC Data Link Layer........................ 4-22 4.4.6.1. B-AMC DLL Interface for Radio Control ............................................ 4-23 4.4.6.2. B-AMC DLL Interface to the Voice Switching System ......................... 4-24 4.4.6.3. B-AMC DLL Interface for System Management ................................. 4-24 4.4.6.4. B-AMC DLL Interface to the B-AMC Sub-Net � Link Status.................. 4-26 4.4.6.5. B-AMC DLL Interface to the B-AMC Sub-Net � Data Transfer .............. 4-27 4.4.6.6. B-AMC Sub-Network Interface ....................................................... 4-28 4.4.7. Additional B-AMC Interface Improvements....................................... 4-29

5. Standardization Activities and Certification Issues..............5-1 5.1. Introduction .................................................................................. 5-1 5.1.1. Further Steps ................................................................................ 5-1 5.2. General Approach for Certification of Airborne Systems ....................... 5-2 5.2.1. ICAO............................................................................................ 5-2 5.2.2. EUROCAE/RTCA............................................................................. 5-3 5.2.3. JAA/EASA/FAA............................................................................... 5-5



Page: IV

5.2.4. ARINC.......................................................................................... 5-5 5.2.5. ETSI ............................................................................................ 5-6

6. References ...................................................................6-1

7. Abbreviations ...............................................................7-1

8. Appendix � Protocol Design for A/A Mode .........................8-1 8.1. Assumptions ................................................................................. 8-1 8.2. Slot Occupancy Transmission in Management Slots............................. 8-1 8.3. Net Entry...................................................................................... 8-3 8.4. Choosing a Slot ............................................................................. 8-4 8.5. Changing the Slot .......................................................................... 8-5 8.6. Data Transmission ......................................................................... 8-5 8.7. Bitmap Transmission ...................................................................... 8-6 8.8. Net Exit ........................................................................................ 8-6 8.9. Remark: Further Extensions of the A3C Basic Mode ............................ 8-7 8.10. A/A Mode LLC Design ..................................................................... 8-8 8.10.1. FEC Algorithms and Techniques ....................................................... 8-8 8.10.2. LLC Based on Single CCC Approach .................................................. 8-9



Page: V

Illustrations

Figure 3-1: Standard B-AMC OFDM frame (FL). .................................................. 3-5 Figure 3-2: Convolutional code within one frame................................................. 3-8 Figure 3-3: Error correction principle................................................................. 3-8 Figure 3-4: Block diagram of B-AMC system....................................................... 3-9 Figure 3-5: Active distances of convolutional codes listed in Table 3-4 with depth given in number of codebits.................................................. 3-12 Figure 3-6: Exemplarily bit and byte error pattern at the convolutional decoder output for CC1 and CC5 at Eb/N0=5 dB................................ 3-13 Figure 3-7: Exemplarily bit and byte error pattern at the inner decoder output for CC3 at Eb/N0=15 dB. ..................................................... 3-14 Figure 3-8: Exemplarily bit and byte error pattern at the inner decoder output for CC4 at Eb/N0=15 dB........................................... 3-15 Figure 3-9: Exemplarily bit and byte error pattern at the inner decoder output for CC9 at Eb/N0=15 dB. ..................................................... 3-16 Figure 3-10: Most simple pilot symbol structure and DME interference impact......... 3-17 Figure 3-11: B-AMC pilot symbol structure adjusted to DME interference. .............. 3-18 Figure 3-12: Standard Schmidl & Cox synchronization symbol structure (upper part) and proposed synchronization symbol structure (lower part) for improved performance under impact of DME interference. ................. 3-19 Figure 3-13: Sidelobe suppression capabilities of cancellation carriers technique combined with transmit signal windowing.......................... 3-21 Figure 3-14: B-AMC physical layer framing structure. .......................................... 3-22 Figure 3-15: Detailed BC frame structure containing three sub-frames................... 3-23 Figure 3-16: RA slot structure with two RA opportunities. .................................... 3-24 Figure 3-17: Standard B-AMC OFDM frame (RL). ................................................ 3-25 Figure 3-18: BC sub-frames 1/3 (upper part) and 2 (lower part)........................... 3-26 Figure 3-19: RA frame. ................................................................................... 3-26 Figure 4-1: High-level structure of the B-AMC data link layer. ............................... 4-1 Figure 4-2: B-AMC channel mapping aircraft perspective...................................... 4-3 Figure 4-3: Multi-frame structure. .................................................................... 4-6 Figure 4-4: Super-frame structure. ................................................................... 4-7 Figure 4-5: RL resource assignment via CCCH. ................................................... 4-8 Figure 4-6: Resource requesting with Nc,used users. ............................................ 4-10 Figure 4-7: Reservation cycle for 2 Nc,used users. ............................................... 4-10 Figure 4-8: Mapping of transport channels to physical channels. ......................... 4-12



Page: VI

Figure 4-9: B-AMC DLL architecture in A/G mode.............................................. 4-13 Figure 4-10: Protocol stack showing the B-AMC interface (ATN case)..................... 4-15 Figure 4-11: Protocol stack showing the B-AMC interface (IPS case)...................... 4-15 Figure 4-12: B-AMC primitives to transmit and receive DLS data........................... 4-19 Figure 4-13: Message sequence chart for transmitting DLS data. .......................... 4-20 Figure 4-14: Message sequence chart for receiving DLS data................................ 4-20 Figure 4-15: B-AMC primitives to transmit and receive LME data........................... 4-20 Figure 4-16: Message sequence chart for transmitting LME data. .......................... 4-21 Figure 4-17: Message sequence chart for receiving LME data................................ 4-21 Figure 4-18: B-AMC primitives to transmit RA frames during net-entry. ................. 4-21 Figure 4-19: Message sequence chart for transmitting LME data during net entry. ... 4-22 Figure 4-20: Message sequence chart for receiving LME data during net entry. ....... 4-22 Figure 4-21: B-AMC interface to the upper layers. .............................................. 4-23 Figure 8-1: B-AMC A3C TDMA structure............................................................. 8-1 Figure 8-2: Hidden station problem................................................................... 8-2 Figure 8-3: Collision scenario where two stations (A and B) transmit in the same slot...................................................................................... 8-6 Figure 8-4: B-AMC A/A physical, MAC and DLL layer with a single CCC................. 8-10

Tables

Table 3-1: Main OFDM parameters for B-AMC.................................................... 3-6 Table 3-2: Application of adaptive coding and modulation in dependence of interference and channel conditions. ............................................. 3-7 Table 3-3: Achievable net information data rates with adaptive coding and modulation. .................................................................................. 3-7 Table 3-4: A choice of convolutional codes...................................................... 3-11 Table 3-5: Block codes for different coded packet sizes..................................... 3-16 Table 4-1: Exemplary transport channel definition for Nc,used=48, n=48,24,12,6,3. . 4-5 Table 8-1: Derived occupancy table from own sight and neighbour table (row A-H).8-3 Table 8-2: Own sight creation. ........................................................................ 8-4 Table 8-3: A/A addressed COS categories, taken from [COCRv2] Table 6-19. ........ 8-9 Table 8-4: Broadcast COS categories, taken from [COCRv2] Table 6-20................ 8-9



Page: 1-1

1. Executive Summary

In this deliverable, the complete specification of the B-AMC Air/Ground (A/G) mode is provided comprising the physical layer and the Data Link Layer (DLL). In addition, a protocol approach for the B-AMC Air/Air (A/A) mode is proposed in the appendix. Standardization activities and certification issues are also addressed.

The B-AMC A/G system specification is based as much as possible on B-VHF (Broadband VHF) concepts. However, there are some adjustments at physical layer and DLL required which are due to the special L-band conditions. The main changes at the physical layer concern the duplex scheme, the Forward Link (FL) access-scheme, the Orthogonal Frequency-Division Multiplexing (OFDM) parameter set, and the physical layer framing structure.

In contrast to B-VHF where Time-Division Duplex (TDD) has been adopted, Frequency-Division Duplex (FDD) is chosen as duplex scheme. Moreover, OFDM together with packet-switched communications or Orthogonal Frequency-Division Multiple-Access (OFDMA) is chosen as FL access-scheme instead of Multi-Carrier Code-Division Multiple-Access (MC-CDMA). The access-scheme for the Reverse Link (RL) is maintained, i.e. OFDMA as proposed for B-VHF is also applied in the B-AMC RL.

The OFDM parameter set is adjusted to both the transmission channel conditions and the interference conditions which are different in the L-band compared to the VHF-band situation. Basic OFDM parameters are the available transmission bandwidth B and the sub-carrier spacing f∆ . From the simulations performed within this study it turned out

that 500 kHzB = is the largest possible transmission bandwidth which enables B-AMC to be implemented as �inlay� system between Distance Measuring Equipment (DME) channels. The sub-carrier spacing is chosen to 500 48 10.4 kHzf∆ = ≈ and 48 sub-carriers are used for B-AMC transmission. This OFDM parameter setting is optimized with respect to the channel conditions and the interference situation in the L-band.

To combat the strong interference from DME and other legacy systems in the L-band special attention has been paid to the B-AMC code design. As a result, a convolutional code applied in time direction and adapted to the expected error patterns introduced by L-band interferers concatenated with a Reed-Solomon (RS) code again applied in time direction has been selected. Simulations show that this powerful code design can almost completely combat the influence of the interference.

To achieve the highest possible data throughput, adaptive coding and modulation is proposed for B-AMC. With that, the code rate and the modulation alphabet are adapted to the current channel and interference conditions. This enables higher transmission data rates in the case where interference is only medium or weak and/or the conditions of the transmission channel are good. Under strong interference conditions the min. net information data rate at physical layer is 272 kbit/s whereas under good channel conditions and negligible interference net information data rates as high as 1.4 Mbit/s can be achieved.

In order to minimize the influence of the B-AMC system towards the legacy L-band systems sidelobe suppression techniques as developed for B-VHF are applied in the B-AMC system. This ensures to minimize the out-of-band radiation of the B-AMC system.

The high-level design of the B-AMC DLL is based on the B-VHF design, although some adjustments had to be made due to the shift from the VHF-band into the L-band. Most of these adjustments concern the medium access sub-layer (MAC) and are related to the



Page: 1-2

use of FDD instead of TDD that was used in the B-VHF design. An A/A mode is not present in the B-VHF concept, but once being adopted for the B-AMC, it required completely new medium access procedures. For these reasons the B-AMC protocol layer structure puts a stronger emphasis on clear layering to allow its components to work in varying modes over different MAC sub-layers with minimal modifications.

For the A/G MAC a deterministic resource allocation algorithm is introduced, which increases support for larger populations within a single cell and decreases latency at the same time. This is a result of the adaptation of the B-AMC frame structure. Complementary to the control mechanisms of B-VHF special control channels have been devised to accelerate medium access latency and round trip time behaviour. Special care is taken on the design of the medium access algorithm to reduce the airborne transmitter duty cycle to foster the coexistence of B-AMC with existing L-Band communication systems (e.g. DME). For the A/A medium access scheme a self-organizing ad-hoc system is developed. First simulation results show a promising behaviour.

Within the higher sub-layers of the DLL, i.e. Logical Link Control, the features of the B-VHF system are complemented with existing standards (HDLC, ISO/IEC 13239). The interfaces of the B-AMC DLL and the sub-network layer are based on existing international standards (ISO 8348) to ascertain compliance with the ATN/ISO and ATN/IPS protocol suits.

----------- END OF SECTION -----------



Page: 2-1

2. Introduction

The main objective of this deliverable is to provide a complete system specification of the B-AMC system including the physical layer as well as the relevant protocols � DLL with MAC and LLC sub-layers). Moreover, standardization activities and certification issues are addressed.

Starting point for the work related to this deliverable are the findings of deliverable D2.1 �System High Level Description� [B-AMC D2.1] and different B-VHF project documents, mainly [B-VHF D6], [B-VHF D8], [B-VHF D10], [B-VHF D18], [B-VHF D19], [B-VHF D20], [B-VHF D21], and [B-VHF D22]. Moreover, deliverable D1 �DME Spectrum Investigations� [B-AMC D1] is taking into account for the B-AMC system specification.

This deliverable is organized as follows. In Chapter 3, the detailed B-AMC physical layer specification is given including the required adjustments and adapted OFDM parameters with respect to B-VHF, coding and modulation, channel estimation and equalization, synchronization, sidelobe suppression, and physical layer framing structure. The B-AMC protocol design with focus on the required changes of the DLL compared to B-VHF is described in Chapter 4. Both the MAC sub-layer and the LLC sub-layer are specified in detail including the respective message flows and interface descriptions. The standardization activities and certification issues are addressed in Chapter 5 and Chapters 6 and 7 provide lists of references and abbreviations, respectively. Chapter 8 includes an Appendix which is used to describe in detail the protocol approach for the A/A mode. This topic is covered by an appendix since it is not part of the study, but extra work which has been performed by the consortium and might be of interest.

----------- END OF SECTION -----------



Page: 3-1

3. Physical Layer Specification

The B-AMC system offers two modes of operation, one for A/G communications and another one A/A communications. The reason for having two separate modes lies in the fact that the requirements for A/G and A/A communications are completely different which would lead to a spectrally very inefficient implementation if A/G and A/A communications are implemented in an integrated way.

Both modes are integrated into one B-AMC radio and can operate simultaneously. Since A/G and A/A mode use different frequency sub-bands within the L-band, the B-AMC radio foresees two RF branches � one for the A/G and one for the A/A mode � together with an appropriate frequency diplexer.

In the following subsections, the detailed physical layer specifications for the B-AMC A/G mode are given. The B-AMC physical layer design is based as much as possible on B-VHF concepts. However, there are some physical layer adjustments required which are due to the special L-band conditions as described below.

No detailed physical layer specifications for the A/A mode are developed within this study. For information about the physical layer high level design for the A/A mode, please refer to [B-AMC D1].

3.1. Identification of Required Adjustments

To identify the adjustments of the B-VHF physical layer components which are required to enable proper B-AMC operation in L-band both the B-VHF physical layer design has been reviewed and the L-band operation conditions differing from the VHF-band conditions have been identified. In the following subsections, the special L-band conditions and the resulting required adjustments are summarized.

3.1.1. Special L-band Conditions

Comparing the L-band to the VHF-band, several differences have to be taken into account, which are relevant to the physical layer design. The interference situation in these two bands is completely different. Whereas in the VHF-band the B-VHF system has been designed as a real overlay system with narrowband interferers contained within the receiving bandwidth, B-AMC is designed as an �inlay� system, i.e., B-AMC RF channels are foreseen to be inserted and operated between adjacent DME channels which are considered the main interference source in L-band. Thus, the center frequencies of interferers are not located within the receiving bandwidth of the B-AMC receiver, but outside, at a relatively close distance.

Nevertheless, interference will still occur from these neighboring DME channels due to the imperfect spectral masks of transmitting DME systems.

The characteristic of the DME interference is different than the interference in the VHF- band since it is more noise-like and bursty instead of narrowband and of long duration. Up to now, it is not clear how much bandwidth will be available between successive DME channels. Currently, the working hypothesis is based on the assumption to have available around 500 kHz for B-AMC transmission.

Considering L-band use, the carrier frequency is approximately 7-8 times higher than in the VHF-band. This has an effect on the free space propagation loss and on Doppler shifts due to moving airborne transmitter and/or receiver.



Page: 3-2

The intended use of the L-band within the FCI is mainly for the new data link sub-system of the Future Radio System (FRS). Voice remains a desired option, but is not necessarily required. This also affects the B-AMC system design, mainly the DLL protocol aspects, but has also impact down to the physical layer framing structure.

3.1.2. Required Adjustments

The aforementioned special L-band conditions imply that for B-AMC some mandatory adjustments compared to the B-VHF design have to be introduced.

3.1.2.1. Duplex Scheme for A/G Communication

Instead of using Time-Division Duplex (TDD) FDD is proposed for B-AMC. There are three important reasons for this choice. First, using FDD instead of TDD avoids large guard times as required for TDD due to propagation delays.

Second, the expected available B-AMC channel bandwidth between successive DME channels is relatively small which leads to a restricted transmission capacity of the B-AMC cell. Further division of this B-AMC cell capacity into FL and RL that would arise from TDD should be avoided in order to have available a reasonable amount of capacity. FDD offers the possibility to put FL and RL on two different B-AMC channels and with that offers doubled B-AMC capacity.

Third, by properly choosing the right parts of the L-band for FL and for RL the co-location interference situation at the aircraft can be significantly relieved.

3.1.2.2. Forward Link Access-scheme

Instead of using MC-CDMA for the FL access-scheme, OFDMA or pure OFDM is proposed for B-AMC FL. Note, pure OFDM is a special case of OFDMA where a single user transmits over all available OFDM sub-carriers. Using pure OFDM in the FL enables to establish packet-switched communication which is preferable when data is the primary concern and not voice. Packet-switched communications cannot be established using MC-CDMA. Moreover, OFDMA (OFDM) is much simpler and achieves performance comparable to MC-CDMA, taking into account the L-band propagation and interference conditions.

3.1.2.3. OFDM Parameters

Within L-band both the propagation conditions and the interference situation is different from the VHF-band. Due to this, the OFDM parameters as chosen for the B-VHF system have to be adjusted for B-AMC. The most important changes concern the RF bandwidth and the sub-carrier spacing what in turn influences other OFDM parameters. A detailed physical layer description including all relevant OFDM parameters is given in Section 3.2. Moreover, coding and interleaving as well as channel estimation and equalization as well as synchronization have to be reviewed and investigated if certain changes are required to ensure proper operation under the changed interference situation. These issues are addressed in Sections 3.3, 0, 3.6, respectively. The sidelobe suppression techniques as developed for B-VHF are also reviewed and relevant techniques are identified in Section 3.7.



Page: 3-3

3.1.2.4. Framing Structure

The fact that FDD is chosen for B-AMC instead of TDD and that a new set of OFDM parameters is proposed for L-band use requires a re-design of the framing structure for B-AMC. The detailed B-AMC framing structure is described in Section 3.8.

3.2. Adapted OFDM Parameter Set for B-AMC

To arrive at the final set of adapted OFDM parameters for B-AMC is an iterative process. Starting point for the physical layer design is the working hypothesis that around 500 kHz are available for each B-AMC channel (FL or RL). From this a first set of OFDM parameters is derived which is used for simulations. Simulation results might indicate that it is desirable to change this hypothesis and with that the OFDM parameters.

The most important physical layer parameter is the sub-carrier spacing f∆ , since after choosing this parameter most other parameters can be deduced in a straight forward way. The choice of the sub-carrier spacing is mainly influenced by the propagation conditions, i.e. by the coherence bandwidth of the transmission channel and the expected Doppler spread. For B-AMC the same transmission scenarios as for B-VHF are considered, namely parking, taxiing, take-off/landing, and en-route scenario [B-VHF D18]. Based on the same aircraft speeds defined for these scenarios, the maximum Doppler shift can be calculated which gives 19, 192, 537, and 997 Hz for the four scenarios, respectively. Taking into account that the en-route scenario is almost a line-of-sight communication and the relative movement between transmitter and receiver, therefore, just translates into a Doppler shift without significant Doppler spread, the Doppler frequency for the take-off/landing scenario is the worst case to be considered for the choice of the sub-carrier spacing. To be able to neglect Inter-Carrier Interference (ICI) the sub-carrier spacing should be at least 10 times larger than the worst case Doppler spread which implies that

5.4 kHzf∆ > .

Moreover, the sub-carrier spacing has to be smaller than the coherence bandwidth of the channel. The considered transmission channel all have a coherence bandwidth well above 50 kHz which leads to the conclusion that the sub-carrier spacing shall be chosen within the following borders

5.4 kHz 50 kHzf< ∆ < .

Taking into account that the out-of band radiation of an OFDM transmission signal decays the faster the smaller the sub-carrier spacing is, a large number of sub-carriers with lower spacing is preferable to avoid interference towards legacy L-band systems, like DME. Thus, the length of the Fast Fourier Transform (FFT), which is identical to the maximum number of sub-carriers supported by the system, is chosen to be 64cN = with

,used 48cN = available sub-carriers for data transmission. The remaining 16 sub-carriers

are used as 12 (6 at each side) empty guard sub-carriers and four (2 at each side) cancellation carriers, i.e. 4cancelN = . The guard bands left and right can be used for

filtering purposes and the cancellation carriers are used as in B-VHF for sidelobe suppression to reduce the out-of-band radiation of B-AMC towards other legacy L-band systems, especially DME (Distance Measuring Equipment).



Page: 3-4

With the available bandwidth of 500 kHzB = and ,used 48cN = used sub-carriers the sub-

carrier spacing f∆ results in

500 kHz 10.416 kHz48

f∆ = = .

From the choice for the sub-carrier spacing f∆ the OFDM symbol duration oT directly

follows, since

1 96 µsoTf

= =∆

is valid. In order to avoid Inter-Symbol Interference (ISI) a guard interval in the form of a cyclic prefix is introduced. The guard interval duration gT is chosen to be

24 µsgT =

resulting in an overall OFDM symbol duration ogT including the guard interval of

120 µsog o gT T T= + = .

With 20% of the overall OFDM symbol duration the guard interval is relatively long. The reason for this choice is that the guard interval fulfills two tasks. One half of the guard interval is used as �classical� guard time to avoid ISI of successive OFDM symbols. The other half is used to enable transmit windowing based on a raised-cosine window with roll-off factor 0.1α = . Note, transmit windowing further decreases out-of-band radiation as already has been proven within B-VHF.

Several OFDM symbols are grouped together to built an OFDM frame. Part of the OFDM symbols within an OFDM frame is used for synchronization, part is used for channel estimation, but most of the OFDM symbols carry data. For B-AMC the number sN of

OFDM symbols to be grouped into a standard OFDM frame is

54sN = .

With that the duration fT of an OFDM frame is

6.48 msf s ogT N T= ⋅ = .

For synchronization two symbols at the beginning of each OFDM frame are used. Strictly speaking, the second synchronization symbol is a combined synchronization and pilot symbol which is also used for channel estimation. Other pilot symbols for channel estimation are chosen with pilot symbol distances according to the worst expected change rate of the channel in time and frequency direction. For the considered propagation channels this yields pilot symbol spacing in time tN and frequency fN

direction of

2, 13f tN N≤ ≤

according to the sampling theorem with two times over-sampling. The proposed choices for the pilot spacing are 1fN = and 12tN = .



Page: 3-5

Based on this reasoning, the main OFDM parameters for B-AMC are specified. As a summary, the resulting standard OFDM frame (FL) is shown in Figure 3-1 and the OFDM parameters are giving in Table 3-1.

Figure 3-1: Standard B-AMC OFDM frame (FL).

Channel bandwidth 500 kHzB =

Length of FFT 64cN =

Number of used sub-carriers ,used 48cN =

Number of CC 2 2 4cancelN = ⋅ =

Sub-carrier spacing 10.416 kHzf∆ =

Overall OFDM symbol duration 120 µsogT =

Guard interval duration 24 µsgT =

Combined sync/pilot symbol

Sync symbol Pilot symbol

Cancellation Carriers

f

t




f

t

f

t



Page: 3-6

Number of OFDM symbols per OFDM FL/RL data frame 54sN =

FL/RL OFDM frame duration 6.48 msfT =

Pilot spacing in time direction 1fN =

Pilot spacing in frequency direction 12tN =

Table 3-1: Main OFDM parameters for B-AMC.

3.3. Adaptive Coding and Modulation

Like in B-VHF, adaptive coding and modulation is used for B-AMC. Depending on the channel and interference conditions variable coding rates and modulation alphabets are applied to create the B-AMC transmit signal. The coding and modulation type chosen at the transmitter is signalled to the receiver in order to decode and demodulate in a correct manner.

It is expected that in the case of strong interference from other legacy systems, like DME and/or JTIDS/MIDS (Joint Tactical Information Distribution System / Multifunctional Information Distribution System), a very strong coding scheme has to be applied in order to overcome this interference. As shown in Section 3.4, code concatenation based on an inner convolutional and an outer RS block code with code rates RCC=0.5 and RBC=0.9, respectively, is required to combat interference. Moreover, a robust modulation technique, like QPSK (Quadrature Phase Shift Keying), is applied in this case.

However, in interference-friendly environments coding can be relaxed and higher-order modulation alphabets can be applied. If interference is weak (negligible), only the channel influence and AWGN has to be considered. Depending on the actual channel condition coding and modulation are adapted in order to achieve the highest transmission efficiency in terms of data throughput possible under the given channel conditions. For weak interference conditions RS coding is dropped and convolutional coding with rates RCC = 1/2, 2/3, 3/4, 1 together with QPSK, 8-PSK, 16-QAM, and 64-QAM modulation is applied as also proposed for B-VHF.

In Table 3-2, an overview of the valid combinations for adaptive coding and modulation within B-AMC is given together with an indication for which cases the respective combinations are applied. The abbreviations read: S = strong, M = medium, W = weak, G = good, B = bad, INT = interference, CH = channel. Note, in contrast to B-VHF it is not foreseen to have no coding at all.

In Table 3-3, the corresponding net information data rates at physical layer are summarized. In this calculation all synchronization and pilot symbols as well as all signalling information have been taken into account and subtracted from the number of bits available for information transmission. Moreover, all guard times have been considered. Thus, Table 3-3 represents the real net information data rate at physical layer. The colour code from Table 3-2 has been adopted for this table to indicate which data rates are achievable under which interference and channel conditions. The minimum net information data rate under strong interference and bad channel conditions is 272 kbit/s. This data rate increases as high as approximately 1.4 Mbit/s under weak interference and good channel conditions.



Page: 3-7

NOTE: The data rates given are approximate figures due to the fact that the RS code is adjusted to the packet size used. Thus, the RS coding rate might vary slightly around 0.9 and with that the total coding rate might vary slightly around 0.45.

NOTE: These data rates are the data rates which are provided by a single B-AMC channel, either FL or RL.

NOTE: The data rate in RL is slightly smaller (~11%) than in FL because the RL has available only 7 instead of 8 data slots.

Faltungs-code

RCC = 1/2 RCC = 2/3 RCC = 3/4 RCC = 1

RS code 0.9 1 0.9 1 0.9 1 0.9 1

QPSK S INT G/B CH

W INT B CH

M INT G/B CH

W INT B CH

M INT G/B CH

W INT B CH

8-PSK W INT B CH

W INT M CH

W INT M CH

16-QAM W INT M CH

W INT M CH

W INT G CH

64-QAM W INT G C

W INT G C

W INT G CH

Table 3-2: Application of adaptive coding and modulation in dependence of interference and channel conditions.

Conv. code

RCC = 1/2 RCC = 2/3 RCC = 3/4 RCC = 1

RS code 0.9 1 0.9 1 0.9 1 0.9 1

QPSK 272.16 kbit/s

302.4 kbit/s

362.88 kbit/s

403.2 kbit/s

408.24 kbit/s

453.6 kbit/s

8-PSK 453.6 kbit/s

604.8 kbit/s

680.4 kbit/s

16-QAM 604.8 kbit/s

809.4 kbit/s

907.2 kbit/s

64-QAM 907.2 kbit/s

1209.6 kbit/s

1360.8 kbit/s

Table 3-3: Achievable net information data rates with adaptive coding and modulation.

The main aim of this study is to show if and how the B-AMC system can co-exist with the legacy systems in L-band, especially DME, if B-AMC channels are put in between the DME channel assignments. For this reason it is of special interest to design coding for the case of strong interference. Within this study, the detailed code design is restricted to the case where strong interference is present. In the following section, the detailed coding design for an environment characterized by strong interference is described based on QPSK modulation.



Page: 3-8

3.4. Code Design for Strong Interference

Coding for B-AMC is chosen considering the difficult interference situation. Assuming that a worst case interferer has a duty cycle of 3600 ppps, a scenario with 15 to 20 destroyed symbols within one OFDM frame is regarded. Since one interferer may destroy 2 subsequent symbols and with a high duty cycle the next interfering signal may succeed after one or two symbols, a powerful convolutional code should be chosen. Since a convolutional code is not suitable for burst error, it should be set orthogonally to the burst errors caused by DME as presented in Figure 3-2.

Figure 3-2: Convolutional code within one frame.

If a convolutional decoder makes a wrong decision, it will produce an error burst and therefore, an additional block code will be used for correction of burst errors, as presented in Figure 3-3. Thus, in a basic approach a code concatenation of an inner convolutional and an outer block code, as given in Figure 3-4, will be used.

Figure 3-3: Error correction principle.

errors can be corrected by BC-decoder

afte

r CC

-dec

oder

awgndme

afte

r cha

nnel errors can be

corrected by BC-decoder

afte

r CC

-dec

oder

awgndme

afte

r cha

nnel

f

t



Page: 3-9

Since the interference can be assumed to be quite regular, an interleaving between the two codes would group the erroneous symbols instead of spreading them and thus, it will be omitted in this system design. For the same reason, an interleaving within each column of one frame would be inappropriate. Thus, the time diversity is given only by the memory of the codes. To combat a possible frequency selective fading a separate random interleaving within each row of one OFDM frame can be considered. The block diagram of the system is given in Figure 3-4. Thus, both the inner and the outer code are applied here in the PHY-layer. An additional Cyclic Redundancy Check (CRC) code may be added at DLL.

Figure 3-4: Block diagram of B-AMC system.

Different codes may be chosen for different frame types, depending on the size of the coded data packet. A standard OFDM frame consists of 12 zero-, 4 cancellation- and 48 data carriers, 2 synchronisation, 4 pilot and 48 OFDM data symbols. A coded data packet contains then N=2304 QPSK symbols. In RL, an OFDMA frame can be divided into groups of 3n carriers, with n=1,2, � ,16, yielding the coded packet sizes of

N=2304 (48 x 48)

N=1152 (24 x 48)

N=576 (12 x 48)

N=288 (6 x 48)

N=144 (3 x 48)

QPSK symbols. Furthermore, there are two BC sub-frame types with the total coded data packet sizes of N=576 and N=1056. Special attention should be paid to the coding of the RA frame. This task will be regarded separately.

3.4.1. Outer Code Design

For the outer code Reed Solomon codes RSq(no,k) from the Galois field GF(2m) are used. In the code notation, no is the code length given in number of symbols of q=2m bits, with no≤2q-1. With k information q-bit symbols at the encoder input the code rate is

RBC = k / no,

and the minimum distance is given as d= no-k+1. By using the codes from GF(q=2m), one code is capable of correcting

(c1, c2,�,cN)outer code inner code row-

interleaver

data from DLL

QPSK

noiseDME interferer

(i1, i2,�,iNI)

++channel

(c1, c2,�,cN)outer code inner code row-

interleaver

data from DLL

QPSK

noiseDME interferer

(i1, i2,�,iNI)

++ ++++channel



Page: 3-10

⎢ ⎥⎢ ⎥⎣ ⎦d-1

F =2

erroneous q-bit symbols or 2F erasures. One code word is then written column-wise in one OFDM frame.

3.4.2. Inner Code Design

The data sequence at the output of the outer code is then coded by a convolutional code, in general given by a generator matrix G or by generator polynomials (g1,g2,�,gn), the code rate

RCC = ki/n ,

and the code memory m × ki or the constraint length L=(m+1) × ki. Here, ki is the number of bits entering jointly the convolutional encoder and resulting in n codebits at its output.

The memory and thus, the constraint length determines the size of the trellis and hence, the complexity of the decoder and consequently the processing time. There are 2m×k states in the trellis. However, since a code with a larger memory implies more time diversity, its performance is expected to be better especially in the considered interference situation.

Beside the memory and the code rate, the performance of a convolutional code will depend on the free distance df and on the active distance df of the code. Table 3-4 lists the parameters for considered inner codes. A convolutional code is capable of correcting

FC=1

2

−⎢ ⎥⎢ ⎥⎣ ⎦

df

adjacent errors, where df is the free distance of the code. To detect a data despite frequently occurring interference, a low rate code would be needed. For correction of

≥cF 3 subsequent errors the code rate should be RCC≤1/2. There also exist convolutional

codes with rate 4/5 and 3/4 which are not listen in Table 3-4. They have a free distance df ≤4 and are capable of correcting only 1 error. Therefore, their performance will not be sufficient considering the DME interference and thus, these codes will not be regarded any further.

Used code notation

g G Rcc L m df Fc

CC1 (5,7) 101111⎛ ⎞⎜ ⎟⎝ ⎠

1/2 3 2 5 2

CC2 (23,35) 1001111101⎛ ⎞⎜ ⎟⎝ ⎠

1/2 5 4 7 3

CC3 (27,75,72)

010111111101111010

⎛ ⎞⎜ ⎟⎜ ⎟⎜ ⎟⎝ ⎠

2/3 3×2 2×2 5 2



Page: 3-11

CC4 (236,155,337)

001011110001101101011011111

⎛ ⎞⎜ ⎟⎜ ⎟⎜ ⎟⎝ ⎠

2/3 5×2 4×2 6 2

CC5 (133,171) 10110111111001⎛ ⎞⎜ ⎟⎝ ⎠

1/2 7 6 10 4

CC6 (13,15,17)

101111011111

⎛ ⎞⎜ ⎟⎜ ⎟⎜ ⎟⎝ ⎠

1/3 4 3 10 4

CC7 (27,71,52,65,57)

010111111001101010110101101111

⎛ ⎞⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎝ ⎠

2/5 3×2 2×2 10 4

CC8 (247,366,171,266,373)

0110011111110110011110011011011011111011

⎛ ⎞⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎝ ⎠

2/5 4×2 3×2 10 4

CC9 (35,23,75,61,47)

011101010011111101110001100111

⎛ ⎞⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎜ ⎟⎝ ⎠

3/5 2×3 1×3 5 2

Table 3-4: A choice of convolutional codes.

Furthermore, the performance of a convolutional code also depends on its active distance profile.

The codes given in Table 3-4 are capable of correcting 2 to 4 successive bit-errors. In addition, such error couples or triples can occur frequently and be corrected all the same. The number of errors which can be corrected within one �erroneous segment�, composed of erroneous and correct bits, is determined by the active distance:

A convolutional code with a memory m × ki can correct all error patterns e[t1,t2) that corresponds to incorrect segments between any two correct states σt1 and σt2 and satisfy [HJZZ99]

e[t1+k,t2+i+1)< da(i-k) /2 for ≤ ≤ ≤ ≤2 1 2 10 k t - t -m-1 and k+m i t - t -1.



Page: 3-12

Here1, da(i-k) is the active distance of the code, given by

daj=minS {wt(c[0,j])},

with minimum built over all state sequences S which start at depth t1=0 in state �0� and end at depth t2=j+1 at state �0�. wt( ) represents the hamming weight of the code sequence c.

Since the active distance grows with the decoder depth, an important code characteristic is the slope of the active distance profile. Figure 3-5 shows the growth of the active distance versus the actual (trellis) depth j, for all codes listed in Table 3-4.

0 50 100 150 200 250 300 350 400 450 500

10

20

30

40

50

60

70

80

90

100

110

depth

aciv

e di

stan

ce

CC1, R=1/2, L=3, df=5

CC2, R=1/2, L=5, df=7

CC3, R=2/3, L=6, df=5

CC4, R=2/3, L=10, df=6

CC5, R=1/2, L=7, df=10

CC6, R=1/3, L=4, df=10

CC7, R=2/5, L=6, df=10

CC8, R=2/5, L=8, df=10

CC9, R=3/5, L=6, df=5

Figure 3-5: Active distances of convolutional codes listed in Table 3-4 with depth given in number of codebits.

According to Figure 3-5 CC1 code shows better active distance properties than other two codes with rate R=1/2, despite smaller free distance. With 22=4, this code has also less number of states in trellis and thus, lower complexity in comparison with CC2 with 24=16 and CC5 with 26=64 states. However, CC5 code especially profits from its larger memory. The performance of CC1 and CC5 is compared in the next Section.

1 In equations, k stands for ki.



Page: 3-13

3.4.3. Code Performance

In order to determine the codes for B-AMC system the performance of the different codes should be evaluated for three different cases:

1. Currently considered case is based on an assumption that the high power interfering signal can be detected at the receiver input and the corresponding symbols within one frame can be replaced by erasures.

2. Assuming the interfering signal to be detected and filtered, the carriers in the middle of one frame are left unchanged (according to the expected filter output) and only the data symbols on the outer carriers are regarded as an erasure at the inner decoder input.

3. The filtered interfering signal is considered in simulations. Thus, a part of the data symbols at the decoder input will be altered, providing probably high degradation in the decoder performance especially in case of high interfering duty cycle.

Figure 3-6: Exemplarily bit and byte error pattern at the convolutional decoder output for CC1 and CC5 at Eb/N0=5 dB.

0 10 20 30 40

0

5

10

15

20

25

30

35

40

45

50

55

carrier nr

sym

bol n

r

CC5 and CC1, R = 1/2, SNR = 5 dB

0 50 100 150 200 250 3000

2

4

byte nr

erro

r nr

CC5; #erroneousbytes = 7 of 323CC1; #erroneousbytes = 10 of 323



Page: 3-14

Figure 3-7: Exemplarily bit and byte error pattern at the inner decoder output for CC3 at Eb/N0=15 dB.

If destroyed symbols can be detected, the number of errors which can be corrected by a convolutional code increases.

In Figure 3-6 - Figure 3-9 an example of the performances of different convolutional codes within one frame with 19 of 54 deleted OFDM symbols is shown. The lines with present erased OFDM symbols, red or blues circles the errors after CC decoder. The same erasure vector is used for all codes; an en-route channel and the Additive White Gaussian Noise (AWGN) are generated randomly. Instead of adding the interference power at the Rx input, the reliability of the affected symbols is set to zero, i.e. for the corresponding codebits holds

n

n

P(c =1)log =0

P(c =0).

While CC1 and CC5 perform well at 5 dB (no errors have been obtained in this example for Eb/N0=10 dB) the performance of CC3 and CC4 with the code rate of RCC =2/3 is insufficient even at 15 dB.



Page: 3-15

The performance obtained with CC9 is rather better. However, to correct the remaining byte errors at 15 dB a block code with a rate of ca RBC =0.7 is needed yielding a total rate of R=RBCáRCC =0.42.

0 10 20 30 40

0

5

10

15

20

25

30

35

40

45

50

55

carrier nr

sym

bol n

r

CC4, R = 2/3 , SNR =15 dB, #erroneousbytes=138 of 431

0 50 100 150 200 250 300 350 4000

4

8

byte nr

erro

r nr


In case of codes with the rate RCC =1/2, the remaining byte errors could be corrected already by a block code with a rate of RBC =0.9 and thus, the total rate would be 0.45.

Therefore, CC5 code is chosen for the inner code in the current system design. Additional simulations are needed to evaluate the performance of the system.

Depending on the size of coded data block, different Reed Solomon codes are proposed for different frames in Table 3-5. Further on, the performance of the concatenation should be proved by simulations. Especially the performance of shorter RS codes for smaller frame sizes should be compared with a performance of a lower-rate convolutional code alone.



Page: 3-16

0 10 20 30 40

0

5

10

15

20

25

30

35

40

45

50

carrier nr

sym

bol n

r

CC9, R= 3/5, SNR = 15 dB, #erroneousbytes = 47 of 359

0 50 100 150 200 250 300 3500

2

4

byte nr

erro

r nr


coded packet size N

for RCC =0.5

block code (length in symbols)

block code (length in bits)

F × q bits

total rate

2 x 2304 RS16(143,128) RS(2288,2048) 7 x 16 0,44

2 x 1152 RS8(143,128) RS(1144,1024) 7 x 8 0,44

2 x 576 RS8(71,64) RS(568,512) 3 x 8 0,44

2 x 288 RS8(35,31) RS(280,248) 2 x 8 0,43

2 x 144 RS8(17,15) RS(136,120) 1 x 8 0.41

2 x 1056 RS8(131,118) RS(1048,944) 6 x 8 0.44

Table 3-5: Block codes for different coded packet sizes.



Page: 3-17

3.4.4. Additional Code Performance Improvement

The B-AMC code performance can be further improved by using a �soft� inner decoder which provides also the reliabilities for the RS-coded bytes to the outer decoder. By defining the unreliable bytes as erasures, the outer code would be capable of correcting 2F erroneous bytes. It is recommended to use this �soft� information within the final B-AMC system.

3.5. Channel Estimation and Equalization

As in B-VHF, channel estimation is based on pilot symbols. The distances of the pilot symbols in time and in frequency direction are chosen in accordance with the sampling theorem as described in Section 3.2. As a result, for the time distance of pilot symbols

12tN = and for the frequency distance 1fN = is chosen. In Figure 3-10, the most simple

(standard) pilot symbol structure for a standard B-AMC data frame is shown, where pilot symbols are grouped within a complete OFDM symbol.

Figure 3-10: Most simple pilot symbol structure and DME interference impact.

However, considering that DME interference is of short duration but broadband as also indicated in Figure 3-10 (red color), a different pilot symbol arrangement appears to be more appropriate, since one DME interferer might destroy a complete OFDM symbol and




f

t




f

t

f

t



Page: 3-18

with that all pilot symbols included. Thus, it is more appropriate to spread pilot symbols over time as shown in Figure 3-11. With that pilot symbol setting only a few pilot symbols are influenced by a DME interferer and channel estimation performance is improved.

Figure 3-11: B-AMC pilot symbol structure adjusted to DME interference.

3.6. Synchronization

As in B-VHF, the Schmidl & Cox algorithm [SC97] is proposed for synchronization. The reasoning for this choice is based on the fact that this algorithm implements a maximum likelihood solution for the OFDM synchronization problem and, thus, has optimum performance under interference free conditions. Moreover, investigations within B-VHF already indicated that this algorithm is very robust against interference. Since the type of interference is different for B-AMC in L-band than for B-VHF in VHF-band, further investigations should be performed on this issue outside this study. Detailed simulations for investigating the synchronisation are out of the scope of this study. However, a brief review of the impact of DME interference on synchronization has been carried out.




f

t




f

t

f

t



Page: 3-19

As the synchronization symbols are complete OFDM symbols it might happen that a DME interferer influences the whole synchronization symbol. This effect is similar to the impact on pilot symbols if the most simple (standard) pilot symbol structure is used as described in the previous section. The interference conditions, especially the interference power, under which synchronization is still possible, would be a topic for further investigations. However, it is assumed that synchronization can be maintained even in the presence of DME interference. This assumption is based on the fact that even under worst case DME interference not all OFDM symbols are influenced and with that synchronization symbols are not influenced all the time. Moreover, performing an explicit synchronization is not required for each OFDM frame, since changes in timing and frequency between OFDM frames are small. For example, assuming an aircraft flying at a speed of 1000 km/h, this aircraft moves only 1.8 m within one OFDM frame duration of

6.48 msfT = . Thus, the maximum change in timing is only 0.6 µs which is well below the

duration 24 µsgT = of the OFDM guard interval. Note that time synchronization in OFDM

systems requires only the accuracy of the guard interval. Keeping this in mind, synchronization can be maintained even if the synchronization symbol is not detected, since it is possible to resort to free running synchronization.

Figure 3-12: Standard Schmidl & Cox synchronization symbol structure (upper part) and proposed synchronization symbol structure (lower part) for improved performance under

impact of DME interference.

In addition to this, special countermeasures can be introduced to improve synchronization, if required. For example, it is possible to use the two synchronization symbols in a slightly different way than proposed for the Schmidl & Cox algorithm. As shown in Figure 3-12, the second synchronization symbol (blue) is changed from having modulation symbols on each sub-carrier (upper part of figure) to have only every second sub-carrier modulated (lower part of figure) like the first synchronization symbol (light blue). Within the new synchronization symbol structure both synchronization symbols (dark blue) have the same structure � only offset by one sub-carrier. The important characteristic of the synchronization symbol structure for performing time synchronization is that every second sub-carrier is left unmodulated (white) whereas the other sub-carriers carry specific modulation symbols. This ensures that the time domain signal consists of two identical halves, a fact which can well be exploited to perform time synchronization by correlation [SC97] Using two synchronization symbols with this characteristic enables two chances to synchronize in time. This is sufficient, since it is not possible to have two consecutive OFDM symbols influenced by one DME interferer and two or more strong DME interferers are not seen within the receiving bandwidth

Sync symbol 2 (old)Sync symbol 1 (old)

f

t

f

t

Sync symbols (new)

Sync symbol 2 (old)Sync symbol 1 (old)

f

t

f

t

f

t

f

t

Sync symbols (new)



Page: 3-20

simultaneously. Using two different signature sequences on the two synchronization symbols allows to discriminate which OFDM symbol achieved successful time synchronization and with that the OFDM frame is synchronized in time and can also be fine-tuned in frequency. The original second synchronization symbol (blue) shown in Figure 3-12 is actually only required if the frequency offset is larger then 0.5 f± ∆ which

is very unlikely for B-AMC, since 10.416 kHzf∆ = and the maximum Doppler shift (enroute, A/A) is below 2 kHz. But even this frequency correction is still possible with the new synchronization symbol structure by slightly adjusting the Schmidl & Cox algorithm.

3.7. Sidelobe Suppression Techniques

Within B-VHF, sidelobe suppression techniques have proven to be a valuable means to enable co-existence of different aeronautical systems in the VHF-band, since they are capable of significantly reducing out-of-band radiation of an OFDM based communications system. Based on the B-VHF design, the combination of two powerful sidelobe suppression techniques is retained for B-AMC.

The sidelobe suppression techniques proposed for B-AMC are the cancellation carriers technique and transmit signal windowing. These techniques have proven to be the most effective within B-VHF and can be transferred one-to-one from the VHF-band to the L-band without requiring any specific adjustments.

The cancellation carriers are foreseen in the physical layer design, see e.g. Figure 3-1. As in B-VHF, two cancellation carriers at each side of the transmit spectrum are proposed for B-AMC, i.e. 4cancelN = .

For B-AMC transmit signal windowing an enlarged OFDM symbol duration has to be considered, just like in B-VHF. As shown in Section 3.2, the chosen guard interval duration of 24 µsgT = already includes additional time for transmit signal windowing with

a raised cosine window with roll-off factor 0.1α = .

The sidelobe suppression capabilities of the chosen techniques are illustrated in Figure 3-13. For the chosen B-AMC OFDM parameters the out-of-band radiation is reduced by 16 dB in the frequency range from 271 kHz until 333 kHz measured from the center frequency of the B-AMC transmit signal. Note, the x-axis is normalized with the sub-

carrier spacing 10.416 kHzf∆ = .



Page: 3-21

Figure 3-13: Sidelobe suppression capabilities of cancellation carriers technique combined with transmit signal windowing.



Page: 3-22

3.8. Physical Layer Frame Structure

The B-AMC physical layer framing structure is hierarchically arranged. In Figure 3-14, this framing structure is summarized graphically, from the Super-Frame (SF) down to the OFDM frames.

Figure 3-14: B-AMC physical layer framing structure.

The smallest unit for both FL and RL is the OFDM frame which serves as a transmission container for different kinds of information. On the RL one frame may be shared by multiple aircraft using OFDMA. Both FL and RL OFDM frames include pilot symbols. Additionally, FL OFDM frames include synchronization symbols. As payload, OFDM frames contain either signalling information (OFDM signalling frames) or user data (OFDM data frames). Although FL and RL differ slightly, since for RL transmission no synchronization symbols are required, both OFDM frames consist of 54sN = OFDM symbols and,

therefore, have the same frame duration which is equal to 6.48 msfT = .

OFDM signalling frames are special frames that do not carry user information. Instead, these frames are used to transmit dedicated control information to specific users, broadcast common control information to all users, or to allow aircraft to access the communications medium for announcing transmission requests, respectively.

The following types of dedicated OFDM signalling frames exist:

! Broadcast (BC) frame � control information is broadcast to all users (FL)

! Random Access (RA) frame � all users send their net entry requests (RL)

BC and RA signalling frames have a specific internal structure. Additionally, under MAC sub-layer control, some data frames can be sent in slots dedicated to the transfer of signalling information:

! Dedicated Control (DC) slot � control information is sent by a specific user (RL)

! Common Control (CC) slot � control information is sent to a specific user (FL)

Multiframe 1(58,32 ms)




RA

Superframe (240 ms)

6,72 ms

RA 1 RA 2 DC

Data SA

Data

Data

Data

Data

Data

Data DCData SA

Data

Data

Data

Data

Data

Data





BC

BC CC

Data

Data

Data

Data

Data

Data

Data

Data CC

Data

Data

Data

Data

Data

Data

Data

Data FL

RL





RA Multiframe 1

(58,32 ms)Multiframe 2(58,32 ms)



RA

Superframe (240 ms)Superframe (240 ms)

6,72 ms6,72 ms

RA 1 RA 2 RA 1 RA 2 DC

Data SA

Data

Data

Data

Data

Data

DataDC

Data SA

Data

Data

Data

Data

Data

Data DCData SA

Data

Data

Data

Data

Data

DataDCData SA

Data

Data

Data

Data

Data

Data





BC Multiframe 1

(58,32 ms)Multiframe 2(58,32 ms)



BC

BC CC

Data

Data

Data

Data

Data

Data

Data

DataCC

Data

Data

Data

Data

Data

Data

Data

Data CC

Data

Data

Data

Data

Data

Data

Data

DataCC

Data

Data

Data

Data

Data

Data

Data

Data FL

RL



Page: 3-23

BC

BC Sub-frame 3

1,80 ms (15 OFDM symbols)

BC Sub-frame 2


BC Sub-frame 1


11 xData

Symbol

Pilot Symbol

11 xData

Symbol

Sync Symbol

Pilot Symbol

Pilot Symbol

Sync Symbol

12 xData

Symbol

Pilot Symbol

Pilot Symbol

BC

BC Sub-frame 3


BC Sub-frame 2


BC Sub-frame 1


11 xData

Symbol

Pilot Symbol

11 xData

Symbol

Sync Symbol

Pilot Symbol

Pilot Symbol

Sync Symbol

12 xData

Symbol

Pilot Symbol

Pilot Symbol

! Synchronized Access (SA) slot � all users send their reservation requests (RL)

Basically, data frames transmitted in DC, CC and SA slots have an identical structure as other FL/RL data frames and can not be distinguished from other data frames in the physical layer. The Medium Access Control (MAC) sub-layer decides about the usage (user data or signalling information) and position of data frames within the multi-frame. The position and usage of the RA and BC frames is fixed.

Figure 3-15: Detailed BC frame structure containing three sub-frames.

A BC frame consists of 56sN = OFDM symbols and, therefore, has a frame duration

equal to 6.72 msBCT = . In Figure 3-15, the detailed BC frame structure is shown. It can

be seen that the BC frame is subdivided into 3 BC sub-frames with BC sub-frame 1 and BC sub-frame 3 being identical. These two BC sub-frames have duration of 1 1.8 msBCST =

and contain 15 OFDM symbols of which 12 carry data. These BC sub-frames are used for broadcasting general Ground Station (GS) information to aircraft within the respective B-AMC cell. BC sub-frame 2 is built out of 26 OFDM symbols and has duration of

2 3.12 msBCST = . This sub-frame contains special GS information for aircraft outside the

cell but listening to this GS in order to prepare for a B-AMC cell handover. Using the middle sub-frame for this purpose ensures that enough time is available for the aircraft outside the B-AMC cell to change to the respective center frequency for listening to BC sub-frame 2. Moreover, sub-frames 1 and 3 act as guard time to account for the different propagation delays on the one hand side between the aircraft and its assigned GS and on the other hand side between the aircraft and the GS it wants to listen to during the BC frame. The RA frame is used in RL and enables net entry to newly arriving aircraft. Two RA frames appear within the RA slot. The duration of the RA slot is the same as that for the BC frame duration, i.e. 6.72 msRA BCT T= = . The RA slot in the RL is transmitted at

the same position as the BC frame in the FL. In Figure 3-16, the detailed RA slot structure is shown. The RA slot contains two RA opportunities � RA opportunity 1 and RA opportunity 2 � each having the same duration of 2 3.36 msRAT = . Each RA opportunity

consists of an RA frame of duration 840 µs and respective guard times of altogether 2.56 ms. The RA frame itself contains four OFDM symbols for data transmission. The OFDM symbols within the RA frame only use 18 sub-carriers, since 72 data symbols are sufficient for performing RA. With that, power and out-of-band radiation for the RA slot is decreased.



Page: 3-24

Figure 3-16: RA slot structure with two RA opportunities.

B-AMC FL and RL OFDM frames are grouped together to build a Multi-Frame (MF) with a duration of 58.32 msMFT = . Both FL and RL MFs comprise nine data frames. On RL, two

data frames with signalling information are transmitted in two signalling slots (SA and DC in Figure 3-14), seven data frames with user information in the remaining data slots. On FL, eight data frames with user information are transmitted in eight data slots, one data frame with signalling information is transmitted in the signalling slot (CC in Figure 3-14).

In FL, 4 MFs together with one BC frame form an SF of duration 240 msSFT = . The SF in

RL has the same duration as the FL SF, consisting of 4 MFs supplemented by one RA slot.

Finally, 25 SFs form a Hyper-Frame (HF) which has a duration of 6 sHFT = . The HF has

no special relevance at physical layer. It is only introduced to have a frame duration which is an integer multiple of 1 s to enable the possible use of a global timing reference, e.g. based on GPS (Global Positioning System) or Galileo. Note, this timing reference is not a requirement for B-AMC A/G communication. The B-AMC A/G mode is designed to work properly without any global timing.

Detailed information as well as a graphical illustration of the different OFDM frames is given in the following figures.

Figure 3-1 shows the FL OFDM frame of length 54sN = containing data symbols,

synchronization symbols, pilot symbols, and cancellation carriers.

Figure 3-17 shows the RL OFDM frame of length 54sN = containing data symbols, pilot

symbols, and cancellation carriers. Since no synchronization symbol is required in RL, one additional pilot symbol is introduced.

Figure 3-18 shows the BC sub-frames 1 and 3 (upper part, 12 data symbols) and the BC sub-frame 2 (lower part, 26 data symbols) containing data symbols, synchronization symbols, pilot symbols, and cancellation carriers.

Figure 3-19 shows the RA frame containing synchronization symbols, pilot symbols, data symbols and cancellation carriers.

RA Opportunity 1 RA Opportunity 2

RA Frame

3,36 ms

840 µs1,26 ms1,26 ms

RA Frame

3,36 ms

840 µs1,26 ms1,26 ms

Guard Guard

Sync Symbol

Data Symbol

Pilot Symbol

Data Symbol

Data Symbol

Data Symbol

Pilot Symbol

RA Opportunity 1 RA Opportunity 2

RA Frame

3,36 ms

840 µs1,26 ms1,26 ms

RA Frame

3,36 ms

840 µs1,26 ms1,26 ms

Guard Guard

Sync Symbol

Data Symbol

Pilot Symbol

Data Symbol

Data Symbol

Data Symbol

Pilot Symbol



Page: 3-25

f

t

Pilot symbol Cancellation Carriers

f

t

f

t

Pilot symbol Cancellation Carriers

Figure 3-17: Standard B-AMC OFDM frame (RL).



Page: 3-26

Figure 3-18: BC sub-frames 1/3 (upper part) and 2 (lower part).

Figure 3-19: RA frame.

----------- END OF SECTION ----------

f

t

f

t




f

t

f

t

f

t

f

t







f f

t




f f

t

f f f f

t t



Page: 4-1

4. Protocol Specification

The high-level design of the B-AMC data link layer is based on the B-VHF design [B-VHF D6], [B-VHF D8], although some adjustments had to be made due to the shift from the VHF-band into the L-band. Most of these adjustments concern the medium access sub-layer (MAC) and are related to the use of FDD instead of TDD that was used in the B-VHF design. The A/A mode was not present in the B-VHF concept, but once being adopted for the B-AMC, it required completely new medium access procedures. For these reasons the B-AMC protocol layer structure puts a stronger emphasis on clear layering to allow its components to work in varying modes over different MAC sub-layers with minimal modifications.

The B-AMC data link layer is directly derived from the B-VHF data link layer. It comprises two sub-layers and six major entities.

The Medium Access sub-layer described in the sections 4.1 - 4.2 comprises the B-AMC Special Services (BSS) entity and the Medium Access (MAC) entities. The BSS entity maps logical channels to transport channels. Below the BSS resides the MAC entity, which has the task to map transport channels to appropriate physical channels. Conceptually, the BSS and MAC entities constitute the medium access sub-layer.

DLS VILME

BSS

MAC A/A

A/A PHY

Logical Channels

Transport Channels

MAC A/G or

A/G PHY

Higher Layers

or

Voice

Physical Channels

Logical Link

Control Sublayer

Medium Access

Sublayer

Physical Layer

Figure 4-1: High-level structure of the B-AMC data link layer.

The inner structures of the medium access sub-layers for the A/G and A/A mode are different and therefore they are separately handled in this chapter and in chapter 8, the appendix.

The Logical Link Control (LLC) sub-layer and its entities are discussed in detail in section 4.3. The LLC sub-layer manages the radio link and offers to the higher layers connection-less transport services with different levels of Quality of Service (QoS). It is up to the LLC layer to achieve the required level of data integrity, using Automatic Repeat Request



Page: 4-2

(ARQ) and checksums, and to support priorities between QoS classes by mapping higher layer packets to appropriate logical channels. The high level data link layer (DLL) structure for B-AMC is shown in Figure 4-1.

4.1. B-AMC Medium Access Sub-Layer

The Medium Access sub-layer described in this section comprises the B-AMC Special Services (BSS) entity and the Medium Access (MAC) entities. This section provides an overview of the BSS and MAC entities and the corresponding channel structure. Details of the various protocol entities are discussed in section 4.2.

4.1.1. Communications Channels - Overview

Each of B-AMC protocol layers provides services to the layer above. The services are offered in the form of abstract �communications channels�. In the B-AMC system design, three types of such channels exist:

! Logical channels - The BSS entity of the medium access sub-layer provides data transfer services to the higher DLL entities of the LLC sub-layer (LME, DLS, Voice Interface) on logical channels. Each logical channel type is defined by what type of information is transferred. B-AMC logical channels can be classified into control channels (BCCH, RACH, SACH, DCCH, CCCH) for the transfer of control plane information and traffic channels (DCH, VCH) for the transfer of user plane information.

! Transport channels - The MAC entity provides data transfer services to the BSS entity on transport channels. Each transport channel type is defined by how the information is transferred. A set of transport channel types (TBC, TRA, T1, T2�TNc) is defined for different kinds of data transfer services. While the mapping of logical control channels to corresponding transport channels is fixed, the logical traffic channels (DCH, VCH) may be mapped onto several types of transport channels, dependent on the required bandwidth.

! Physical channels - Physical channels consist of selections of OFDM sub-carriers in a layered structure of OFDM frames that normally appear within specific time slots. While some OFDM frames (RA and BC OFDM frames) carry dedicated signalling information, others (data OFDM frames) may � as dictated by the MAC entity - carry either signalling information or user data. Physical channels are mapped to OFDM-frames by the physical layer.

Figure 4-2 shows the relationship between logical channels, transport channels and physical channels.

4.1.2. BSS Entity - Overview

The BSS entity maps logical channels to transport channels. It provides a sending and a receiving buffer for each transport channel and injects or extracts DLL-PDUs from the transport channels.

By this way, the BSS entity provides the interface between the LLC sub-layer and the different MAC entities. It is important to note that only one MAC entity type (MAC A/G or MAC A/A) is used at any time, i.e. the radio operates either in A/G or A/A mode.



Page: 4-3

Figure 4-2: B-AMC channel mapping aircraft perspective.

The role of the BSS is analogue to the B-VHF design, although with stricter adhering to layering concept. All traffic (voice, data and management) is now routed through the BSS entity. Routing voice traffic through the BSS now decouples the logical voice channels from the transport channels (as it was always the case for data traffic).

NOTE: B-VHF allowed direct interaction between the voice interface and the MAC. As voice channels were always assigned to a fixed set of sub-carriers, logical channels and transport channels coincided in that case.

Each DLL-PDU received from the LLC sub-layer is put into a BSS queue. Each queue corresponds to one transport channel. Start and end of each DLL-PDU are marked with a flag protected by byte stuffing in the queue.

Whenever the BSS is granted a transport channel by the MAC entity (using the resource acquisition mechanism described in section 4.2.2) the contents (or a part of the contents) of the transport channel queue is injected into the granted transport channel. This channel is mapped to a physical channel by the MAC entity.

4.1.3. A/G Mode MAC Entity - Overview

The B-AMC MAC entity maps transport channels to physical channels of the A/G radio link. The general idea of B-AMC A/G MAC solution is that the B-AMC FL and RL channels



Page: 4-4

(which are separated by FDD) are themselves structured in time. They contain a series of (almost) equally spaced time slots, which are managed by the algorithms of the MAC sub-layer. Each slot contains one OFDM frame carrying information of one or more transport channels.

On the RL, different aircraft may transmit simultaneously on different transport channels within the same data-frame, being separated by OFDMA. Transport channel capacity is requested by the aircraft MAC entity and is allocated by the ground-station. The resource request algorithm is contention-free (up to the specified maximum number of aircraft) as it is realized through a dedicated Synchronized Access Channel. Details are discussed in section 4.2.

4.1.4. A/A Mode MAC Entity - Overview

A/A communication between aircraft takes place in a decentralized, self-organized way within �communication bubbles� defined by the radio range of the B-AMC terminals in the A/A mode. The protocol is based on TDMA medium access. It is distributed and self-organized; no central control instance is used for resource management. For synchronization purposes, the availability of a global time reference is assumed. The B-AMC system operating in the A/A mode assumes a dedicated global �Common Control Channel� (CCC). Details are discussed in chapter 8 (appendix).

4.2. Air/Ground Medium Access Sub-Layer

From the perspective of the B-AMC medium access sub-layer, the B-AMC RL and FL are structured in time slots. These time slots contain corresponding physical layer OFDM frames (either signalling or data frames) and have a duration of either 6.72 or 6.48 ms, depending on the OFDM frame type they contain (see Figure 4-3 and Figure 4-4).

Within each slot2 (i.e. OFDM-frame) an integral number of transport channels may be allocated by the BSS. These transport channels are mapped to time slots by the MAC. Different types of transport channels (different transmission bandwidths) are realized by assigning an appropriate number of OFDM sub-carriers to each transport channel type:

! T1 transport channel uses one OFDMA sub-carrier during the slot.

! T2 transport channel uses two OFDMA sub-carriers during the slot.

! ..

! TNc,used transport channel uses all Nc,used sub-carriers during the slot.

While the MAC entity associates transport channels with time slots, the peer physical layers exchange the information pertinent to these transport channels in the form of physical OFDM (either signalling or data-) frames.

On the RL information of several transport channels can be transmitted in one OFDMA frame. Except for the RA slot, the transport channels of different users (different aircraft) are separated by OFDMA (each transport channel may be individually accessed by each aircraft). On the FL, only the TNc,used transport channel is used by the B-AMC GS, except for the BC slot.

2 With the exception of the BC/RA slots, which have different transport channel types. Slot types and framing structure are discussed in section 4.2.1.



Page: 4-5

NOTE: The transport channels of each aircraft and the GS carry addressed DLL-PDUs to allow the statistical multiplexing of several logical channels.

The constellation of sub-carriers of different RL transport channel types � actually representing bandwidth assignments over the duration of one slot � is managed by the physical layer and pre-defined (a-priori known to each B-AMC radio). This assignment of sub-carriers to the transport channels is optimised to reduce the effect of L-band interference.

The transport channels need not be defined for all n=1,2, ..,Nc,used (channel sizes not considered useful may be omitted). Table 4-1 displays exemplary transport channel definitions for Nc,used=48 carriers using the coding rates defined in Table 3-5.

NOTE: The exemplarily given values in Table 4-1 refer to the most robust transmission set-up, i.e. robust QPSK modulation, and strongest coding. Thus, the data rates given are the minimum guaranteed data rates for transmission under strong interference conditions. Considering adaptive coding and modulation considerably larger data rates are achieved (see section 3.3).

The indicated available RL user data rate is the theoretical value that could be achieved if an aircraft were assigned all RL OFDM carriers over all slots (corresponding to seven T48 transport channels per MF). The values contain MAC overhead (only DATA slots are used for calculating capacity) but do not include any LLC overhead.

Transport channels are assigned by the GS, per slot, by using the resource acquisition mechanism.

Traffic Channel Type T48 T24 T12 T6 T3QPSK Data Symbols 2304 1152 576 288 144Coding Rate 0,44 0,44 0,44 0,43 0,41Traffic Channel Capacity/slot (bits) 2027 1013 506 247 118

Data Slots per Super-Frame (FL) 32Available User Data Rate FL (kbit/s) 270,27

Data Slots per Super-Frame (RL) 28Available User Data Rate RL (kbit/s) 236,48

Super-Frame Duration (ms) 240Super-Frame Duration (slots) 37

Table 4-1: Exemplary transport channel definition for Nc,used=48, n=48,24,12,6,3.

Within the BC/RA slots two specific OFDM frame formats appear: Random Access (RA) frames and Broadcast (BC) frames. The slots for these frames have a slightly longer duration (6.72 ms) than �ordinary� slots and are only used for exchanging information required during net-entry and handover. Consequently, two additional transport channel types (TRA, TBC) have been defined that are mapped by the MAC to the RA and BC slots.

The assignment of time slots to different purposes is managed by the MAC frame structure, whereas the acquisition of transport channel resources is managed by the MAC resource allocation algorithm.



Page: 4-6

The relationship between logical channels, transport channels and physical channels (slots and OFDM frames) is displayed in Figure 4-2. Slot types � as managed by MAC - are discussed in section 4.2.1.

4.2.1. A/G MAC Frame Structure

The B-AMC medium access sub-layer uses the framed structure provided by the physical layer to build its own slotted time structure (referred to as �MAC framing�). The basic unit of the MAC framing is the multi-frame (MF). A multi-frame comprises 9 time slots (9 * 6.48 = 58.32 ms) each containing a data OFDM frame or signalling OFDM frames other than BC/RA. BC and RA OFDM frames are 6.72 ms long and appear at a super-frame- rather than multi-frame level.

On the FL the first slot (CC slot) of each multi-frame is used for the TNc,used transport channel carrying the logical Common Control Channel (CCCH). The main purpose of the CCCH is to assign RL transport channels to different aircraft.

The remaining 8 slots of the FL multi-frame are used for the transmission of the TNc,used transport channel containing the logical channels of the traffic plane (voice, data and management information). We will refer to these slots as DATA1 to DATA8 or �data slots�. In Figure 4-3 they are displayed in grey.

On the RL there are only 7 data slots and two special time slots. The SA slot is used for the logical Synchronized Access Channel (SACH). Within this slot only �low-bandwidth� T1 transport channels are used. At net entry, each aircraft is assigned one of total Nc,used available T1 transport channels (i.e. one OFDMA sub-carrier), thus the system provides each of up to Nc,used aircraft with a dedicated low bit-rate transport channel for its SACH. If the number of aircraft exceeds Nc,used, the assignment procedure described in section 4.2.2 is applied.

The DC slot has the same structure as the SA slot and is used to provide each aircraft with a dedicated low bit-rate transport channel for its logical Dedicated Control Channel (DCCH). The DCCH conveys LLC signalling information (e.g. ACKs, power measurements, etc.).

The positions of the �special� slots (CC, SA, DC) within the multi-frame have been chosen in such a way to give the radio equipment enough processing time (2-4 slot lengths ~ 12 � 25 ms).

SADC

CC

Multi-Frame

RL

FL

58.32 ms

Figure 4-3: Multi-frame structure.

After four RL multi-frames one Random Access/Broadcast slot is inserted, containing a RA-frame that carries TRA transport channel/logical Random Access Channel (RACH). Similarly, the BC-frame with TBC transport channel/logical Broadcast Channel (BCCH) is inserted on the FL (BC and RA slots coincide in time!). These channels are used during



Page: 4-7

net-entry and hand-over. One RA/BC slot and four multi-frames comprise one super-frame. The super frame has an overall length of 240 ms.

Figure 4-4: Super-frame structure.

4.2.1.1. Transfer of User Data

All transport channels of the traffic plane shown in Figure 4-2 are carried in the data slots of the multi-frame. The multiplexing of logical channels onto appropriate transport channels is done by the BSS entity, so the MAC only has to map transport channels to physical OFDM frames that appear in the appropriate time slots. It is the task of the MAC entity to identify which slots should be used for a particular transport channel. The ground-station MAC entity has the additional task to determine and manage the resource assignments for all aircraft. Once the slot of a transport channel is known, the physical layer can insert/extract the appropriate OFDM frame.

The GS is the only user of data slots on the FL, thus no particular assignment of slots is necessary. The ground-station uses only TNc,used transport channels (i.e. all OFDM sub-carriers) and its BSS multiplexes packets of multiple logical channels according to their priority to be conveyed on the same TNc,used transport channel. The BSS of an aircraft receiving these channels determines packets indented for them by inspecting their destination address.

The allocation of RL time slots and transport channels to specific aircraft is managed by the MAC entity of the ground-station. The details of how this assignment can be derived from the resource requests of the aircraft MAC entity are presented in the next section. For now we will assume that the ground-station always knows the needs of all aircraft it currently controls.

The short-term assignment of RL slots and transport channels is transmitted at the beginning of each multi-frame using the TNc,used transport channel in the CC slot containing the CCCH. The CCCH contains a �table� with transport channel/slot allocations for the next 7 data slots on the RL. The scope of the assignment (7 data slots the assignment will apply to-) is shifted four slots to the right with respect to the CC slot in order to give the radio equipment enough processing time. The table is generated by the ground-station MAC entity using the resource acquisition process.

Each table entry contains one slot/transport channel assignment. Each entry/assignment comprises the owner ID (i.e. the aircraft address), the slot ID and the type of the allocated transport channel (Figure 4-5). Each table entry denotes a transmit opportunity for one specific aircraft for a single slot and transport channel. Note that several aircraft can simultaneously transmit in the same slot, using different transport channels (i.e.

RA SADC

BC CC

Multi-Frame Multi-Frame

CC

Multi-Frame

CC

Multi-Frame

RL

FL

58.32 ms 58.32 ms 58.32 ms 58.32 ms

240.0 ms

6.72 ms

SADC SADC SADC

CC



Page: 4-8

OFDMA sub-carriers)3. One aircraft could receive more than one transport channel allocation per multi-frame, but in order to keep the RL duty cycle low the resource allocation algorithm does not assign more than one transport channel per multi-frame.

Figure 4-5: RL resource assignment via CCCH.

4.2.1.2. Transfer of Voice

The transfer of voice streams works basically the same way as the transfer of data. If the voice channel has been configured at a particular GS, the GS periodically assigns one T64 transport channel per multi-frame to the voice transport channel. The assignment can be on demand (selective voice) or permanent (party-line voice). If this allocation is not tied to a specific aircraft (i.e. party-line), the pilot has to follow the Listen-Before-PTT protocol to avoid collisions, as all registered aircraft may transmit in this transport channel. Due to the fact that all RL voice traffic is relayed on FL by the ground-station, overruling by the controller is always possible.

A voice stream uses one T6 transport channel per multi-frame (under the assumption Nc,used=48). This provides 288 bits per multi-frame. If a bigger transport channel is used, 288 bit are used to carry three 20 ms samples of the AMBE ATC-10B vocoder and the remaining bits are available for voice signalling information (e.g. priority access, Talker_ID).

The relaying mechanism of the ground-station introduces an additional delay of up to one multi-frame length (58.32 ms) on the aircraft to aircraft path. In order to fulfil the [COCRv2] PTT-squelch delay (50 ms) requirement in an air-air scenario, the RL voice

3 Actually, not only the RL transport channel type has to be assigned, but also the position of the transport channel within the OFDMA frame (an aircraft needs to exactly know which OFDM sub-carriers to use). This aspect has been ignored for simplicity here. 4 Alternatively 6 T1 (3 T2, 2 T3) transport channels in 6 (3, 2) consecutive slots of the multi-frame could be used, too. Note, that in any case only 6 of the TNc,used * 7 RL sub-carriers/slot (or TNc,used * 8 on the FL) available for user data are needed.



Page: 4-9

frame subject to relaying can be announced to the aircraft in advance, in the CCCH at the start of the MF, using a specific CCCH flag. This could be used to open the SQ of an airborne RX without having to wait for the actual voice frame to arrive. Depending on the position of the first received RL voice transport channel in the multi-frame, the PTT-squelch delay caused by the re-transmission may be variable, but even if the first RL voice frame were received in the first RL data slot, the delay would be not longer than one multi-frame length (6.48 ms � 58.32 ms).

NOTE: This figure does not include any B-AMC sub-network delay (or ground-network delay if a voice stream is relayed from one ground-station to another). However, if reasonable sub-network performance is assumed (less than 40 ms latency added by the interconnection of the ground B-AMC infrastructure) the voice requirements stated in [COCRv2] section 5.1 are met.

4.2.1.3. Transfer of Signalling Data

Each logical channel of the control plane has one permanently assigned transport channel and associated slot/OFDM signalling frame (see Figure 4-2).

The only exceptions from such permanent assignment are the DCCH and SACH which may experience re-assignment if the population of registered aircraft changes. The DC slot is used for the T1 transport channels of the DCCH which offers each aircraft a low-latency RL signalling channel which can be accessed directly, without making a resource request. Each such T1 transport channel can be individually accessed due to OFDMA, offering simultaneous dedicated access to up to Nc,used aircraft. This provides enough bandwidth for sending acknowledgments and related signalling. The Nc,used T1 transport channels that appear within the DC slot are dynamically managed/(re)assigned using the scheme described in the next section.

4.2.2. Resource Allocation for the RL

The B-AMC MAC resource allocation function manages the assignment of RL slots and transport channels to different aircraft in a contention-free manner. On the FL, no resource requests are required as the GS directly allocates FL resources and manages access priorities.

Let us assume for clarification purposes that there are exactly Nc,used aircraft registered at the ground-station. RL resource allocations are announced by the ground-station at the beginning of each multi-frame over the CCCH in the CC slot using a TNc,used transport channel. In order to be included in the assignment, each aircraft has to report its resource needs on RL to the ground-station via the SACH in its dedicated T1 transport channel in the SA slot of each multi-frame. On the basis of these reports, the GS will allocate RL resources.

In order to give the registered aircraft an opportunity to send their resource requests, each of the Nc,used users is assigned one T1 transport channel in the SA slot. This assignment is initially made during net-entry and can be changed later on. Just like in the case of the DCCH, this provides each aircraft with a small but guaranteed capacity per SA slot. After having received requests over all T1/SA channels, the ground-station computes the allocation of the transport channels and RL slots for the aircraft and announces the result in the next TNc,used/CC on the CCCH. The resource allocation is computed using the weighted fair queuing algorithm (Figure 4-6).



Page: 4-10

Figure 4-6: Resource requesting with Nc,used users.

If there are more than Nc,used registered users per GS, the resource request algorithm has to be adapted. Let us assume that there are exactly 2* Nc,used registered users. In this case we can offer each aircraft a designated access opportunity only every second SA slot � therefore, once in every second MF. This introduces the concept of the �breathing reservation cycle�. The reservation cycle is the number of multi-frames needed to give each aircraft its access opportunity. In our case, the reservation cycle has a length of two multi-frames. After the last SA slot of the reservation cycle, the ground-station computes the resource allocation for the RL of the next cycle and announces it on the CCCH during the next two CC slots (Figure 4-7).

Figure 4-7: Reservation cycle for 2 Nc,used users.

In the general case, if the number of registered aircraft is not a multiple of Nc,used, the access opportunities of the SA slots are assigned in round-robin manner. Using this scheme the average length of the reservation cycle grows linearly with the number of users and provides each aircraft with one dedicated resource request opportunity in every cycle.

( ) msNc

usersSACHtoaccessE 0.60=

The upper bound for the time to medium access5 is deterministic:

5 Strictly speaking, the medium access here represents the time from the instant a packet becomes the first one in the BSS queue to the time it is actually transmitted by the physical layer.



Page: 4-11

msNc

SACHtoaccess 0.60users⎥⎥⎤

⎢⎢⎡≤ .

Note that the average distance between two SA slots is 60.0 ms due to the RA/BC slot contained in every super-frame.

If we assume no queuing delay and that the ground-station grants the request of the aircraft within the next reservation cycle this implies an upper bound for the medium access on the RL:

msNc

RLonaccessmedium 0.60users2 ⎥⎥⎤

⎢⎢⎡≤

and the expected time for RL medium access is then

( ) msNc

usersRLonaccessmediumE 0.602= .

The average end-to-end latency for a DLL-PDU transmitted in k consecutive transport channels is then

( ) msQmsNuserskRLonlatencywayOneE k

usedc

+= 0.602,

,

where Qk is the average queuing delay experienced by the k fragments of the DLL-PDU

Although this algorithm is easily out-performed by random access schemes at low GS loading and high aircraft population, it is deterministic and it can guarantee medium access in linear time even under heavy load where stochastic access schemes experience exponentially growing delays.

4.2.3. The Role of the BSS in the Resource Allocation on the RL

At the start of each SA slot the aircraft MAC entity sends a request to the local BSS entity. The BSS entity responds by indicating the length of the BSS transport channel queues. This answer is transmitted as a resource request to the GS MAC entity over the SACH.

From the response of the ground-station MAC entity on the CCCH the aircraft MAC entity identifies the granted transport channels (if any transport channel was requested by that aircraft). The number of bits that corresponds to the granted transport channel size is then removed from the BSS sending queues and handed-over to the MAC entity which passes these data to the physical layer prior to the start of the corresponding slot. By this way the sending BSS effectively performs segmentation of �long� DLL-PDUs into �short� transport channels. The leading time with respect to the beginning of the time slot must be sufficient for the physical layer operations (e.g. coding, interleaving) over data to be transmitted.

On the receiving side the arriving data is accepted by the MAC and their content is appended to the appropriate receiving queue of the BSS. The BSS sub-layer collects the received data from the transport channels (being segments of the DLL-PDU) and constantly scans the receive queues for the start and end flags identifying a DLL-PDU. When it finds a complete DLL-PDU in the queue, the �assembled� DLL-PDU is extracted



Page: 4-12

and handed-over to the DLS sub-layer. DLL-PDUs generated by the LME are processed in an analogue way.

This is illustrated in Figure 4-8. Note that for illustrational purposes it has been assumed that the sending aircraft gets two resource allocations per multi-frame. Normally the aircraft would get only one to reduce the airborne duty cycle.

Figure 4-8: Mapping of transport channels to physical channels.

4.2.4. Additional Medium Access Performance Improvements

Due to the short time available for this study a number of highly interesting protocol improvements could not be investigated in detail. The most important points for further development are listed below:

! The use of adaptive modulation and coding could greatly improve the overall system throughput under low interference. The structure of the RL (i.e. on demand assignment of transport channels to individual aircraft) is already suitable for this. The FL would need only minor modifications to allow the use of adaptive techniques.

! The super-frame and multi-frame formats investigated in this study have been chosen to provide very good all-purpose performance. However, for special use cases alternative framing formats could be more suitable. Due to the fact that the only required periodical slot is the BC/RA slot the B-AMC medium access protocols could be easily modified to use fully dynamic multi-frame formats inside the super-frames. The basic infrastructure for this is already present as the RL layout of the next multi-frame is announced in the CCCH.

! A special (although static) case of the above item is the introduction of a �low latency� mode. In this mode the number of SA and DC slots on the RL would be increased. By this RL bandwidth can be traded for lower RL medium access latency. If, for example, the number of SA/DC slots per multi-frame were doubled, the available user data rate on the RL would drop from 236.46 kbps to 168.92 kbps (which is still three times the bandwidth required to support the RL in all scenarios defined in [EvalScen]) and the medium access times were halved (in a typical ENR Large scenario at FER=10-2 the average latency would drop from ~531 ms to ~255 ms cf. [B-AMC D5] and section 4.2.2). Alternatively, if lower latency is not required, a proportionally increased number of aircraft could be supported in the same reservation cycle.



Page: 4-13

! The deterministic medium access scheme proposed for B-AMC has been especially designed for a safety related environment. For non safety related communications alternative random access schemes could be defined. These algorithms have the benefit to provide quicker access under low loads.

! If the airborne duty cycle is not a problem (i.e. OPTN 3), the GS can grant an aircraft up to 8 DATA slots per multi-frame (instead of just one now). Although this would not greatly improve the total throughput, a significant reduction of latency could be achieved for large packets (i.e. packets so large that they require several transport channels). The overall throughput could be slightly increased by the assignment and merging of consecutive slots (i.e. if two consecutive slots are used by the same aircraft no guard times etc. are required between these slots).

4.3. B-AMC Logical Link Control Sub-Layer

The upper sub-layer of the B-AMC data link layer is the logical Link Control (LLC) sub-layer containing the Data Link Service (DLS), Voice Interface (VI) and Link Management Entity (LME) � see Figure 4-9.

The LLC design is basically the same for the A/G and A/A mode. However, not all functions are supported in both modes. This requires a separate treatment of the LLC design for the A/G and the A/A mode. The A/G mode LLC design is presented in the next sections whereas the A/A mode LLC design is treated in section 8 (appendix).

Figure 4-9: B-AMC DLL architecture in A/G mode.



Page: 4-14

4.3.1. A/G Mode LLC

In the A/G mode the B-AMC radio is configured to use the A/G MAC Entity. DLL-PDUs are generated by the LLC sub-entities and passed to the medium access sub-layer. The sub-entities of the LLC are described below.

4.3.2. DLS

The B-AMC Data Link Services entity (DLS entity) is analogue to the B-VHF DLS. It supports connectionless communication with different traffic classes (QoS). If the required integrity of a traffic class can not be achieved using only FEC in the physical layer, the DLS improves integrity using an ARQ protocol (i.e. HARQ). The logical data channel DCH is used for the transmission of user data and the DCCH channel for signalling (ACK, NAK, etc.). The selected ARQ protocol is HDLC according to ISO 13239 [ISO/IEC 13239] asynchronous balanced mode (ABM) with option 3 and 7. ABM defines the point-to-point behaviour for HDLC on asynchronous links (i.e. links where a station may send at any time). Option 3 (SREJ recovery) introduces selective reject ARQ. Option 7 (multi-octet addressing) allows the use of DLL addresses longer than one octet. This is necessary for B-AMC to allow more than 256 nodes per cell. For each QoS class one DLS instance exists.

The support for connection oriented communication has been dropped. For the details of the B-AMC DLS the B-VHF document [B-VHF D20] applies with the restrictions mentioned above.

4.3.3. LME

The B-AMC Link Management Entity (LME) very similar to the B-VHF LME. The only major difference in the design is that the resource management has been moved from LME into the MAC sub-layer. This was necessary to support the A/A mode and the A/G mode with a single LME design. The remaining LME functionality comprises the B-AMC system procedures described in the next chapter. For the details of the B-AMC LME the B-VHF document [B-VHF D21] applies with the restrictions mentioned above.

The LME uses the BCCH and RACH logical channels during net-entry. CCCH, SACH and DCCH are used for signalling.

4.3.4. Voice Interface

The Voice Interface (VI) of the B-AMC system is identical to the Voice Unit interface of B-VHF. The VI uses the logical voice channel VCH.

NOTE: The Voice Unit (vocoder) is a COTS functional block that is external to the B-AMC system, but it interfaces with the B-AMC system over a digital VI and its specifics (e.g. size of voice frames) had to be considered in the B-AMC framing structure.

4.3.5. Interface to the Upper Layers

The B-AMC interface to the upper layers is based on the B-VHF interface to the upper layers. The only major modification from the original design is that the direct support for connection oriented communication has been dropped, so that the B-AMC system offers a clean and simple connection-less interface (see Figure 4-10 and Figure 4-11).



Page: 4-15

Outgoing network layer packets are passed from the B-AMC convergence layer, which performs segmentation and reassembly, to the B-AMC sub-network and DLL. The desired traffic class (QoS) is a parameter of the interface. On the receiving side the content of received B-AMC packets is handed to the convergence layer to reconstruct network layer packets.

Besides supporting a larger MTU (Maximum Transfer Unit) size than the B-AMC sub-network can provide without fragmentation, the convergence layer supports additional functions like transparent compression and encryption.

In the ground-station the B-AMC sub-network interface is provided by the ground network interface (GNI) which provides intra- and extra-system network functionality. For the details of the B-AMC interface to the upper layers (including ground network interface (GNI) and air network interface (ANI)) the B-VHF document [B-VHF D22] applies with the restrictions mentioned above. Details are discussed in section 4.4.6.

Figure 4-10: Protocol stack showing the B-AMC interface (ATN case).

Figure 4-11: Protocol stack showing the B-AMC interface (IPS case).



Page: 4-16

4.4. Description of Protocol Message Flow and Interface

This section describes the primitives and message flows of the B-AMC data link layer and sub-net entities.

4.4.1. Primitives of the Physical Layer

The B-AMC physical layer offers the data link layer four primitives:

! PHY_DATA.ind

! PHY_DATA.req

! PHY_SETPWR.req

! PHY_SETCH.req

PHY_DATA.ind is the indication raised by the B-AMC physical layer when a complete OFDM frame has been received and decoded. It supplies two arguments.

Parameters:

" Received data

" Receive Power

Data is the decoded contents of the OFDM frame. Usually this is a fragment of a DLL layer packet. The second argument indicates the power with which the frame has been received.

PHY_DATA.req is the primitive passed from the data link layer to the physical layer to request data be sent. It takes two arguments.

Parameters:

" Data to send

" Frame type

The supplied data in the argument is coded and encapsulated in an OFDM frame of the given type by the physical layer.

PHY_SETPWR.req is the primitive passed from the data link layer to the physical layer to request the sending power be changed.

Parameters:

" Power

The new sending power is determined by the regular power measurements and adjustment algorithms of the data link layer (for protocols see [B-AMC D2.1], chapter 9).

PHY_SETCH.req is the primitive used to request the physical layer to change the tuning of the B-AMC radio. It takes the new channel as its single argument.



Page: 4-17

Parameters:

" Channel

This primitive is used for handovers between different ground stations.

4.4.2. Primitives of the MAC-Entity

The B-AMC MAC entity offers the BSS Entity five primitives for the management of medium access. Generally these are split into two primitives for resource allocation and three primitives for receiving and transmitting data.

! MAC_RR.ind

! MAC_RR.resp

! MAC_TX.ind

! MAC_TX.resp

! MAC_RX.ind

! MAC_RATX.req

! MAC_RATX.ind

! MAC_RATX.resp

! MAC_RA.ind

MAC_RR.ind is the indication raised by the MAC entity to request a resource request form the BSS. It takes no arguments. Upon receipt of this indication the BSS responds with a MAC_RR.resp response. This primitive reports the required resources (i.e. transport channels) via the BSS queue lengths to the MAC, which will insert it into the SACH channel.

Parameters:

" BSS queue lengths

Resource requests of the BSS are triggered by the MAC entity with the MAC_RR.ind indication as the BSS entity has no knowledge of the MAC framing and slot structure.

MAC_TX.ind is the indication raised by the MAC entity to indicate to the BSS that data may be sent. It single argument is the capacity of the granted transport channel.

Parameters:

" Transport channel capacity

The BSS responds to this indication with a MAC_TX.resp, which takes an appropriate amount of data as argument.

Parameters:

" Data to send

Data transmissions of the BSS are triggered by the MAC entity with the MAC_TX.ind indication as the BSS entity has no knowledge of the MAC framing and slot structure.



Page: 4-18

Whenever the physical layer has indicated the reception of a new OFDM frame to the MAC entity the MAC_RX.ind indication is passed to the BSS. Its argument carries the received data.

Parameters:

" Received Data

The RA primitives are only used during net entry. MAC_RATX.req is the primitive used by an aircraft to request the indication of the next RACH channel from the MAC entity. When the MAC entity received this request it will indicate the next RACH transmit opportunity issuing the MAC_RATX.ind indication to the LME. The LME responds with the MAC_RATX.resp primitive. This primitive takes the net entry message as its single argument.

Parameters:

" Net entry message

The reception of a message on the RACH is indicated to the ground station with the MAC_RA.ind primitive.

4.4.3. Primitives of the BSS

The BSS entity offers the LLC sub-layer four primitives for sending and transmitting data.

! BSS_DATA.req

! BSS_DATA.ind

! BSS_VOICE.ind

! BSS_LME.ind

BSS_DATA.req is the primitive used by all LLC entities to request a packet being queued for sending. It takes the required quality of service, protocol identification and LLC-PDU as arguments. Note that no destination address is required as all B-AMC packets are broadcast by the physical layer.

Parameters:

" Quality of service

" Protocol

" DLL-PDU

When a DLL-PDU has been reassembled by the BSS receive queues the arrived packet is forwarded to the appropriate LLC entity by the BSS using three distinct primitives. BSS_DATA.ind is the indication used to hand a received data packet to the DLS. BSS_VOICE.ind is the indication for the forwarding of voice data to the voice interface (VI). The BSS_LME.ind indication hands management LLC-PDUs to the LME. The packet type is determined by the protocol type. All three primitives take the same single argument.



Page: 4-19

Parameters:

" Received DLL-PDU

4.4.4. Message Flow of the DLS

In the following the message flow of the B-AMC data link layer is presented (Figure 4-12 - Figure 4-14). Observing the message flow from the transmitting point of view, a B-AMC data transmission starts from the DLS with a BSS_Data.req primitive. Within that request the complete DLL-PDU is handed over to the BSS sub-layer. The BSS sub-layer may handle different QoS queues which are served accordingly to their priority. Each queue holds a certain amount of data which is reported toward the MAC sub-layer after a MAC_RR.ind primitive was indicated toward the BSS sub-layer. The current capacity needs are reported within the MAC_RR.resp primitive. After the mechanisms of the MAC sub-layer retrieved capacity from the resource management of the ground station, it is reported back to the BSS sub-layer through the MAC_TX.ind primitive. This primitive indicates toward the BSS sub-layer how many bits it may transmit in the acquired channel. This exact amount of bits is forwarded towards the MAC sub-layer via the MAC_TX.resp primitive. The MAC sub-layer which is responsible for the relative timing forwards the received bit stream towards the PHY via the PHY_DATA.req primitive. The PHY will eventually transmit the data.

Figure 4-12: B-AMC primitives to transmit and receive DLS data.

In the opposite direction the PHY indicates incoming data toward the MAC sub-layer via the PHY_DATA.ind primitive. At MAC sub-layer the incoming data is simply forwarded to the BSS sub-layer, which puts together the possibly separated bit streams. After a complete DLL-PDU was received at BSS level it is forwarded to the proper DLS entity.



Page: 4-20

Figure 4-13: Message sequence chart for transmitting DLS data.

Figure 4-14: Message sequence chart for receiving DLS data.

4.4.5. Message Flow of the LME

Figure 4-15: B-AMC primitives to transmit and receive LME data.

Considering the message flow from the LME (see Figure 4-15 - Figure 4-17), there is no significant difference compared to the DLS message flow, except that the BSS maintains



Page: 4-21

a separate LME queue for management messages. The different interface is expressed through the BSS_LME.ind primitive.

Figure 4-16: Message sequence chart for transmitting LME data.

Figure 4-17: Message sequence chart for receiving LME data.

Figure 4-18: B-AMC primitives to transmit RA frames during net-entry.

Considering the flow of the net-entry message (see Figure 4-18 - Figure 4-20) a direct interface towards the MAC sub-layer exists. If the LME has to transmit a random access message it indicates this toward the MAC sub-layer via the MAC_RATX.req primitive. After that the MAC sub-layer indicates a random access opportunity toward the LME via the MAC_RATX.ind primitive (the random access algorithm is handled by the MAC sub-layer). Following the LME submits the random access message toward the MAC through



Page: 4-22

the MAC_RATX.resp primitive. The MAC forwards the RA message toward the PHY with the PHY_DATA.req primitive.

The PHY indicates toward the MAC a RA message receipt through the PHY_DATA.ind primitive. The MAC itself forwards the RA message toward the LME via the MAC_RA.ind primitive.

Figure 4-19: Message sequence chart for transmitting LME data during net entry.

Figure 4-20: Message sequence chart for receiving LME data during net entry.

4.4.6. Primitives Offered by the A/G B-AMC Data Link Layer

The B-AMC system offers its services to the upper layers through a set of primitives and management entities. Its design is based on [B-VHF D22], although it has been simplified as connection oriented communication is not longer directly supported.

The radio control entity is an external entity, which manages basic voice functions, like selecting a channel. The logical voice channels provided by the B-AMC data link layer are connected to an external voice switching system. The Sub-Network System Management Entity (SN-SME) offers the functionality to power the B-AMC radio up and down. Higher layer protocols are not allowed to use the B-AMC data link layer directly, but interface with the B-AMC sub-network layer, which provides intra-B-AMC network functionality (e.g. handovers between different ground stations, etc.), see Figure 4-21.

The primitives used to connect the B-AMC data link layer with the management entities, voice switching system and the sub-network layer are described in this section. Usually the airborne case is discussed first. If deviations for the ground system exist, they are mentioned immediately afterwards.

The radio control entity, voice switching system and SN-SME are not discussed in detail, as they are considered external to the B-AMC system.



Page: 4-23

Figure 4-21: B-AMC interface to the upper layers.

4.4.6.1. B-AMC DLL Interface for Radio Control

The external radio control entity provides the radio operator with the means to control the voice service provided by the A/G B-AMC system. Two primitives are passed between the B-AMC DLL and the external radio control entity to manage the voice operations of the B-AMC system (for protocols see [B-AMC D2.1], chapter 9).

! BAMC_CHANNEL_SELECT.req

! BAMC_OVERRULED.ind

BAMC_CHANNEL_SELECT.req is the primitive passed from the radio control entity to the B-AMC data link layer to request that the voice channel in use be switched to the desired channel.

Parameters:

" Desired voice channel

The desired channel can either be the party line service, broadcast service or a dedicated voice channel for some other purpose. These additional channels are referenced as the selective voice service.

Note: The desired voice channel is identified by a �B-AMC service ID� B-ID as described in [B-VHF D07]. If the voice channel has been created on demand for a selective voice service it is referenced by a transient B-AMC ID (B-ID*). The B-AMC VI takes care of mapping the B-ID to the �proper� logical voice channel.



Page: 4-24

A ground based B-AMC radio may offer more than one voice channel at the same time (e.g. a B-AMC ground station could provide voice services for several controllers in different sectors.). In this case the parameters are augmented by an additional user index.

The BAMC_OVERRULED.ind is the primitive generated by the aircraft B-AMC system to indicate that the airborne user of the voice channel has been pre-empted by the controller. This indication is generated whenever the controller�s voice activity is detected on the selected voice channel.

If a controller wants to pre-empt an airborne user he needs but to send a voice message. The B-AMC system will mute all airborne users of the same voice channel transparently then.

Note: The base station data link layer does not support the BAMC_OVERRULED.ind. As the base station is the only authority allowed to pre-empt other users of the voice system.

4.4.6.2. B-AMC DLL Interface to the Voice Switching System

In order to support legacy voice switching equipment the B-AMC voice interface is kept as simple as possible. It contains only three primitives.

! BAMC_VOICE_DATA.req

! BAMC_VOICE_DATA.req

! BAMC_VOICE_PTT.req

The B-AMC data link layer provides a vocoder to transform the analogue input from the voice switching system into digital voice samples and back. The B-VHF system has been designed to use the AMBE-ATC-10 vocoder. For details refer to [B-VHF D21].

BAMC_VOICE_DATA.req is the primitive that passes the analogue voice captured from the voice switching system to the vocoder inside the B-AMC system.

If the internal vocoder did transform a received digital sample back to analogue voice the BAMC_VOICE_DATA.ind primitive passes the produced signal to the voice switching system.

BAMC_VOICE _PTT.req is the primitive to indicate that the user pushed the PTT button. It takes no arguments. Upon receipt of this request the B-AMC system triggers the vocoder operation and generates (internal) in-band signals.

4.4.6.3. B-AMC DLL Interface for System Management

The external system management entity (SN-SME) controls the start up and shut down of the B-AMC system. The B-AMC link is brought up via the net initialization procedure. Configuration and net entry are performed transparently to the user. The B-AMC service is shut down via the net exit procedure. Four primitives are exchanged between the system management entity and the airborne B-AMC system (for protocols see [B-AMC D2.1], chapter 9).

! BAMC_NI.req

! BAMC_NI.conf



Page: 4-25

! BAMC_NE.req

BAMC_NI.req is the primitive used by the system management entity to start the B-AMC service. At the receipt of this primitive the airborne B-AMC data link will search for an available ground station and start the net entry procedure.

After the net entry has been completed (successfully or unsuccessfully) B-AMC indicates the result of the procedure by means of the BAMC_NI.conf primitive. The status of the B-AMC service is reported in the primitives� argument.

Parameters:

" Service status

Valid states are:

" Service is up.

" Service is not available.

" Access denied.

This request is normally issued at power-up. Upon receipt of the request airborne B-AMC will commence net entry in the B-AMC cell providing the strongest signal. Once the link is completely set up, the B-AMC sub-network layer will receive the BAMC_LINKUP.ind indication for the newly acquired B-AMC address and start their services.

For the B-AMC ground station an analogue definitions exists: The BAMC_NI.req primitive is the primitive passed from the ground SN-SME to request the B-AMC service be started. Upon receipt of this primitive the ground B-AMC radio will start to transmit the periodic broadcast beacon in the BCH announcing available services to possible mobile clients.

Note: The BAMC_NI.conf confirmation (like it is used in the airborne subsystem) is not necessary in the ground station. A base station does not need to register with any other radio therefore a base station�s net entry is always successful.

Note: It is not necessary to indicate the net entries of mobile stations to the upper layer (e.g. by means of a BAMC_NI.ind primitive). This is handled transparently in the B-AMC layer. Special settings (e.g. access restrictions) are managed by the configuration interface. The same holds true for the net exit of mobile stations.

If the airborne system management entity wishes to shut down the B-AMC service it requests this via the BAMC_NE.req primitive. This primitive triggers the B-AMC net exit procedure.

The result of the above operation is reported by the BAMC_NE.conf primitive. Note that a request to shut down the B-AMC service will always be successful. The resulting state of the data link layer is indicated via the primitive�s argument.

Parameters:

" Service status

Valid states are:

" Net exit confirmed by ground station.

" Net exit not confirmed by ground station or ground station not available.



Page: 4-26

This primitive is usually triggered by a system shut down; in this case the B-AMC sub-network layer receives an BAMC_LINKDOWN.ind indication for the local B-AMC address in use and the B-AMC system performs the net exit procedure.

In the ground station the BAMC_NE.req primitive is passed from the ground SN-SME to B-AMC to request the service be shut down. This primitive is always successful therefore no BAMC_NE.conf confirmation is required.

4.4.6.4. B-AMC DLL Interface to the B-AMC Sub-Net � Link Status

The B-AMC sub-network layer collects and interprets information from the B-AMC data link layer to determine the link status. The resulting state information is used by the sub-network routing protocols and may be passed to higher layer protocols if necessary. For this purpose six primitives are exchanged (for protocols see [B-AMC D2.1], chapter 9).

! BAMC_SNPA.req

! BAMC_SNPA.resp

! BAMC_HANDOVER.req

! BAMC_HANDOVER.ind

! BAMC_LINKUP.ind

! BAMC_LINKDOWN.ind

In order to determine the radio�s sub-network point of attachment (SNPA, i.e. data link layer address) the B-AMC sub-network layer issues the BAMC_SNPA.req request. In response to this request the B-AMC data link layer generates the BAMC_SNPA.resp response. This primitive has a single argument.

Parameters:

" Local B-AMC address

Note that the layer 2 address of an airborne B-AMC radio is assigned by the ground station; therefore it may change in time due to handover events or re-initialization.

Contrary to the airborne B-AMC sub-network layer the base station�s sub-network layer may have to manage more than one sub-network attachment state. In this case the BAMC_SNPA.req primitive passed from the sub-network layer to all connected B-AMC radios to request their layer 2 addresses. It takes no parameters.

Upon receipt of the above request each of the base stations answers with a BAMC_SNPA.resp response reporting its local address. The MAC layer address is the only argument supplied.

If the B-AMC GS decides that the airborne B-AMC data link layer should make a handover to another ground station the issuing of the BAMC_HANDOVER.req request from the airborne B-AMC sub-network layer to the data link layer is triggered (the involved protocols are described in [B-AMC D2.1]). This primitive takes as argument the target B-AMC ground station.

Parameters:

" Target GS for handover



Page: 4-27

If an airborne B-AMC radio has performed a handover from one ground station to another successfully, this is reported to the B-AMC sub-network layer via the BAMC_HANDOVER.ind message. This primitive takes one argument.

Parameters:

" Local B-AMC address

Note that the airborne radio�s layer 2 address need not change if the base stations are managed by the same GSC.

Note: For obvious reasons there is no BAMC_HANDOVER.ind in the base station.

If the airborne B-AMC radio looses contact to the ground station and is unable to reconnect or perform a handover the B-AMC system issues the BAMC_LINKDOWN.ind indication.

Parameters:

" Deprecated address

As soon as the connection is re-established the BAMC_LINKUP.ind indication is raised. At system start-up this primitive is used to inform the upper layers that the B-AMC service is ready.

Parameters:

" New local address

In the ground station the BAMC_LINKUP.ind primitive is passed to the sub-network layer whenever a new radio link (i.e. new base station) becomes available. It single argument reports the new SNPA.

4.4.6.5. B-AMC DLL Interface to the B-AMC Sub-Net � Data Transfer

The B-AMC DLL offers the services necessary for receiving and transmitting voice samples and data packets. In order to provide this service the data link layer has a connectionless interface. The interface is closely modelled after the ISO 8348 [ISO 8348] standard.

Note: ISO 8348 actually describes the interface of the network layer (layer 3), so it does not concern the data link layer directly. Nevertheless the standard is taken into account (where appropriate) to make the operation of higher layer protocols easier.

The higher layer protocols do not use the B-AMC data link layer interface directly; instead they communicate with the B-AMC sub-network layer (using an appropriate SNDCF), which provides the higher layers with a more abstract interface.

The connectionless interface provides two primitives:

! BAMC_UNIT_DATA.ind

! BAMC_UNIT_DATA.req



Page: 4-28

BAMC_UNIT_DATA.req is the primitive passed from the sub-network layer to the B-AMC DLL to request a user data packet be sent. This is a connectionless best-effort service, so no call setup is required. The primitive takes the following arguments.

Parameters:

" Destination address

" Quality of service

" Protocol

" User data

The destination address may be any valid local unicast or multicast address. If the address is invalid or unreachable the packet is silently discarded by the B-AMC data link layer (more advanced methods of error recovery are of course possible).

The protocol field is used to identify the type of sub-network layer packets transferred over the connection.

The quality of service field specifies a desired service level. It is not guaranteed by the B-AMC data link that this level can actually be achieved. An urgent flag is not necessary, as urgent data can be given the appropriate QOS parameters instead.

The interface provides all three B-AMC data services:

! Acknowledged data link service (B-DA)

! Not acknowledged data link service (B-DN)

! Broadcast data link service (B-DB)

These services can be selected via the QOS parameter and may be combined with an additional priority level.

Received data units are indicated by the DLL to the sub-network layer with the BAMC_UNIT_DATA.ind primitive. The following arguments are defined.

Parameters:

" Source address

" Protocol

" User data

The source address is a local unicast id. The value of the protocol field decides the stack the packet is forwarded to.

4.4.6.6. B-AMC Sub-Network Interface

The sub-network layer connects multiple ground-stations and their ground station controllers (GSCs) to the ground network interface (GNI). It inspects received packets on the reverse link and decides whether to forward them to another base station or to hand them up the stack (or possibly perform both actions). It also decides about the GS to be used on the forward link when sending a data packet towards a particular aircraft (this is based on the GNI global knowledge about the logon status of all aircraft at all GSCs within the service area of the GNI) and triggers the handover procedure based on regular power reports.



Page: 4-29

For data transfer services the s similar interface as for the data transfer services of the DLL has been defined. The B-AMC sub-network management happens transparently within the sub-network entity.

The following well-known primitives are supported:

! SN_UNITDATAind

! SN_UNITDATAreq

They have the same properties as the primitives provided by the B-AMC data link described in section 4.4.6.5. The sub-network dependant convergence functions of the supported protocols interface with the B-AMC sub-network layer.

4.4.7. Additional B-AMC Interface Improvements

Due to the short time available for this study a number of highly interesting interface improvements could not be investigated in detail. The most important points for further development are listed below:

! 802.21 MIH: The B-AMC interface as defined in this section provides only basic functionality. The inclusion of further primitives to support 802.21 Media Independent Handover (MIH) is certainly a point of further research.

----------- END OF SECTION -----------



Page: 5-1

5. Standardization Activities and Certification Issues

5.1. Introduction

The ongoing B-AMC study carries out a research on broadband multi-carrier (MC) technology for aeronautical communications in the lower part of the aeronautical L-band (960-1164 MHz). This work is based on the achievements made in the course of the B-VHF project that has developed a baseline multi-carrier concept for a system operating in the VHF COM band.

The significant efforts of the B-AMC study were put onto adaptations of the B-VHF physical layer and its capability to operate under specific interference conditions in the L-band. At the same time, the suite of B-VHF protocols and functions above the physical layer (data link layer and higher layers) has been adapted. The important work of the physical layer adaptation and protocol optimisation is carried out by using computer modelling and simulations.

The B-AMC project will therefore provide a solid basis for the following standardisation activities, but cannot produce the required system prototypes and the full scope of the required standardisation material. Moreover, some further modifications/optimisations of the selected B-AMC protocols and functions may be required but could not be tackled within the B-AMC study.

Apparently, much additional work will be needed to establish B-AMC as a fully validated, mature technology that can be deployed and operationally used for safety-related aeronautical communications. This chapter outlines the most important actors and actions on the roadmap towards such a system, mainly based on the deliverable [B-VHF D27] of the B-VHF project.

5.1.1. Further Steps

The members of the B-AMC team expect that the B-AMC system will score well in the Step II of FCI technology assessment. Assuming that the expectation would fulfil, the next necessary step would be to find the framework within the B-AMC system could be further developed and refined. The opportunity for such a framework could emerge under ongoing the European SESAR activity.

Due to the lack of B-AMC system prototypes, the B-AMC project has assessed the system interference performance and overall QoS aspects by simulations. However, in the practice some additional aspects arise due to non-ideal implementations. Therefore, in the next phase B-AMC system prototypes should be built, including airborne and ground components.

As for other systems, laboratory interference measurements would be required for demonstrating the system capability to operate in the �real� L-band environment and for establishing the frequency planning guidance and detailed criteria. As such measurements are only meaningful with fully mature representative radio hardware, an absolutely important issue in the further B-AMC system validation process is the involvement of radio vendors.

In the course of the B-AMC project it proved to be particularly difficult to produce and provide interference investigation results. This is mainly due to the fact that the inputs for such investigations [FSCA-L] do not provide all required details for an analytical



Page: 5-2

approach. Moreover, brief inspection of related outputs produced for other L-band candidate technologies supports the opinion of the B-AMC team that due to different method applied and different assumptions made, it will be hardly possible to compare these results and draw conclusions. Therefore, the harmonisation of diverging interference approaches and the establishment of common metrics and detailed scenarios for comparing different technologies should be an important task for the next step, as well.

5.2. General Approach for Certification of Airborne Systems

Due to the international nature of air transport, the need for world-wide interoperability of airborne systems resulted in the evolution of an international standardization process. The chain runs from ICAO (SARPS) through JAA/EASA/FAA (JARS/FARS/TSO) and EUROCAE/RTCA (MASPS/MOPS) to ARINC (Equipment Characteristics). This process supports the safe introduction of new products and operational capabilities across national borders and within international airspace.

For classical technologies, ICAO has standards in order to ensure worldwide interoperability between any aircraft and any ATS provider under the responsibility of the Contracting States. The use of data communications between ATS providers and aircraft increases system complexity. Because of this increased complexity, ATS supported by data communications require a high degree of coordination among the stakeholders and approval authorities to ensure compatibility between operator use and ATS provision.

As interoperability is required at all levels, the standardisation covers both operational services that are using some particular communications technology as well as the technology (e.g. B-AMC) itself.

The validation of the newly developed technology standard must be performed as a supplementary activity to the ICAO standardisation. The validation normally comprises both laboratory tests and flight tests. The feedback from the validation activities is typically used for the refinement of SARPs after the initial publication.

5.2.1. ICAO

The main objective of the International Civil Aviation Organization (ICAO) is to ensure safe, regular, efficient, and economical air transport. Its main tool towards this goal is a comprehensive series of international rules � �Standards and Recommended Practices (SARPs)� � which member states agree to follow.

A new system like B-AMC would naturally be subject to ICAO standardisation. According to the past experience with other technologies, this procedure may last several years.

The formulation of new or revised SARPs begins with a proposal for action from ICAO itself or from its Contracting States. Proposals may also be submitted by international organizations (e.g. EUROCONTROL).

For technical SARPs, proposals are analysed first by the Air Navigation Commission (ANC). Depending on the nature of the proposal, the ANC may assign its review to a specialized working group. Working groups meetings are the main vehicle for drafting and finalising the SARPs work and reaching the necessary consensus.

The original recommendations for core SARPs along with any alternative proposals developed by the ANC are submitted to Contracting States and selected international



Page: 5-3

organizations for comment. Finally, the amendments to Annexes recommended by the ANC are presented to the ICAO Council for adoption.

Adopted SARPs are periodically reviewed and revised, as necessary, to keep abreast with technological and other developments affecting the aviation industry.

The current ICAO approach is to keep the SARPs relatively short and delegate detailed information to the dedicated �Manuals on Technical Specifications� for the corresponding system.

Taking VDL as an example, ICAO Annex 10 now comprises basic definitions and VDL system capabilities as well as short SARPs for VDL modes 2, 3 and 4, describing system characteristics of the ground and airborne installation (transmitting power, adjacent channel and spurious emissions, receiving functions), physical layer protocols and services. Basic information about the VDL Mobile SNDCFs applicable to different VDL modes is also included, as well as the description of the Voice Unit for VDL Mode 3.

Details of VDL mode-specific link layer and subnetwork layer protocols and services have been delegated to the corresponding �Manuals of VDL Technical Specifications�. As a specific example, ICAO Doc 9816-AN/448 � Manual on VHF Digital Link (VDL) Mode 4 � comprises Part I (Implementation Manual) and Part II (Technical Manual).

Implementation Manual (Part I) comprises an overview of the VDL Mode 4 services in support of CNS/ATM, key functions and applications supported by the system, technical description of VDL Mode 4 and its operating principles, architecture and implementation options for airborne, ground, airport and surface vehicle installations, methods for channel management and channel switching and possible future applications of VDL Mode 4.

Technical Specifications (Part II) describes in detail VDL Mode 4 link layer protocols and services and VDL Mode 4 SNDCF, providing additional detailed material for ADS-B application and definitions for Compact Position Reporting.

The development of ICAO SARPs is an inevitable step for any safety-related mobile aeronautical communications technology. Therefore SARPs would be required for the B-AMC system as well. Once available, B-AMC SARPs would provide the necessary input for other standardisation bodies (e.g. EUROCAE/RTCA, ARINC) to develop their standards.

For the B-AMC system, similar structure of the ICAO standards can be anticipated as for VDL, comprising B-AMC SARPs to be included in Annex 10 as well as separated detailed �Manual on B-AMC Technical Implementation�. Moreover, similar basic contents would be applicable to both documents as in the VDL case.

The B-AMC project deliverables � in particular B-AMC System High Level Description [B-AMC D2.1], B-AMC Technology Operational Concept and Deployment Scenarios [B-AMC D2.2], as well as this deliverable � B-AMC System Specification and Standardisation and Certification Considerations � provide an initial basis for producing such standards.

5.2.2. EUROCAE/RTCA

The primary task of EUROCAE and RTCA (Radio Technical Commission for Aeronautics) working groups is to prepare performance specifications and similar documents, which may be referenced by Aviation Authorities in Technical Standard Orders (TSO).

[RTCA DO-264] identifies a set of different standards that apply to a given communications system:



Page: 5-4

! Operational Services and Environment Definition (OSED)

! Operational, Safety and Performance Requirements (SPR)

! Interoperability Requirements (INTEROP)

! Minimum Operational Performance Standards (MOPS) / Minimum Aviation System Performance Standards (MASPS)

These standards are developed by EUROCAE/RTCA, but some may be delegated to other bodies and groups.

The OSED is used as the basis for assessing and establishing operational, safety, performance, and interoperability requirements for the related CNS/ATM system. The OSED identifies the operational Air Traffic Services (ATS) supported by data communications and their intended operational environments and includes the operational performance expectations, functions, and selected technologies of the related CNS/ATM system. The OSED captures requirements that have been derived and/or validated as being necessary for a particular operational service.

An SPR standard is used to coordinate the operational, safety, and performance objectives and allocate requirements for the different approval types:

! ATS provider operational approval

! Aircraft type design approval

! Operator operational approval

SPR is developed using an Operational Safety Assessment (OSA) and an Operational Performance Assessment (OPA) of the functions, performance expectations, and characteristics of operational environments needed to support the ATS identified in the OSED.

An INTEROP standard is used to provide sufficient information to enable different stakeholders to develop system elements that are compatible for an operational implementation. It is developed using an interoperability assessment (IA) of selected functions and technologies needed to support the ATS identified in the OSED. An INTEROP standard identifies the technical, interface, and related functional requirements for a specific technology or a mix of technologies. The INTEROP provides traceability from each requirement to the functions it supports, the services, and the operating environments in the OSED. Similar to an SPR standard, an INTEROP standard can be tailored to meet the needs of a particular operational implementation.

In most cases, Minimum Operational Performance Standards (MOPS) and Minimum Aviation System Performance Standards (MASPS) published by EUROCAE and RTCA provide performance requirements tailored to characteristics of a specific technology. These standards can be used to assess the feasibility of a specific technology to meet the minimum operational, safety, and performance requirements defined in an SPR. These standards normally do not provide an operational performance basis.

For the B-AMC system the B-AMC MOPS would have to be developed and referenced in the OSED, SPR and INTEROP documents.

In order to preserve required safety and performance levels, prior to any practical operational usage a careful analysis and mapping of applications onto �carrier technologies� must be done. The B-AMC technology has been developed by taking requirements for known operational services into account, however, the detailed mapping



Page: 5-5

and investigation must be done separately for each B-AMC service that is intended to be deployed.

5.2.3. JAA/EASA/FAA

The mission of these bodies is to develop, maintain, and promote safety standards in the field of design and production of aeronautical products. In 2003 the European Community and the other entities involved in the sector have established the European Aviation Safety Agency (EASA) to give Europe a single aviation safety authority, like the Federal Aviation Administration (FAA) of the United States. With the start of EASA operations, the Central Joint Aviation Authorities (JAA) Certification Division is providing support to EASA in its certification related activities for

! certification of aeronautical products, parts and appliances;

! approval of organisations/personnel engaged in the maintenance of these products;

! approval of air operations;

! licensing of air crew etc.

Communication equipment must meet a Technical Standard Order (TSO), which is a form of certification for a particular piece of equipment. A TSO is a minimum performance standard issued by the Administrator for specified materials, processes, and appliances used on civil aircraft.

The installation of airborne avionics systems generally requires airworthiness certification, which is part of its Type certificate (TC) for new aircraft or Supplemental Type Certificate (STC) for aircraft already in service.

5.2.4. ARINC

The intent of an ARINC Characteristic is to provide design guidance for the development and installation of the airborne equipment. As such, this guidance covers the operational capabilities of the system and the standards necessary to achieve inter-changeability of the hardware produced by various manufactures. Heart of all ARINC Characteristics is the standardized inter-wiring including e.g. specific form factor, mounting provisions, input/output interfaces, and power supply characteristics.

Due to the target concept [B-AMC D6] of the B-AMC airborne system architecture (packaging within existing units) the implementation of the B-AMC technology for the purpose of an A/G data link would mainly affect two existing avionics standards:

! ARINC 750 � VHF Data Radio (VDR)

! ARINC 758 � Communications Management Unit (CMU)

The B-AMC airborne transceiver should be preferably deployed as an upgrade of the VDR radio. This would allow the VDR to be used with existing wiring in �traditional� modes (DSB-AM, VDL Mode 2) in the narrowband airspace, and in the B-AMC mode � including digitised voice � in the B-AMC-supported airspace.

Should it prove that such integration within existing VDR is not technically feasible, the corresponding ARINC standards should be developed for a stand-alone B-AMC radio unit.

The CMU should be upgraded to implement necessary B-AMC-specific data link functions that are not suitable to be implemented within the physical transceiver.



Page: 5-6

The concept for an airborne integration of a B-AMC radio when operating in the A/A mode is less clear [B-AMC D6] due to the lack of harmonised airborne architecture for that case. The final decision will drive the need for establishing new-/modifying existing ARINC standards.

5.2.5. ETSI

ETSI is involved in producing European standards for VDL Mode 4 ground installations and would probably be tasked with developing similar standards for other types of the aeronautical ground equipment, including the B-AMC ground station.

----------- END OF SECTION -----------



Page: 6-1

6. References

Reference Description

[B-AMC D1] B-AMC Report D1 � DME Spectrum Investigations, Rev. 0.3, 08.05.2007

[B-AMC D2.1] B-AMC Report D2.1 � System High Level Description, Rev. 0.5, 13.06.2007

[B-AMC D2.2] B-AMC Report D2.2 � Technology Operating Concept and Deployment Scenarios, Rev 0.1, 16.07.2007

[B-AMC D5] B-AMC Report D5 � Expected B-AMC System Performance, Rev. 0.1, 16.07.2007

[B-AMC D6] B-AMC Report D6 � System Specification Including Standardization and Certification Considerations, Rev. 0.3, 16.07.2007

[B-VHF D6] B-VHF Report D6 � B-VHF Functional Principles and Architecture, Rev. 1.0, 05.04.2005

[B-VHF D7] B-VHF Report D7 � B-VHF Operational Concept Document, Rev. 1.0, 10.10.2005

[B-VHF D8] B-VHF Report D8 � MAC Requirements and Specification, Rev. 1.0, 25.05.2005

[B-VHF D10] B-VHF Report D10 � Requirements on B-VHF System Parameters, Rev. 1.0, 02.05.2005

[B-VHF D18] B-VHF Report D18 � Physical Layer Design for Forward and Reverse Link, Rev. 1.0, 10.05.2006

[B-VHF D19] B-VHF Report D19 � MAC Requirements and Specification Including Rationale for Selection of MAC Approach and Interface Definition, Rev. 1.0, 25.05.2006

[B-VHF D20] B-VHF Report D20 � Specification of the LLC Protocol, Rev. 1.0, 31.08.2005

[B-VHF D21] B-VHF Report D21 � Data Link Layer Design, Rev. 1.0, 10.02.2006

[B-VHF D22] B-VHF Report D22 � Upper Layer Protocol Design and Specification, Rev. 1.1, 10.02.2006

[B-VHF D27] B-VHF Report D27 � Deployment Scenario, Rev. 1.0, 03.10.2006

[COCRv2] EUROCONTROL/FAA Future Communications Study, Operational Concepts and Requirements Team, �Communications Operating Concept and Requirements for the Future Radio System�, Ver. 2, May 2007.

[EvalScen] Eurocontrol/FAA Future Communications Study, �Future Communications Infrastructure � Technology Investigations, Evaluation Scenarios�, rev. 0.99, 2007

[FSCA-L] EUROCONTROL/FAA Future Communications Study, �Framework for Spectrum Compatibility Analysis in L-Band for FCI Technology Candidates�, Draft 1.0

[HJZZ99] S. Höst, R. Johannesson, K.S. Zigangirov, V.V. Zyablov ,�Active Distances for Convolutional Codes,� IEEE Transactions on Information Theory, Vol. 45, No. 2, pp. 658-669, March 1999

[ISO 8348] International Standard ISO 8348, �Information Technology � Open Systems Interconnection � Network Service Definition�, April 1987



Page: 6-2

[ISO/IEC 13239] International Standard ISO/IEC 13239:2002(E), �Information Technology � Telecommunications and Information Exchange Between Systems � High-Level Data Link Control (HDLC) Procedures�, 3rd ed., 2002

[RTCA DO-264] RTCA/DO-264, Guidelines for Approval of the Provision and Use of Air Traffic Services Supported by Data Communications, 14.12.2000

[SC97] T. M. Schmidl and D. C. Cox, �Robust frequency and timing synchronization for OFDM�, IEEE Transactions on Communications, Vol. 45, No. 12, pp. 1613-1621, December 1997

----------- END OF SECTION -----------



Page: 7-1

7. Abbreviations

A/A Air-air

A/G Air-ground

ACK Acknowledge

ADS-B Automatic Dependent Surveillance - Broadcast

ANC Air Navigation Commission

ANI Airborne Network Interface

AOC Airline Operational Communications

ARINC Aeronautical Radio INCorporated

ARQ Automatic Repeat Request

ATC Air Traffic Control

ATM Air Traffic Management

ATN Aeronautical Telecommunications Network

ATS Air Traffic Services

AWGN Additive White Gaussian Noise

B-AMC Broadband Aeronautical Multi-carrier Communications

B-VHF Broadband VHF

BC BroadCast (frame)

BCCH Broadcast Control Channel (logical channel)

BIS Boundary Intermediate System

BSS B-AMC Special Services

CC Common Control (slot)

CCC Common Communications Channel

CCCH Common Control Channel (logical channel)

CMU Communications Management Unit

CNS Communication, Navigation, Surveillance

COM Communication

CoS Class of Service

CRC Cyclic Redundancy Check

DATAd Data OFDM frame

DC Dedicated Control (slot)

DCCH Dedicated Control Channel (logical channel)

DCH Data channel (logical channel)

DLL Data Link Layer

DLS Data Link Services



Page: 7-2

DME Distance Measuring Equipment

DSB-AM Dual Side Band � Amplitude Modulated

EASA European Aviation Safety Authority

ENR En-Route

ETSI European Telecommunications Standard(isation) Institute

EUROCAE EURopean Organisation for Civil Aviation Equipment

EUROCONTROL European Organisation for the Safety of Air Navigation

FAA Federal Aviation Administration

FARs Federal Aviation Regulations

FCI Future Communications Infrastructure

FDD Frequency-Division Duplex

FFT Fast Fourier Transform

FL Forward Link

FRS Future Radio System

GNI Ground Network Interface

GPS Global Positioning System

GS Ground Station

GSC Ground Station Controler

HF Hyper-Frame

IA Interoperability Assessment

ICAO International Civil Aviation Organisation

ICI Inter-Carrier Interference

INTEROP Interoperability Requirements

ISI Inter-Symbol Interference

JAA Joint Aviation Authority

JARs Joint Aviation Requirements

JTIDS Joint Tactical Information Distribution System

LLC Logical Link Control

LME Link Management Entity

MAC Medium Access Control

MASPS Minimum Aviation System Performance Standards

MC Multi-Carrier

MC-CDMA Multi-Carrier Code-Division Multiple-Access

MF Multi-Frame

MIDS Multifunctional Information Distribution System

MOPS Minimum Operational Performance Standards



Page: 7-3

MTU Maximum Transfer Unit

OFDM Orthogonal Frequency-Division Multiplexing

OFDMA Orthogonal Frequency-Division Multiple-Access

OPA Operational Performance Assessment

OSA Operational Safety Assessment

OSED Operational Services and Environment Definition

OSI Open System Interconnect

PDU Protocol Data Unit

PHY Physical Layer

QoS Quality of Service

QPSK Quadrature Phase Shift Keying

RA Random Access (frame)

RACH Random Access Channel

RL Reverse Link

RS Reed-Solomon

RTCA Radio Technical Commission for Aeronautics

SA Synchronized Access (slot)

SACH Synchronised Access Channel (logical channel)

SARPs Specification And Recommended Practices

SESAR Single European Sky ATM Research

SF Super-Frame

SN Sub-Network

SN-SME Sub-Network Management Entity

SNDCF Subnetwork Dependent Convergence Function

SPR Operational, Safety and Performance Requirements

STC Supplemental Type Certificate

TBC Transport channel for BCCH logical channel

TC Type Certificate

TDD Time-Division Duplex

TDMA Time Division Multiple Access

Tn Transport channel (n OFDM carriers)

TNc Transport channel (all OFDM carriers)

TRA Transport channel for RACH logical channel

TSO Technical Standard Orders

UTC Universal Time Co-ordinated

VCH Voice channel (logical channel)



Page: 7-4

VDL VHF Digital Link

VDR VHF Data link Radio

VHF Very High Frequency

VI Voice Interface

----------- END OF SECTION -----------



Page: 8-1

8. Appendix � Protocol Design for A/A Mode

In this chapter, a communication protocol for direct air-air communications (A3C) is presented. The protocol is based on TDMA medium access. Moreover, it is distributed and self-organized which means that no central control instance used for resource management is needed.

8.1. Assumptions

Figure 8-1 shows the TDMA structure which is used by the air-air communication protocol. One B-AMC A3C Frame is one UTC second long and consists of 512 data slots and 64 management slots where one management slot occurs regularly after eight data slots. The data slots are used by stations for the transmission of user data, e.g. surveillance data like ADS-B, whereas management slots are used for the transmission of information concerning slot occupancy. The duration of management slots is twice the duration of data slots, therefore, the duration of the data slot can be calculated as 1 / (512+64*2) = 1.5625 ms6.

Figure 8-1: B-AMC A3C TDMA structure.

Further, we assume that it is possible to transmit up to 68 user data bytes (+ header) in one data slot and up to 136 user data bytes (+ header) in one management slot, respectively. A management slot occurs always after eight data slots.

8.2. Slot Occupancy Transmission in Management Slots

Information concerning data slot occupancy within the A3C frame is transmitted by a certain station in a management slot. Data slot occupancy is represented as a bitmap consisting of 1024 bits where two bits always represent the occupancy state of a certain data slot over the last one-second period. Four different states, encoded with the two bits, have been defined for each data slot:

00 � FREE: slot is free, no interferer detected;

6 According to [B-AMC D2.1] the OFDM frame duration will be 500 µs. Thus, the guard time will be 1.062 ms which corresponds to 172 NM transmission range.



Page: 8-2

01 � WEAK: a weak7 signal has been received; decoding not possible;

10 � COLLISION: a strong8 signal has been detected in the slot, which could not be decoded; therefore it is assumed that a data collision occurred;

11 � OCCUPIED: slot is occupied, signal was decoded correctly.

The state of a certain slot, which is calculated from the signal strength of a received physical frame, will be forwarded by the physical layer to the MAC via service primitives at the end of each slot. At the physical layer only three different states can be identified, �free�, �weak� and �strong�. Thus, when the MAC gets a �strong� notification from the physical layer and the received frame was decoded correctly then it sets the slot state to OCCUPIED otherwise to COLLISION.

The periodic transmission of management data is mainly used to overcome the hidden station problem which refers to the collision of packets at a receiving node due to the simultaneous transmission of two or more nodes which are not directly within each others transmission range but are within the transmission range of the receiver. A receiving station always checks the received bitmap from a neighboring station whether a collision occurred in its used data slot or not. If a collision is detected then it chooses a new slot. The hidden station problem is illustrated in Figure 8-2.

Figure 8-2: Hidden station problem.

7 An appropriate weak signal threshold value must be defined based on interference considerations. 8 An appropriate strong signal threshold value must be defined based on interference considerations.



Page: 8-3

Further, a kind of weighting for each slot state has been introduced as this will play an important role when a station decides to choose a certain data slot when data has to be transmitted:

00 0

01 1

10 2

11 3

8.3. Net Entry

When a station powers up its B-AMC A3C communication system it does not start immediately with the transmission of data. At the beginning it listens for several seconds, e.g.: for 8 seconds9, on the channel. In this time the station generates an internal data slot occupancy table derived from the neighbour table where each entry consists of the address and the channel state as seen by this certain neighbour and from a station�s own point of view on the channel.

A station monitors management slots and extracts from transmitting neighbouring stations their occupancy bitmaps. The state of each slot (its corresponding weight) is inserted into the neighbour table (Table 8-1).The station compares the neighbour table with its own sight and builds a consolidated slot occupancy table (last row in Table 8-1).

0 1 2 3 4 5 6 7 8 9 10 11 � 511A 0 0 3 3 0 0 0 0 0 0 0 0 0B 0 0 3 0 0 0 0 0 0 0 0 3 0C 0 0 0 0 0 0 0 0 0 0 0 0 0D 0 0 0 0 0 0 0 0 0 0 0 0 0E 0 0 0 0 0 0 0 0 0 0 0 0 0F 0 0 0 0 0 0 0 0 0 0 0 0 0G 0 0 0 0 0 0 0 0 0 0 0 0 0H 0 0 0 0 0 0 0 0 0 0 0 0 0

own sight 0 0 0 3 0 0 0 0 0 0 0 3 0occupancy table 0 0 3 3 0 0 0 0 0 0 0 3 0

Aircraft Data Slots

Table 8-1: Derived occupancy table from own sight and neighbour table (row A-H).

As already mentioned above, at net entry a station listens on the channel for 8 seconds. In this time it creates the neighbour table and its own sight. The creation of the own sight is presented in Table 8-2. It depends on the slot states of the last eight frames where weights for each frame have been defined and in such a manner that the oldest 9 We decided to listen for at least 8 seconds, but this was just a first assumption. It

could also be less than eight seconds (depending on system duty).



Page: 8-4

one (HistoryFrameID = 1) has the lowest weight and the latest (HistoryFrameID = 8) the highest. By the end of the latest frame the current slot state of each slot is calculated by summing up the weights for each slot state. Finally, the slot state with the highest value is inserted into the own sight table.

A possible value W for this weight for each history frame (last eight frames) is as follows:

dicatorSlotUsedIndicatorSlotUsedInmeIDHistoryFra

meIDHistoryFraW ××

=∑ )(

,

where HistoryFrameID ranges from [1..8] and

SlotUsedIndicator = 1 if slot is used by neighbour stations (derived directly from received and evaluated header information in data slots; see Chapter 8.9 for preliminary further details) or unknown (hidden station) or

SlotUsedIndicator = 0 otherwise.

For example (assuming that the SlotUsedIndicator was always 1), in the first three frames slot 0 was free (FREE state), thus 6/36 (1/36+2/36+3/36) is calculated, then two weak signals where received which means that 9/36 (4/36+5/36) is calculated for the WEAK state and finally, 21/36 (6/36+7/36+8/36) is calculated for the OCCUPIED state. Then max(FREE, WEAK, OCCUPIED) is calculated and inserted into the own sight table, in this case it is OCCUPIED.

0 1 2 3 4 5 6 7 8 9 10 11 � 5111 1/36 0 0 0 0 0 3 0 3 0 0 0 0 � 02 2/36 0 0 0 0 0 3 0 3 0 0 0 0 � 03 3/36 0 0 0 0 0 3 0 3 0 0 0 0 � 04 4/36 1 0 0 0 0 1 0 3 0 0 0 0 � 05 5/36 1 0 0 0 0 1 0 3 0 0 0 0 � 06 6/36 3 0 0 0 0 0 2 2 0 0 0 0 � 07 7/36 3 0 0 0 0 0 2 2 0 0 0 0 � 08 8/36 3 0 0 0 0 0 2 2 0 0 0 0 � 0

own sight 3 0 0 0 0 0 2 2 0 0 0 0 � 0

Data SlotsWeightsFrames

Table 8-2: Own sight creation.

8.4. Choosing a Slot

As already mentioned each station maintains a neighbour table comprising for each neighbour the neighbour�s address, the slot ID and the channel state bitmap as seen by this neighbour. The neighbour table is then compared with a station�s own channel occupancy table; see section 8.3 (and Table 8-1).

From this comparison an estimated channel state is derived and a station generates two lists. The first consists of all free slots and the second of all weak slots. A slot is chosen from one list according to a two-state selection procedure:

4. Choose randomly, but uniformly distributed, a slot from type 00 slots; if no free slots available then go to 2.



Page: 8-5

5. Choose randomly, but uniformly distributed, a slot from type 01 slots.

Else no channel is available.

8.5. Changing the Slot

The slot used to transmit data is (randomly) changed after variable number of used frames in the interval [x,y]10 where x is the minimum- and y the maximum number of consecutive slots used for data transmission. The number of slots with the same slot ID to be used in consecutive frames is always determined at the beginning of each slot change. Furthermore, at this stage, already the next slot ID, which will be used afterwards11 is determined and indicated in the header of each data packet. Moreover, the remaining number of frames (including the current transmission) used for data transmission in the current slot is always included in the header of a data packet. 7 bits are used for the number of transmissions and 9 bits (0 � 511) represent the slot that will be used in the future.12

A new slot, see section 8.4., will also be chosen if a station realizes that the currently used slot could no be received correctly by neighbour stations anymore.

8.6. Data Transmission

In order to overcome the problem (shown in Figure 8-3) of two stations being inside of each others transmission range and transmitting in the same slot which could lead to a collision at several receiving nodes - or in an undetected collision if only the 2 transmitting stations exist - a station, although it has chosen a free slot, transmits always with a certain probability using a p-persistence13 mechanism. An additional approach for collision detection that could be taken into account might be the following:

After having transmitted a message at the beginning of a slot, which takes about 350µs according to DLR�s en-route framing considerations, the station switches immediately back to the listening mode and listens on the channel. If it receives a strong signal within the slot used for its own transmission then the station could assume that another station has also transmitted in this slot and a collision occurred.

10 Appropriate values must be determined in further evaluations of the proposed A3C

protocol. 11 This indicated slot ID depends on the current view of a stations channel state and

could be changed if the need arises. 12 This approach supports channel management to be carried out by neighbour stations

involved (e.g. if a station transmits in slot S and indicates in the data header: slot ID = T; outstanding transmission count = 3, this means that it will transmit 2 further data packets (after the current frame) in slot S and then switch to slot T. At the moment it is foreseen that a station uses only one slot per frame, but a station could also decide to use more than one slot depending on applications.

13 An appropriate value must be determined in further evaluations of the proposed A3C protocol.



Page: 8-6

If a collision has been detected, then a new slot must be chosen with a certain probability14.

Figure 8-3: Collision scenario where two stations (A and B) transmit in the same slot.

8.7. Bitmap Transmission

In each management slot mi a certain station transmits the channel state (slot occupancy) from its own point of view but only if the channel ID (data slot in which the station tries to transmit data) equals )8(8mod is + . P-persistence is also used here for slot interferer detection.

8.8. Net Exit

A station indicates net exit by transmitting a final message in the header of a data slot where the 7 bits representing outstanding transmissions are set to 015.

14 An appropriate value must be determined in further evaluations of the proposed A3C protocol. 15 The number of outstanding transmissions is set to 0 only in case of Net Exit; otherwise, in case of switching to a new slot ID, this new slot ID together with a transmission count of 1 (= last transmission in the currently used slot) is transmitted.



Page: 8-7

8.9. Remark: Further Extensions of the A3C Basic Mode

The Basic Mode (CHmode = 0; see below) of the A3C direct air-air communication protocol has been developed mainly to describe the principles of the A3C protocol as well as carry out intensive performance evaluations of the proposed protocol.

However, taking today�s and future aeronautical applications and scenarios (see e.g. [COCRv2]) into account, several different traffic channel data rates must be provided to support both broadcast communications (e.g. periodic ADS-B messages) as well as point-to-point communications.

For this, the following extension is foreseen, but not fully described in this document: The Channel Mode (CHmode) and Channel Rate (CHnr) is indicated by a combination of 6 bits in the header of each data slot in which a transmission by the station occurs as follows: CHmode (coded in 2 bits see below) + CHnr (coded in 4 bits).

CHmode = 0 (00): Full-rate channel: Slot will be occupied (every second) in each subsequent frame for the specified number (CHnr) of frames in the future (CHnr ranges from 0 to CHnr_max16; see below). This mode can be used for messages occurring periodically (e.g. ADS-B broadcast messages transmitted every second) as well as for non-periodic transmission of larger messages in subsequent frames (e.g. for point-to-point communications); this includes also a single transmission (CHnr = 0), in which case no further usage of this slot is intended in subsequent frames (slot can be considered FREE afterwards).

CHmode = 1 (01): Slot will be allocated in a multiple of 2 in subsequent frames (e.g. every other frame (second), every 4th frame (second), etc.); the rate is specified in CHnr parameter as power of 2;

CHmode = 2 (10): Slot will be allocated in a multiple of 3 in subsequent frames (every third frame (second), or every 6th frame (second), etc.); the rate is specified in CHnr parameter as power of 3.

CHmode = 3 (11): Slot will be allocated in an multiple of 5 in subsequent frames (i.e. every fifth frame (second) or every 10th frame (second), etc.); the rate is specified in CHnr parameter as power of 5.

CHnr = 0..15 (0000..1111): Number of subsequent frames in which the slot will be allocated (if CHmode = 0) or rate (if CHmode is 1, 2 or 3). With these values a reservation for maximal 15 subsequent frames corresponding to 15 seconds (Full Rate or non-periodic transmissions corresponding to 15*68 = 1088 user data octets) in the future can be made, or using a 1/r channel rate, reservation as seldom as 515 = 30,517,578,125 seconds corresponding to approximately 353,212 days can be made.

Therefore, with these A3C protocol extensions, non-periodic or periodic Full-Rate Channels as well as 1/2, 1/3, 1/4, 1/5, 1/6, 1/8, 1/9, 1/10, 1/12, 1/15, 1/16 etc. rate

16 An appropriate value must be determined in further evaluations of the proposed A3C protocol, currently CHnr_max is set to 15.



Page: 8-8

channels can be specified and supported by the A3C protocol suitable both for broadcast messages (e.g. ADS-B) as well as for point-to-point communications.

For stations intending to use a 1/r-rate channel, the following slot assignment algorithm is foreseen:

1. Scan all slots to determine which Channel Mode and Channel Rates are in use in each of the 512 user data slots (from the station�s point of view).

2. If a corresponding 1/r-rate channel is already in use in any of the currently used slots, select one of the used slots and transmit in a frame/slot which is not occupied so far (periodically empty slot);

3. If no corresponding 1/r-rate is already in use or if a corresponding 1/r-rate slot is already saturated (used by the maximum number of stations equal to r), apply the �Choosing a Slot� procedure of A3C protocol described in chapter 8.4. and indicate the Channel Mode and Channel rate used in this slot in the header of each data transmission (CHmode + CHnr described above).

It is assumed that with the extensions of the A3C protocol outlined briefly in this chapter, the communication requirements for direct air/air communications of today�s and foreseen future aeronautical applications will be fulfilled. The detailed specification of these A3C extensions, the required adaptations to the A3C medium access and channel management algorithms, as well as the results of detailed performance evaluations of the proposed extensions are outside the scope and therefore, will not presented in this document.

8.10. A/A Mode LLC Design

This section gives an overview of the A/A LLC design. It outlines some FEC algorithms which could be used by the LLC to fulfil integrity requirements. Finally, an overview of the DLL with its entities is presented.

8.10.1. FEC Algorithms and Techniques

In Table 8-3 and Table 8-4 air-air addressed and broadcast COS are presented. There are two air-air addressed services where COS DA-A is reserved for a future service and six broadcast COS.

Further, messages of both traffic classes, addressed and broadcast, will be unacknowledged and retransmission will be not possible. This implies that instead of an ARQ protocol very strong FEC, maybe combined with CRC, has to be used at DLS sub-layer to guarantee data integrity, see Table 8-4. Several FEC algorithms like Reed Solomon (RS), Turbo Codes (TC) or Low-density parity-check codes (LDPC) and techniques like concatenated coding (e.g. RS and Viterbi) will be taken into account and investigated.

Using different FEC algorithms for different services might be a meaningful approach. For example RS could be used for time-critical services with small message sizes (fit into one slot if system is TDMA based) like PAIRAPP and TC could be used for services like AIRSEP where delay is not that critical, transmission rate is low and messages have to be fragmented into several smaller frames.



Page: 8-9

COS ET TD95-FRS CUIT-FRS IUCT-FRS AP-FRS AU-FRS Service Type

DA-A rsvd rsvd rsvd rsvd rsvd rsvd rsvd

DA-B 7.8 2.4 0.9996 5.0E-8 0.999995 0.9995 AIRSEP

Table 8-3: A/A addressed COS categories, taken from [COCRv2] Table 6-19.

COS ET TD95-FRS CUIT-FRS IUCT-FRS AP-FRS AU-FRS Service Type

DB-A 3.2 0.4 0.99996 5.0E-8 0.9995 0.9995

DB-B 4.8 1.2 0.9996 5.0E-8 0.9995 0.9995

DB-C 8.0 1.2 0.9996 5.0E-8 0.999995 0.9995

SURV A-A Data

DB-D 3.2 1.2 0.99996 5.0E-8 0.9999975 0.99995

DB-E 8.0 1.2 0.99996 5.0E-8 0.9999975 0.99995

DB-F 16.0 1.2 0.99996 5.0E-8 0.9999975 0.99995

SURV (ATC) TIS-B WAKE

Table 8-4: Broadcast COS categories, taken from [COCRv2] Table 6-20.

8.10.2. LLC Based on Single CCC Approach

Figure 8-4 shows the A/A B-AMC system with the physical, MAC and LLC Layer with its entities according to MAC approach. The DLL consists of the DLS entity which will be responsible for fragmentation17, priority scheduling and FEC. The LME will have a similar functionality like in the A/G mode and the BSS simply provides the MAC with DLS packets.

17According to [COCR] only AIRSEPP messages have to be fragmented (497 bytes) all other messages will fit into one single TDMA slot.



Page: 8-10

Figure 8-4: B-AMC A/A physical, MAC and DLL layer with a single CCC.

----------- END OF SECTION -----------

REPORT D 3 System Specification Including … · REPORT D 3 System Specification Including...

Documents

Transcript of REPORT D 3 System Specification Including … · REPORT D 3 System Specification Including...