Manual On VHF Digital Link (VDL) Mode 4: Doc 9816 AN/448

Doc 9816
AN/448
Manual on VHF
Digital Link (VDL)
Mode 4
Approved by the Secretary General

and published under his authority
First Edition — 2004
International Civil Aviation Organization

Doc 9816
AN/448
Manual on VHF
Digital Link (VDL)
Mode 4
Approved by the Secretary General

and published under his authority
First Edition — 2004

AMENDMENTS
The issue of amendments is announced regularly in the ICAO Journal and in the
monthly Supplement to the Catalogue of ICAO Publications and Audio-visual
Training Aids, which holders of this publication should consult. The space below
is provided to keep a record of such amendments.
RECORD OF AMENDMENTS AND CORRIGENDA
AMENDMENTS CORRIGENDA
No. Date Entered by No. Date Entered by
(ii)
FOREWORD
This document contains a comprehensive description of the Very High Frequency (VHF) Digital Link (VDL) Mode 4
data link, notably the capabilities, technical characteristics, and modes of operation of VDL Mode 4. It complements
the Standards and Recommended Practices (SARPs) for VDL Mode 4 as contained in Annex 10 to the Convention on
International Civil Aviation Aeronautical Telecommunications, Volume III, Part I Digital Data Communication
Systems.
Part I of this document — Implementation Aspects of the Manual on VHF Digital Link (VDL) Mode 4, comprises of
five chapters which describe the implementation of VDL Mode 4. They are as follows:
Chapter 1, Part I of this document provides an overview of the role of VDL Mode 4 services in support of the
operations in Communications, Navigation and Surveillance (CNS) and in Air Traffic Management (ATM), and it also
describes the key functions and applications supported by the system.
Chapter 2, Part I provides a technical description of VDL Mode 4 and its operating principles.
Chapter 3, Part I addresses the architecture and implementation options for airborne, ground, airport and surface
vehicle installations.
Chapter 4, Part I describes the methods for channel management and channel switching in VDL Mode 4, with focus
on Automatic Dependent Surveillance Broadcast (ADS-B) operation.
Chapter 5, Part I describes potential future applications of VDL Mode 4.
Meanwhile, Part II of this document — Detailed Technical Specifications of the Manual on VHF Digital Link (VDL)
Mode 4, is made up of four chapters outlining the detailed technical specifications of VDL Mode 4. They are as follows:
Chapter 1, Part II of this document describes the link layer protocols and services, including the Media Access
Control sub-layer, VLD Mode 4 specific services sub-layer, data link service sub-layer, and link management entity
sub-layer.
Chapter 2, Part II describes the VDL Mode 4 subnetwork dependent convergence function.
Chapter 3, Part II provides additional material for ADS-B applications.
Chapter 4, Part II offers definitions for Compact Position Reporting, including fixed data field encoding and
decoding, information field offset encoding and decoding, patch ID encoding and decoding, and position report
processing.
Comments on this document would be appreciated from all parties involved in the implementation of aeronautical
mobile communication. These comments should be addressed to:
The Secretary General

999 University Street
Montréal, Quebec H3C 5H7
Canada
(iii)
(iv) Manual on VHF Digital Link (VDL) Mode 4
Note 1. References to Annex 10 are made to include all amendments up to Amendment 78. Paragraph numbering
in later editions of Annex 10 may change and affect the references in this document.
Note 2. Regular updates to this document may be found at the Aeronautical Communications Panel website
(http://www.icao.int/anb/panels/ACP/).
___________________
TABLE OF CONTENTS
PART I. IMPLEMENTATION ASPECTS

Page
List of illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-(i)
Acronyms, abbreviations and symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-(v)
Chapter 1. The role of VDL Mode 4 in CNS and ATM operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-1
1.2 Background to the development of VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-1
1.3 Technical context of the functional capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-1
1.4 Overview of VDL Mode 4 services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-3
1.5 Communication services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-3

1.5.1 Broadcast services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-3
1.5.2 End-to-end communication services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-3
1.6 Surveillance functions and applications of VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-4

1.6.1 Use of multiple channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-4
1.6.2 Automatic Dependent Surveillance — Broadcast (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-5
1.6.3 Automatic Dependent Surveillance — Contract (ADS-C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-6
1.6.4 Illustrative uses of Automatic Dependent Surveillance (ADS) applications . . . . . . . . . . . . . . . . I-1-6
1.7 VDL Mode 4 capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-11
Chapter 2. Technical description and operating principles of VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1
2.2 Physical elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1

2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1
2.2.2 Global Navigation Satellite System (GNSS) receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1
2.2.3 Very High Frequency (VHF) transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-2
2.2.4 Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-2
2.2.5 Communication processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-3
2.3 Functional design principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-3
(v)
(vi) Manual on VHF Digital Link (VDL) Mode 4
Page
2.4 Functional elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-4

2.4.1 Physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-4
2.4.2 Time Division Multiple Access (TDMA) frame structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-5
2.4.3 System timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-5
2.4.4 Position information and synchronization bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-8
2.4.5 Message types and structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-8
2.4.6 Slot selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-10
2.4.7 Operating modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-13
2.4.8 Slot access management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-14
2.4.9 Aeronautical Telecommunication Network (ATN) communication mechanisms . . . . . . . . . . . . I-2-25
2.4.10 Link management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-39
2.5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-51

2.5.1 Mobile stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-52
2.5.2 Ground stations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-54
Appendix A to Chapter 2. Link management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-1
1. Synchronization burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-1

2. General burst header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-1
3. Fixed data field of synchronization burst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-2
4. Variable data field of synchronization burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-3
5. Directory of Services (DoS) message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-4
Appendix B to Chapter 2. Automatic Dependent Surveillance —

Broadcast (ADS-B) implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-1
1. Fixed data field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-1

2. Variable data fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-1
Appendix C to Chapter 2. Compact Position Reporting (CPR) encoding algorithm. . . . . . . . . . . . . . . . . . I-2C-1
1. Characteristics of the Compact Position Reporting (CPR) algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-1

2. Representation of latitude and longitude angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-2
3 Compact Position Reporting (CPR): Constants, variables and functions . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-2
4. Compact Position Reporting (CPR) encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-6
5. Compact Position Reporting (CPR) decoding from a single report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-10
6. Compact Position Reporting (CPR) global decoding with two reports . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-14
7. Compact Position Reporting (CPR) position report processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-18
Appendix D to Chapter 2. Network entry: threshold value for CG1 counter . . . . . . . . . . . . . . . . . . . . . . . . I-2D-1
Chapter 3. Architectures and implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-1
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-1
3.2 Redundancy considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-1

3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-1
3.2.2 Availability, continuity and integrity requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-2
Part I. Implementation aspects
Table of Contents (vii)
Page
3.3 Aircraft architectures and implementation aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-4

3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-4
3.3.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-4
3.3.3 Transceiver configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-5
3.3.4 Antenna installation considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-6
3.3.5 Examples of equipage levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-7
3.3.6 Cockpit display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-8
3.3.7 Redundancy aspects of aircraft installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-8
3.3.8 Aircraft retrofit aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-12
3.4 Ground architectures and implementation aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-12

3.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-12
3.4.2 Ground architecture elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-12
3.4.3 Implementation options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-16
3.4.4 Data distribution in a ground network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-16
3.4.5 System resource management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-18
3.4.6 Directory of Services (DoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-18
3.4.7 Implementation of applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-19
3.5 Airport and vehicle architectures and implementation aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-20

3.5.1 Mobile stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-21
3.5.2 Ground controller display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-21
3.5.3 Ground stations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-21
3.5.4 VHF channel requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-21
3.5.5 Operational aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-21
3.6 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-23

3.6.1 Surface movement surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-23
3.6.2 Runway incursion monitoring (RIM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-23
3.6.3 Snow clearing operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-23
3.6.4 Rescue coordination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-24
3.7 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-24
3.8 Certification and approval aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-24
Chapter 4. Channel management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-1
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-1
4.2 The use of multiple channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-1

4.2.1 Applications and channel types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-2
4.2.2 Global Signalling Channels (GSCs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-2
4.2.3 Additional channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-3
4.2.4 Required number of channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-3
4.2.5 Service volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-3
4.3 Channel management and channel switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-3

4.3.1 Ground station management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-3
(viii) Manual on VHF Digital Link (VDL) Mode 4
Page
4.4 Airborne equipment for multiple channel use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-8
4.5 Transition aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-8
4.6 Channel management scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-8

4.6.1 Example 1: Channel management for a terminal control area (TMA) with airspace
access requirements for VDL Mode 4 limited to users equipped with at least
three receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-8
4.6.2 Example 2: Channel management for Core of Europe assuming airspace access
requirements for VDL Mode 4 are limited to two receivers and one transmitter. . . . . . . . . . . . . I-4-13
4.6.3 Example 3: Channel management for Los Angeles (LA) Basin, assuming airspace
access requirements for VDL Mode 4 are limited to two receivers and one transmitter . . . . . . I-4-20
4.7 Description of regional definitions for channel management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-30
Appendix A to Chapter 4. Failure modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4A-1
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4A-1
2. Aircraft loses the transmitter in the terminal area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4A-1
3. Loss of one aircraft receiver in the terminal area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4A-2
4. Aircraft fails to act on switching instruction from the ground station or ground station fails
to instruct aircraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4A-3
5. Failure of the ground station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4A-3
6. Global Navigation Satellite System (GNSS) failure modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4A-3
Appendix B to Chapter 4. ADS-B requirements air-to-air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4B-1
Chapter 5. Potential future applications for VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-1
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-1
5.2 Overview of VDL Mode 4 services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-1
5.3 Functions and applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-2

5.3.1 Potential communications applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-2
5.3.2 Potential navigation applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-3
5.4 Summary of potential future VDL Mode 4 capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-6

Table of Contents (ix)
Page
PART II. DETAILED TECHNICAL SPECIFICATIONS
List of illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-(i)
Acronyms, abbreviations and symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-(vii)
Chapter 1. Link layer protocols and services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-1
1.1 General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-1

1.1.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-1
1.1.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-1
1.1.3 Definitions, acronyms, abbreviations and parameter symbols . . . . . . . . . . . . . . . . . . . . II-1-1
1.2 Media Access Control (MAC) sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-7

1.2.1 MAC sub-layer services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-7
1.2.2 MAC sub-layer parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-8
1.2.3 Time synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-9
1.2.4 Slot idle/busy notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-10
1.2.5 Transmission processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-11
1.2.6 Received transmission processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-11
1.3 VDL Mode 4 specific services (VSS) sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-11

1.3.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-11
1.3.2 Burst format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-12
1.3.3 VSS sub-layer parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-16
1.3.4 VSS quality of service (QoS) parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-17
1.3.5 Received transmission processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-19
1.3.6 Reserved access protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-19
1.3.7 Random access protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-25
1.3.8 Fixed access protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-28
1.3.9 Null reservation protocol specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-28
1.3.10 Periodic broadcast protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-28
1.3.11 Incremental broadcast protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-34
1.3.12 Combined periodic broadcast and incremental broadcast protocol specification. . . . . . . . II-1-36
1.3.13 BND broadcast protocol specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-37
1.3.14 Unicast request protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-38
1.3.15 Information transfer request protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-42
1.3.16 Directed request protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-45
1.3.17 Block reservation protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-54
1.3.18 Response protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-61
1.3.19 General request protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-62
1.3.20 General response protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-64
1.3.21 Re-transmission procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-66
1.4 Data link service (DLS) sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-66

1.4.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-66
(x) Manual on VHF Digital Link (VDL) Mode 4
Page
1.4.2 DLS protocol specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-68

1.4.3 DLS system parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-77
1.4.4 DLS procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-78
1.5 Link management entity (LME) sub-layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-91

1.5.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-91
1.5.2 Synchronization burst format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-92
1.5.3 Control (CTRL) parameter formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-98
1.5.4 LME timers and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-116
1.5.5 LME procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-117
1.5.6 Types and procedures of CTRL DLPDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-126
1.5.7 CTRL transmission procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-126
Chapter 2. VDL Mode 4 mobile subnetwork dependent convergence function (SNDCF) . . . . . . . . . II-2-1
Chapter 3. Additional material for Automatic Dependence

Surveillance — Broadcast (ADS-B) applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-1
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-1
3.2 Acronyms, abbreviations and parameter symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-1
3.3 Information field formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-3
3.4 ADS-B request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-14

3.4.1 ADS-B request format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-14
3.4.2 Autonomous monitoring (sleep) mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-15
3.4.3 Automatic selection of variable information fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-15
3.5 Default ADS-B reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-17

3.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-17
3.6 ADS-B procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-17

3.6.1 ADS-B request procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-17
3.6.2 Transmission of time synchronization request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-18
3.6.3 Information field priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-18
3.6.4 Trajectory Change Point/State Vector Quality (TCP/SVQ) change procedures . . . . . . . . II-3-18
3.7 Control (CTRL) parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-19

3.7.1 Directory of Service (DoS) message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-19
3.7.2 Channel management parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-20
Chapter 4. Definitions for Compact Position Reporting (CPR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-1
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-1
4.2 Parameter symbols, data types, constants and variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-1

Table of Contents (xi)
Page
4.2.1 Parameter symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-1

4.2.2 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-1
4.2.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-1
4.2.4 Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-2
4.2.5 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-3
4.2.6 Patch constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-4
4.3 Fixed data field position encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-6

4.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-6
4.3.2 Input parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-6
4.3.3 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-6
4.4 Fixed data field position local decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-7

4.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-7
4.4.3 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-7
4.5 Fixed data field position global decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-9

4.5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-9
4.5.3 Transition level straddling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-10
4.5.4 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-10
4.6 Information field offset encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-11

4.6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-11
4.6.3 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-11
4.7 Information field offset decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-13

4.7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-13
4.7.3 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-13
4.8 Patch ID (PID) encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-15

4.8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-15
4.8.3 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-15
4.9 Patch ID (PID) decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-15

4.9.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-15
4.9.3 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-16
4.10 Position report processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-16

4.10.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-16
4.10.2 Position report parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-17
4.10.3 Position report processing procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-17
___________________
PART I
IMPLEMENTATION ASPECTS
LIST OF ILLUSTRATIONS
List of Figures
Chapter 1. The Role Of VDL Mode 4 in CNS/ATM operations
Figure I-1-1 Time slots in VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-2

Figure I-1-2 VDL Mode 4 end-to-end communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-4
Figure I-1-3 VDL Mode 4 ATN concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-5
Figure I-1-4 Time slot usage in VDL Mode 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-6
Figure I-1-5 Ground network support for ADS-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-7
Figure I-1-6 Cockpit display of traffic information (CDTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-7
Figure I-1-7 TIS-B concept and ATS surveillance provided by ADS-B and radar . . . . . . . . . . . . . . . I-1-8
Figure I-1-8 Examples of position data exchange in a ground management system. . . . . . . . . . . . . . I-1-10
Figure I-1-9 CDTI in support of surface surveillance and situational awareness . . . . . . . . . . . . . . . . I-1-10
Chapter 2. Technical description and operating principles of VDL Mode 4
Figure I-2-1 The VDL Mode 4 unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-2

Figure I-2-2 OSI layering in VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-6
Figure I-2-3 GFSK superframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-7
Figure I-2-4 VDL Mode 4 burst structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-9
Figure I-2-5 VDL Mode 4 slot selection process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-11
Figure I-2-6 Graceful shrinkage of cell radius of a broadcast station resulting from
use of the Robin Hood principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-12
Figure I-2-7 Co-channel intervention protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-13
Figure I-2-8 Autonomous operational scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-14
Figure I-2-9 Periodic broadcast protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-16
Figure I-2-10 Incremental broadcast protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-17
Figure I-2-11 Unicast request protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-19
Figure I-2-12 Autotune reservation protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-20
Figure I-2-13 Information transfer request protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-22
Figure I-2-14 Random access protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-23
Figure I-2-14a DLS services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-26
Figure I-2-14b Use of DLS and VSS functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-27
Figure I-2-14c Use of the T-bit in a short transmission procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-30
Figure I-2-14d Short transmission procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-31
Figure I-2-14e Long transmission procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-33
Figure I-2-14f Linked transmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-34
Figure I-2-15a Channel usage efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-35
Figure I-2-15b Message frequency versus message length (octets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-37
Figure I-2-15c Message frequency versus message length (slots) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-38
Figure I-2-16 Sudden arrival of previously hidden station, aircraft X, into a busy airspace . . . . . . . . I-2-40
Figure I-2-17 Use of periodic broadcast and incremental broadcast reservations
for network entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-42
I-(i)
I-(ii) Manual on VHF Digital Link (VDL) Mode 4
Figure I-2-18 BND reservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-43

Figure I-2-19 Half-slot transmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-45
Figure I-2-20 Plea response protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-45
Figure I-2-21 Blocks protected by ground and mobile rebroadcast transmissions . . . . . . . . . . . . . . . . I-2-46
Figure I-2-22 Block protection using multiple mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-47
Figure I-2-23 Block protection with multiple ground stations and mobiles . . . . . . . . . . . . . . . . . . . . . . I-2-47
Figure I-2-24 Second frame block reservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-48
Figure I-2-25 Ground quarantining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-49
Figure I-2-26 Channel assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-50
Figure I-2-27 Ground station transmissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-56
Appendix C to Chapter 2 . Compact Position Reporting (CPR) encoding algorithm
Figure I-2C-1 Angle scale based on integer representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-2

Figure I-2C-2 Illustration of longitude encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-7
Figure I-2C-3 Illustration of longitude decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-12
Figure I-2C-4 Illustration of longitude global decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-16
Chapter 3. Architectures and implementations
Figure I-3-1 Basic VDL Mode 4 installation on GA aircraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-4

Figure I-3-2 Airborne transceiver equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-5
Figure I-3-3 Antenna installations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-6
Figure I-3-4 Cockpit display operating in an en route environment . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-9
Figure I-3-5 Possible transceiver configuration for AT and high-end GA aircraft . . . . . . . . . . . . . . . I-3-9
Figure I-3-6 Example of AT category aircraft architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-10
Figure I-3-7 Multi-mode receiver (MMR) integrated VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-11
Figure I-3-8 Possible internal MMR architecture with VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-11
Figure I-3-9 Basic ground architecture elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-13
Figure I-3-10 Typical ground station set-up with external interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-14
Figure I-3-11 Physical topology of the Swedish segment of the NEAN network . . . . . . . . . . . . . . . . . I-3-15
Figure I-3-12 Interconnection of national domains in NEAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-16
Figure I-3-13 Connections between a ground station and ATM system
providing full redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-17
Figure I-3-14 Multicast distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-17
Figure I-3-15 Generation and distribution of TIS-B position data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-19
Figure I-3-16 TIS-B service volumes (polygons) and reference points (X) . . . . . . . . . . . . . . . . . . . . . . I-3-20
Figure I-3-17 ADS-B surface surveillance system supporting snow clearing operations. . . . . . . . . . . I-3-24
Chapter 4. Channel management
Figure I-4-1 Service volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-4

Figure I-4-2 Directory of Services (DoS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-5
Figure I-4-3 Ground station transmissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-6
Figure I-4-4 Channel management procedures (inbound traffic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-10
Figure I-4-5 Channel management procedures (outbound traffic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-11
Figure I-4-6 Simplified graphical depiction of Core of Europe 2015 airborne traffic . . . . . . . . . . . . I-4-14
Figure I-4-7 Strawman resource allocation for LSC/GND channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-16
Figure I-4-8 Channel assignments and update rates for Core of Europe . . . . . . . . . . . . . . . . . . . . . . . I-4-17
Figure I-4-9 Strawman resource assignment methodology for GSC2 . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-20
Figure I-4-10 Simplified graphical depiction of LA Basin 2020 airborne traffic . . . . . . . . . . . . . . . . . I-4-22
Part I. Implementation Manual
List of Illustrations I-(iii)
Figure I-4-11 Strawman resource allocation for GND channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-23

Figure I-4-12 Channel assignments and update rates for LA Basin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-25
Figure I-4-13 Possible slot reuse scheme for LA Basin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-26
Figure I-4-14 Strawman resource assignment scheme for LA Basin tesselation . . . . . . . . . . . . . . . . . . I-4-26
Chapter 5. Potential future applications for VDL Mode 4
Figure I-5-1 VDL Mode 4 communications services and example applications . . . . . . . . . . . . . . . . . I-5-1
Figure I-5-2 Controller-pilot data link communications (CPDLC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-2
Figure I-5-3 Flight Information Services — Broadcast (FIS-B). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-3
Figure I-5-4 Global Navigation Satellite System (GNSS) augmentation . . . . . . . . . . . . . . . . . . . . . . . I-5-4
Figure I-5-5 Secondary navigation capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-5
Figure I-5-6 Secondary navigation based on ADS-B reports from other users . . . . . . . . . . . . . . . . . . I-5-6
List of Tables
Chapter 1. The Role Of VDL Mode 4 in CNS/ATM operations
Table I-1-1 VDL Mode 4 capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-11
Table I-2-1 Unicast DLS burst format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-27

Table I-2-2 DLDPU contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-29
Appendix A to Chapter 2. LINK MANAGEMENT
Table I-2A-1 Encoding for the fixed part of the synchronization burst . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-2
Table I-2A-2 Encoding for the variable part of the synchronization burst . . . . . . . . . . . . . . . . . . . . . . . I-2A-3
Table I-2A-3 Link management information fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-3
Table I-2A-4 Information field 3 hex — Basic ground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-4
Table I-2A-5 Information field 4 hex — UTC time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-4
Table I-2A-6 Overall structure of the GSIF message with two CTRL parameters
(VSS sub-layer and DoS) included without compression . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-6
Table I-2A-7 Example of compressed channel management CTRL burst format
(VDL Mode 4 header excluded) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-8
Appendix B to Chapter 2. Automatic Dependent Surveillance — Broadcast (ADS-B) Implementation
Table I-2B-1 Encoding for ADS-B variable information fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-1

Table I-2B-2 ADS-B information fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-3
Table I-2B-3 Information field 0 hex — Basic information field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-3
Table I-2B-4 Information field 1 hex — High dynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-4
Table I-2B-5 Information field 2 hex — Full position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-4
Table I-2B-6 Information field 9 hex — Trajectory Change Point (TCP) . . . . . . . . . . . . . . . . . . . . . . . I-2B-5
Table I-2B-7 Information field A1 hex — Aircraft data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-5
Table I-2B-8 Information field AA0 hex— High resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-6
I-(iv) Manual on VHF Digital Link (VDL) Mode 4
Appendix C to Chapter 2. Compact Position Reporting (CPR) encoding algorithm
Table I-2C-1 Constants used in Compact Position Reporting (CPR) calculations . . . . . . . . . . . . . . . . I-2C-2
Table I-2C-2 Variables used in CPR calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-3
Table I-2C-3 Input parameters and return values for functions used in CPR calculations . . . . . . . . . I-2C-4
Table I-2C-4 Transition latitude lookup table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-5
Table I-2C-5 Fixed data field latitude/longitude encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-6
Table I-2C-6 Information field offset encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-8
Table I-2C-7 Patch ID (pid) encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-9
Table I-2C-8 Parameters sent in the synchronization burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-10
Table I-2C-9 Fixed data field latitude/longitude decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-11
Table I-2C-10 Information field offset decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-13
Table I-2C-11 Patch ID (pid) decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-13
Table I-2C-12 Parameters sent in the synchronization burst for point (b) . . . . . . . . . . . . . . . . . . . . . . . . I-2C-15
Table I-2C-13 Compact Position Reporting (CPR) global decoding equations . . . . . . . . . . . . . . . . . . . I-2C-15
Table I-2C-14 Observations on differences in segment length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-16
Table I-2C-15 State transitions for Compact Position Reporting (CPR) processing . . . . . . . . . . . . . . . I-2C-19
Chapter 3. Architectures and implementations
Table I-3-1 Level equipage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-7

Chapter 4. Channel management
Table I-4-1 Channel allocations and switching procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-9

Table I-4-2 Distances to outlying cities from Brussels (Core of Europe scenario) . . . . . . . . . . . . . . I-4-14
Table I-4-3 Timeline and reporting rates by airspace region. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-19
Table I-4-4 Message delivery success probability (P) required to satisfy ADS-B MASPS . . . . . . . I-4-28
Table I-4-5 Timeline and reporting rates by airspace region. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-29
Table I-4-6 General structure of channel management parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-30
Table I-4-7 Regional multicast block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-31
Appendix B to Chapter 4. ADS-B requirements air-to-air
Table I-4B-1 ADS-B report accuracy, update period and acquisition range requirements . . . . . . . . . I-4B-1
Chapter 5. Potential future applications for VDL mode 4
Table I-5-1 Potential future VDL Mode 4 capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-6
___________________
ACRONYMS, ABBREVIATIONS AND SYMBOLS
AAC Aeronautical Administrative Communication

ACAS Airborne Collision Avoidance System
ACI Adjacent channel interference
ACK Acknowledgement
ACL ATC clearance
ACM ATC communications management
ACP Aeronautical Communications Panel
ADS-B Automatic Dependent Surveillance — Broadcast
ADS-C Automatic Dependent Surveillance — Contract
ADSP Automatic Dependent Surveillance Panel
AFAS Aircraft in the Future ATM System
AIRSAW Airborne Situational Awareness
AMSS Aeronautical Mobile Satellite Service
AOC Airline Operation Centre; Airline Operational Communications
ASAS Airborne Separation Assistance (System)
A-SMGCS Advanced Surface Movement Guidance and Control System
AT Air transport
ATC Air Traffic Controller; Air Traffic Control
ATIS Automatic Terminal Information Service
ATIS-B Automatic Terminal Information Service — Broadcast
ATM Air Traffic Management
ATN Aeronautical Telecommunication Network
ATS Air Traffic Services
AWGN Additive White Gaussian Noise
AWOP All Weather Operations Panel
BND Big negative dither
CAA Civil Aviation Authority

CCI Co-channel interference
CD&R Conflict detection and resolution
CDTI Cockpit Display of Traffic Information
CDU Cockpit display unit
CMD Command
CMU Communications Management Unit
CNS Communications, Navigation and Surveillance
COTS Commercial off-the-shelf
CPDLC Controller-Pilot Data Link Communication
CPR Compact Position Reporting
csid Command set ID
CTS Clear to send (burst)
DAP Downlink of Airborne Parameters

dB decibel
I-(v)
I-(vi) Manual on VHF Digital Link (VDL) Mode 4
DGNSS Differential Global Navigation Satellite System

DLPDU Data Link Protocol Data Unit
DLS Data link services
DM Disconnect mode (for connected links)
DME Distance measuring equipment
DoS Directory of Services
D-OTIS Data Link Operational Terminal Information System
D-RVR Digital — Runway Visual Range
dt directed time out parameter
D/U Desired/Undesired (signal ratio)
DYNAV Dynamic Route Availability Notification
EFIS Electronic Flight Instrument System
FIR Flight Information Region

FIS Flight Information Service
FIS-B Flight Information Service — Broadcast
FLIPCY Flight Plan Consistency Checking
FMS Flight Management System
fpm feet per minute
fps feet per second
FRMR Frame reject (frame)
GA General Aviation
GFSK Gaussian-filtered Frequency Shift Keying
GND Ground
GNSS Global Navigation Satellite System
GPS Global Positioning System
GRAS Ground-based Regional Augmentation Service
GSC Global Signalling Channel
GSIF Ground Station Information Frame
hex hexadecimal encoding

HF High Frequency
ICAO International Civil Aviation Organization

IFR Instrument Flight Rules
INFO Information (frame)
INS Inertial navigation system
kHz kilohertz
LAN Local area network

LME Link Management Entity
LRU Line replaceable unit
LSC Local Signalling Channel
MASPS Minimum Aviation System Performance Standard

MHz megahertz
MMR Multi-mode receiver
ms millisecond
MS Mode status
Part I. Implementation Manual
Acronyms, abbreviations and symbols I-(vii)
NAC Navigational accuracy category

NEAN North European ADS-B Network
NIC Navigational integrity category
NM nautical miles
NPV Non-precision approach with vertical guidance
nr Nominal update rate
ns nanosecond
NSCOP Negotiated Set Up Connection-Orientated Protocol
OC On-condition
OSI Open Systems Interconnection
P Probability
PANS Procedures for Air Navigation Services
PDC Pre-departure clearance
PIREP Pilot report
pr Priority
pr_f Plea response flag
PRM Precision runway monitor
PSTN Public Switched Telecommunication Network
PVT Position, velocity and time
QoS Quality of Service
RCP Required Communication Performance

res currently unused
R/F Radio Frequency
RIM Runway incursion monitoring
rms root mean square
RNE Rapid net entry
RNP Required Navigation Performance
RSP Required Surveillance Performance; Response
RTCA Radio Technical Commission for Aeronautics
RTS Request to send (burst)
SAR Search and Rescue

SARPs Standards and Recommended Practices
SBAS Satellite-based Augmentation System
sdf Source/destination flag
SIL Surveillance integrity level
SMGC Surface Movement Guidance Control
SMR Surface Movement Radar
SSR Secondary Surveillance Radar
STDMA Self-Organizing Time Division Multiple Access (Technology)
SV State Vector (report)
SZOM Start Zero Overhead Mode
TBD To be defined
TC update interval
TCP Trajectory Change Point
TCP/IP Transmission Control Protocol and Internet Protocols
TDMA Time Division Multiple Access
I-(viii) Manual on VHF Digital Link (VDL) Mode 4
TFOM Time figure of merit

TIS Traffic Information Services
TIS-B Traffic Information Services — Broadcast
TMA Terminal control area
TWR Aerodrome control tower
UDATA broadcast equivalent of DATA which embraces all broadcast type DLPDUs
µs microsecond
UTC Universal Time Coordinated
VDL Very High Frequency (VHF) Digital Link

VFR Visual Flight Rules
VHF Very High Frequency
VLMC Virtual Link Management Channel
VSS VDL Mode 4 specific services
WAN Wide area network
ZOCOP Zero Overhead Connection-Orientated Protocol
___________________
Chapter 1
THE ROLE OF VDL MODE 4 IN CNS AND ATM OPERATIONS
1.1 INTRODUCTION
This chapter provides an overview of the Very High Frequency (VHF) Data Link (VDL) Mode 4 services in support of
Communications, Navigation and Surveillance (CNS) and of Air Traffic Management (ATM) operations and it also
describes the key functions and applications supported by the system. In particular, section 1.7 summarizes how the
requirements for surveillance data link capabilities can be accommodated by the system.
1.2 BACKGROUND TO THE DEVELOPMENT OF VDL MODE 4
The VDL Mode 4 was developed based on the Self-Organizing Time Division Multiple Access (STDMA) technology
and was intended to meet the requirements for a high capacity data link that can support demanding ATM applications.
The capabilities of VDL Mode 4 aim to meet the following design requirements:
a) to operate from gate-to-gate, on the ground and in all types of airspace, with global implementation;
b) to operate without the need for complex ground infrastructure (although additional benefits may be gained if
this were available);
c) to offer a solution for all user groups with appropriate cost-effectiveness and performance for different user
requirements; and
d) to support a range of ATM applications.
In line with these design requirements, VDL Mode 4 is a flexible system which can be adapted to new applications as
requirements become available.
1.3 TECHNICAL CONTEXT OF THE FUNCTIONAL CAPABILITIES
Note.— A technical description of the system is provided in Chapter 2. The very high-level description given in
1.3.1 to 1.3.3 will facilitate the understanding of the technical context of the functional capabilities described in this
chapter.
1.3.1 VDL Mode 4 is a VHF data link providing digital communications between mobile stations (aircraft and
airport surface vehicles) and between mobile stations and fixed ground stations. It was developed for CNS/ATM
aviation applications, including broadcast applications (e.g. Automatic Dependent Surveillance — Broadcast (ADS-B))
and point-to-point communications (e.g. Automatic Dependent Surveillance — Contract (ADS-C)). The most
prominent properties of VDL Mode 4 are its efficient exchange of short repetitive messages and its ability to support
time-critical applications.
I-1-1
Chapter 1. The role of VDL Mode 4 in CNS and ATM operations I-1-2
1.3.2 VDL Mode 4 transmits digital data in a standard 25 kHz VHF communications channel and employs a
Time Division Multiple Access (TDMA) scheme. A TDMA system divides the communication channel into time
segments of one-minute superframes, which in turn are subdivided into time slots. The start of each time slot is an
opportunity for a station to transmit. A surveillance system such as ADS-B cannot have restrictions that limit the
maximum number of participating stations. VDL Mode 4 is capable of handling overload situations (i.e. more slots
required than are currently available) and of adapting to the traffic in a controlled and safe manner.
1.3.3 Built on the STDMA concept, the unique feature of VDL Mode 4 is the way that the available transmission
time is divided into a large number of short time slots synchronized to Universal Time Coordinated (UTC). Each time
slot may be used by a radio unit (mounted on aircraft, ground vehicles or at fixed ground stations) for the transmission
of data. The exact timing of the slots and their planned use for transmissions are known to all users within the range of
each other, so that efficient use of the data link can be made and users do not transmit simultaneously. As a result
of this “self-organizing” protocol, VDL Mode 4 does not require the operation of any ground infrastructure and
can therefore support air-air as well as ground-air communications and applications. The concept is illustrated in
Figure I-1-1.
Time slot 1 Time slot 3

used by used by
aircraft A aircraft B
1 2 3 4 5 6 7
Time slot 2
used by
ground
station
Figure I-1-1. Time slots in VDL Mode 4

1.4 OVERVIEW OF VDL MODE 4 SERVICES
VDL Mode 4 provides a range of digital communications services that support many CNS/ATM applications. VDL
Mode 4 also incorporates a surveillance element, in which all users regularly transmit their position, making it possible
for all users (e.g. aircraft, ground stations) to know the exact location of all other users in the vicinity. This information
is used to manage the data link; it also makes possible a host of broadcast and point-to-point communication protocols
that can be used to implement ADS-B and ADS-C applications.
1.5 COMMUNICATION SERVICES
VDL Mode 4 supports two different types of communications services:
1) VDL Mode 4 specific services (VSS); and
2) VDL Mode 4 Aeronautical Telecommunications Network (ATN) data link services (DLS).
The VSS include broadcast and non-ATN point-to-point (addressed) communications with a minimum of overhead
information for exchange of time-critical data. In addition, VDL Mode 4 constitutes an ATN subnetwork and provides
fully ATN-compliant communication services. Together these services support several broadcast and end-to-end
communication functions that, in turn, support a range of air-ground and air-air ATM applications. As elaborated in
Chapter 3 on Architecture and Implementations, VDL Mode 4 services are accommodated on multiple Radio
Frequency (R/F) channels. The point-to-point channels should preferably be separated from those R/F channels
supporting VSS. Different broadcast communications could share a single channel. The possibilities for R/F channel
sharing however depend on various constraints, such as channel availability, channel loading, certification requirements
and Air Traffic Services (ATS) regulations, and they may also differ between states and regions.
1.5.1 Broadcast services
1.5.1.1 ATN does not support broadcast transmissions. However, broadcast transmissions (defined as “specific
services”) are used in many different CNS/ATM applications. Depending on the application, the broadcast transmission
can be made by both ground stations and mobile units.
1.5.1.2 The broadcast of data is the fundamental VDL Mode 4 technique, while point-to-point communications
could be seen as a complementary function for realizing specific needs in future ATM concept. As an enabler of
important applications and services, such as ATS surveillance, Cockpit Display of Traffic Information (CDTI), Surface
Movement Guidance Control (SMGC) and Airborne Separation Assistance System (ASAS), ADS-B is a key VDL
Mode 4 function.
1.5.2 End-to-end communication services
1.5.2.1 In VDL Mode 4, end-to-end communications can be realized by using VSS or by using the full ATN
protocol (router and DLS) as illustrated in Figure I-1-2. The selection of either VSS or VDL Mode 4 ATN data link
services is based on a number of parameters, such as aircraft equipage, ground infrastructure, time criticality, economic
aspects and channel loads.
1.5.2.2 VDL Mode 4 is one of the available subnetworks to be used for ATN communications. The selection of
the subnetwork (i.e. VDL Mode 2, 3 or 4; Aeronautical Mobile Satellite Service (AMSS); High Frequency (HF) data
link; or Mode S data link) is made by the airborne router (see Figure I-1-3).
APPLICATION
ATN ROUTER
VDL Mode 4 ATN VDL Mode 4

AMSS DL HF DL Data Link Services (DLS) Specific Services (VSS)
Mode S DL VDL VDL Mode 4

Transceiver
Figure I-1-2. VDL Mode 4 end-to-end communications
1.5.2.3 A particular advantage of using VDL Mode 4 for ATN communications is that the reservation protocols
available can be used to reserve transmission time for each message. This significantly reduces the probability of
channel contention (i.e. when two or more transmissions attempt to access the same time slot at the same time), as
compared to, for instance, VDL Mode 2. The result is greater capacity. ATN communications, as illustrated in
Figure I-1-3, will always use a separate frequency.
1.6 SURVEILLANCE FUNCTIONS AND APPLICATIONS OF VDL MODE 4
1.6.1 Use of multiple channels
The number of channels required to support VDL Mode 4 services in a certain area will depend on local and regional
conditions, such as the traffic density (which affects the channel load), certification requirements, ATS regulations, and
spectrum availability. For example, whereas a single channel may be acceptable for supporting ADS-B, CDTI, and
Traffic Information Services — Broadcast (TIS-B) in one area, multiple channels may be required to support these
applications in a high-density terminal area. More information is provided in Chapter 4 (Channel Management).
Application (end)
ATN router
VDL Mode 4 Data Link Data Link

ATN DLS n n+1
ATN router
Application (end)
Figure I-1-3. VDL Mode 4 ATN concept
1.6.2 Automatic Dependent Surveillance — Broadcast (ADS-B)
1.6.2.1 The ADS-B function uses the VDL Mode 4 synchronization burst message formats to broadcast regularly
the identity, position, altitude, time, intent and vector information of an aircraft or a ground vehicle for use by other
users. Because position reporting is an integral part of communications management in VDL Mode 4, the core elements
of ADS-B are already present on the link.
1.6.2.2 The size of the time slots on the data link is adapted to accommodate an ADS-B report. A time slot may
accommodate other information elements as illustrated in Figure I-1-4.
1.6.2.3 ADS-B supports many mobile air-air and ground-ground surveillance applications such as CDTI1 and
Airborne Situational Awareness (AIRSAW) and airborne separation. When VDL Mode 4 system also includes ground
stations, then it is also able to support ground surveillance and other ADS-B applications such as Advanced Surface
Movement Guidance and Control Systems (A-SMGCS), enhanced Air Traffic Control (ATC), Search and Rescue
(SAR) coordination, etc.
___________________
1. CDTI in this context means the functional capability to display position information, not the physical unit.
Reporting rate for aircraft A

once every 5 sec
Reporting rate for aircraft B

once every 5 sec
KEY: Position reports

Met data, etc
from aircraft A
Position reports
Other aircraft
from aircraft B
reports
Note.— Actual number of slots is much larger than shown.
Figure I-1-4. Time slot usage in VDL Mode 4
1.6.2.4 Provided that airport vehicles are also equipped with VDL Mode 4, Figure I-1-5 shows how ADS-B can
be used to provide ground-based surveillance across a large geographical area through the use of a network of ground
stations. Local servers at ground stations collect surveillance information from aircraft and send this information to a
network service for transmission to the end application (e.g. to support ATS surveillance).
1.6.3 Automatic Dependent Surveillance — Contract (ADS-C)
Automatic Dependent Surveillance — Contract (ADS-C) is based on air-ground point-to-point communications and is
supported by VDL Mode 4 through its ATN services. ADS-C would require an ATN router and an ATN network to
carry the position data to, in most cases, the ATC centre.
1.6.4 Illustrative uses of Automatic Dependent Surveillance (ADS) applications
1.6.4.1 Cockpit Display of Traffic Information (CDTI)
One of the benefits of VDL Mode 4, through its inherent support for ADS-B capability, is that it provides a pilot with
situation awareness by using CDTI. This means that a display in the cockpit can show the pilot the positions of all other
aircraft in its vicinity (VDL Mode 4 supports a range of up to 200 NM). Traffic information for the CDTI may be
obtained from single or multiple sources, including TIS-B and ADS-B. Figure I-1-6 provides an example of the CDTI
display unit in an aircraft. The concept is further elaborated in 1.6.4.2.
LS LS
LS
NS
LS = Local server
LH1234 XX1234
NS = National server
SK1234
Figure I-1-5. Ground network support for ADS-B
Figure I-1-6. Cockpit Display of Traffic Information (CDTI)

1.6.4.2 Traffic Information Service (TIS)
Traffic Information Services (TIS) is an ATM function that uses a data link to upload radar surveillance data from the
ground to aircraft in order to supplement ADS-B reports in airborne surveillance. VDL Mode 4-supported broadcast
TIS (TIS-B) will provide ADS-B-equipped aircraft with the position information2 for non-ADS-B-equipped aircraft in
order to provide situational awareness in relation to all nearby traffic. TIS-B is an important function which delivers
benefits from ADS-B in an environment where not all aircraft are equipped with ADS-B and during the transition from
a radar-based to an ADS-B surveillance environment. TIS-B reports are typically restricted to position information of
aircraft not equipped with ADS-B. Such position data are obtained, for instance, by radar. This means that CDTI on
board ADS-B equipped aircraft will predominantly be based on TIS-B early in the transition process. The proportion of
ADS-B reports will gradually increase over time. The TIS-B concept is illustrated in Figure I-1-7.
1.6.4.3 Air-to-air surveillance
Basic air-to-air surveillance is provided by ADS-B. The direct air-to-air communication (addressed) capability of VDL
Mode 4 can be used to implement trajectory negotiations between two aircraft directly. Such trajectory negotiation is
used to ensure that in the event of a conflict, the action taken by one aircraft does not conflict with the other aircraft’s
intentions.
1.6.4.4 Air Traffic Service (ATS) surveillance (air to ground)
1.6.4.4.1 The ADS-B application of VDL Mode 4 can be used by ground stations to provide ATS surveillance
(as illustrated in Figure I-1-7) in the absence of radar ground infrastructure and/or while working in conjunction with
existing radar systems.
ADS-B
ATC
TIS-B
Radar
Figure I-1-7. TIS-B concept and ATS surveillance provided by ADS-B and radar
___________________
2. TIS-B is typically uplinked on the same channel(s) used for ADS-B.
1.6.4.4.2 Track data based on ADS-B, radar, or merged (fused) ADS-B radar data are presented on ATS displays.
The quality of ADS-B data (based on precise Global Navigation Satellite System (GNSS) position and course
information) provides a more complete basis for surveillance by the ground ATS system as compared to radar (primary
radar and secondary surveillance radar). This surveillance capability is further enhanced through the provision of intent
data (which radar alone does not provide).
1.6.4.4.3 The transition surveillance architecture may use multi-sensor data fusion at the ATS centres to
transform multiple radar and aircraft ADS-B reports into aircraft track files and aircraft intent files.
1.6.4.5 Surface movement surveillance
1.6.4.5.1 Advanced Surface Movement Guidance and Control System (A-SMGCS) will become an essential
means for maintaining maximum capacity and safety in low-visibility conditions at high-density airports. As illustrated
in Figure I-1-8, A-SMGCS requires the exchange of position data between aircraft on final approach and all ground
users on and in the vicinity of the airport.
1.6.4.5.2 VDL Mode 4 provides the following:
• ADS-B data to support the ground movement surveillance system (Figure I-1-9 provides a typical CDTI
display equipment on an aircraft supporting surface surveillance);
• a two-way data link to support controller-pilot communications; and
• a communication link to assist airline operators in the surveillance and control of support vehicles.
1.6.4.5.3 VDL Mode 4 can be installed for all users on the airport surface (e.g. wide-bodied commercial aircraft,
small General Aviation (GA) aircraft, ground vehicles, etc.). Whereas typical aircraft equipment will include a display
to benefit from CDTI, such display equipment is likely to be less common in surface vehicles. However, a display
showing the location of surface vehicles and aircraft has proven to be extremely useful for team leaders coordinating
snow removal and similar activities on the airport.
1.6.4.6 Search and Rescue (SAR)
In Search and Rescue (SAR) operations, VDL Mode 4 services could be used to provide surveillance services to
support the following:
• provision of an overall situation display to support SAR activities and coordination of resources including
participating vessels; and
• identification of last known position of disabled aircraft or vessel.
1.6.4.7 Fleet management
Airline companies may take advantage of the availability of ADS-B data in order to monitor the location of their
aircraft. Whereas surveillance by ATS is restricted to a particular area of jurisdiction (either Flight Information Region
or Terminal Control Area), the geographical area in which airlines could monitor aircraft movements would be the
entire area covered by the ADS network, including airports. For proprietary reasons, data received could be restricted to
ADS-B reports from aircraft belonging to the airline’s own fleet, while data emanating from other aircraft are
suppressed. Fleet management supported by VDL Mode 4 could include direct Airline Operational Communications
(AOC) (e.g. cockpit data communication) as described in 1.7.
Figure I-1-8. Examples of position data exchange in a ground management system
Figure I-1-9. CDTI in support of surface surveillance and situational awareness

1.7 VDL MODE 4 CAPABILITIES
Table I-1-1 summarizes how the requirements for surveillance data link capabilities can be accommodated by VDL
Mode 4.
Table I-1-1. VDL Mode 4 capabilities
Scenario feature in Chapter 1 Comments
ADS-B ADS-B is the core VDL Mode 4 application and it supports the inclusion of intent
information.
ADS-C ADS-C is an ATN application and is therefore supported by VDL Mode 4. As VDL
Mode 4 operates on VHF which is constrained by line-of-sight, VDL Mode 4 is of
limited value for ADS-C over oceanic and remote regions. However, ADS-B supported
by VDL Mode 4 would continue to operate in these areas to provide AIRSAW not
supported by ADS-C.
TIS-B TIS-B uplink is based on radar tracks and is a ground-air broadcast service that is
supported by VDL Mode 4.
CDTI CDTI is based on ADS-B reports received from other aircraft and surface vehicles.
AIRSAW AIRSAW is based on ADS-B and TIS-B reports and the use of CDTI.
Ground situational awareness (pilot) Ground situational awareness is based on ADS-B from aircraft and surface vehicles and
the use of CDTI.
ATC surveillance ATC surveillance may use ADS and radar inputs. Presentation to controllers includes
ADS, radar, and fused ADS/radar tracks.
A-SMGCS ADS-B reporting from aircraft and ground vehicles supporting ATS surveillance will be
a key component of a future A-SMGCS. Runway incursion alerts may be included.
Conflict detection and resolution CD&R is based on algorithms using ADS-B and trajectory inputs. CD&R supports
(CD&R) ASAS functionality.
ASAS supports airborne applications (e.g. in-trail climb/descent and station-keeping)
based on received ADS-B and TIS-B reports, CD&R algorithms and pilot support
functionality.
Airborne Collision Avoidance For safety and redundancy reasons, ACAS should be supported additionally by a
System (ACAS) technical system independent from the one already supporting ACAS. However, ADS-B
data may be used to enhance ACAS. (See 1.6.2)
Precision Runway Monitor (PRM) PRM is an ADS-B based application.
Trajectory negotiations Addressed service. Supported through the implementation of the air-air point-to-point
protocol called ZOCOP.
AOC monitoring AOC will be able to access ADS-B reports for fleet management through the VDL
Mode 4 ground network.
___________________
Chapter 2
TECHNICAL DESCRIPTION AND OPERATING PRINCIPLES

OF VDL MODE 4
2.1 INTRODUCTION
This chapter provides a technical description of VDL Mode 4 and its operating principles. Chapter 4 provides a
supplemental description of the mechanisms for channel management by a ground station.
Note.— The term “mobile” in this and subsequent chapters is used to denote an aircraft station, aeronautical
station or mobile surface station as defined in Annex 10 to the Convention on International Civil Aviation —
Aeronautical Telecommunications, Volume II — Communication Procedures including those with PANS Status.
2.2 PHYSICAL ELEMENTS
2.2.1 Overview
2.2.1.1 Each user of the VDL Mode 4 system (aircraft, airport surface vehicle, and ground station) is equipped
with systems for determining the position of the aircraft and vehicles and the Universal Time Coordinated (UTC) time
for synchronization of the transmission and reception of position data.
2.2.1.2 Figure I-2-1 shows the typical architecture of a basic VDL Mode 4 unit. This typical architecture is the
same for airborne and ground users. The VDL Mode 4 unit interfaces with various external units such as a display unit,
computers and databases.
2.2.1.3 Actual implementation architectures may differ from the one illustrated in Figure I-2-1. While an
installation in a General Aviation (GA) aircraft may well include a single integrated transponder box in common with
this architecture, an installation in an Air Transport (AT) aircraft may, for instance, employ an external Global
Navigation Satellite System (GNSS) receiver or use navigation and time inputs from the navigation system. An AT
aircraft will almost certainly use duplicated equipment for redundancy, and may use multiple Very High Frequency
(VHF) sets and antennas to support extended communication capabilities. A fixed ground station may include a GNSS
reference receiver for the generation of augmentation uplinks. Further details of implementation architectures are
provided in Chapter 3.
2.2.2 Global Navigation Satellite System (GNSS) receiver
The Global Navigation Satellite System (GNSS) receiver provides position and time information all over the globe, and
both elements are essential for the operation of the VDL Mode 4. Typically, time inputs are obtained from GNSS, but
may also be obtained from another source (such as an on-board atomic clock; also see 2.4.3.1).
I-2-1
I-2-2 Manual on VHF Digital Link (VDL) Mode 4
2.2.3 Very High Frequency (VHF) transceiver
2.2.3.1 The VHF transceiver in a mobile installation is used to communicate the mobile’s own position and other
relevant information to other users (including ground stations) as well as to receive data from other users. The
transceiver is capable of operating on channels with 25 kHz spacing. Although stationary, a ground station will also
broadcast its location coordinates at regular intervals.
2.2.3.2 In a minimum SARPs-compliant configuration, the VHF transceiver comprises one transmitter, and two
receivers capable of monitoring different channels (typically the Global Signalling Channels (GSC)) simultaneously.
The ability to transmit and receive simultaneously on different channels will depend on the frequency separation
between the channels, the number and location of antennas on the aircraft, and the airborne radio implementation. The
exact requirement for simultaneous transmit/receive on different channels will also depend on the demands of the
various communication applications supported. Airport surface vehicles typically operate on a single channel. This may
be the same channel used by aircraft on the ground, although separate channels may be used for operational reasons.
Channel management is the subject of Chapter 4.
2.2.4 Spectrum
2.2.4.1 VDL Mode 4 operates in the aeronautical VHF spectrum band, i.e. 108 to 136.975 MHz. The
discrimination property of VHF, which allows a station to select the stronger of two overlapping signals, enables the
efficient reuse of time slots and spectrum.
2.2.4.2 A pair of GSCs will be allocated for worldwide use. These channels will be sufficient to support Air
Traffic Management (ATM) in most areas, but may have to be complemented by Local Signalling Channels (LSC) in
busy terminal areas and at high density airports in order to supplement the GSCs for Automatic Dependent Surveillance
— Broadcast (ADS-B) and the possible additional VHF channels required for uplink and downlink of application data.
2.2.4.3 The principles for assigning VDL Mode 4 channels are yet to be developed. Appropriate frequency
management techniques must be used when determining the set of physical VHF frequencies in a certain area, taking
into consideration the co-channel and adjacent channel interference (CCI/ACI) characteristics of the VDL Mode 4
transceivers.
VHF COM GNSS

Transceiver Processor Receiver
External interfaces
Figure I-2-1. The VDL Mode 4 unit

Chapter 2. Technical description and operating principles of VDL Mode 4 I-2-3
2.2.5 Communication processor
2.2.5.1 The communication processor is a computer that coordinates the use of the communication channel. It is
connected to the VHF transceiver and the GNSS receiver. The communication processor holds a virtual image of the
time slot frame in its memory. It will transmit the position information obtained from the GNSS receiver, using the
timing information from the UTC second pulse.
2.2.5.2 The communication processor controls the slot allocation for the station’s own transmissions. It
continuously updates its own slot map, and allocates slots from free slots in the slot map or reuses slots from distant
stations.
2.3 FUNCTIONAL DESIGN PRINCIPLES
2.3.1 VDL Mode 4 operation is built from the following fundamental functional elements:
• A physical layer which uses a robust modulation scheme for encoding data in each slot. The modulation
scheme is described in 2.4.1.
• A Time Division Multiple Access (TDMA) frame structure. The frame structure is described in 2.4.2.
• A timing reference providing a unique marker for the start of each communications slot. The system timing
used in VDL Mode 4 is described in 2.4.3.
• Position information used to organize access to the slots. The requirements for position accuracy are described
in 2.4.4.
• A flexible message structure that can support a wide range of data transfer and broadcast protocols. The
message structure is discussed in 2.4.5.
• A slot selection function that determines when a station can access the channel and maintains information on
the current and planned slot assignments. This is described in 2.4.6.
• Different operating modes allowing the slot access to be autonomous or controlled. Operating modes are
described in 2.4.7.
• A slot access management function controlling the use of each slot. VDL Mode 4 supports:
— autonomous access control, enabling stations to access the slot without requiring control by a master
station; and
— a number of directed access schemes enabling stations to allocate slots for other stations and for a ground
station to control overall slot access.
The type of access scheme will depend on the operational scenario. The access control schemes are described
in 2.4.8.
• ATN communication mechanisms, which provide point-to-point data link services (DLS) protocols. These are
described in 2.4.9.
• A number of link management functions that support the communications connections with other stations and
provide access to data link services on a wide range of channels. These functions are described in 2.4.10 and
include:
— synchronization bursts broadcast periodically by every mobile and ground station to maintain the
communications link (see 2.4.10.1);
— control (CTRL ) Data Link Protocol Data Units (DLPDUs) to allow a ground station to negotiate data link
connection with one or more mobile stations (see 2.4.10.2);
— link establishment, including a number of specific network entry protocols (see 2.4.10.3);
— blocking reservation protocols and ground quarantining to provide protection for important ground station
transmissions (see 2.4.10.4 and 2.4.10.5);
— GSCs to provide a worldwide standard communication channel and a means of accessing other data link
services (see 2.4.10.6);
— frequency management to allow access to supported services operating on other frequencies (see 2.4.10.7);
and
— a Directory of Services (DoS) to inform stations via the GSCs of supported services (see 2.4.10.8).
2.3.2 VDL Mode 4 SARPs documentation is based on the Open Systems Interconnection (OSI) reference model
of the International Organization for Standardization (ISO). The layered structure as applied to VDL Mode 4 is
illustrated in Figure I-2-2.
2.4 FUNCTIONAL ELEMENTS
2.4.1 Physical Layer
2.4.1.1 Modulation scheme
Note.— For additional reference, see also Annex 10 — Aeronautical Telecommunications, Volume III, Part I —
Digital Data Communication System, Chapter 6.
VDL Mode 4 supports Gaussian-filtered Frequency Shift Keying (GFSK) with a modulation rate of 19 200 bits/sec.
2.4.1.2 Noise floor estimation
2.4.1.2.1 The VDL Mode 4 receiver uses an energy sensing algorithm as one of the means to determine the state
of the desired time slot in the operational Radio Frequency (R/F) channel (idle or busy) (See Annex 10 — Aeronautical
Telecommunications, Volume III, Part I — Digital Data Communication System, Chapter 6, Note to 6.9.5.3 and also
see Part II of this document — Detailed Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4,
Chapter 1, 1.2.4.). However, because the local noise floor is not a constant, an estimator is needed.
2.4.1.2.2 One possible estimator is Tq, calculated according to the following algorithm which is a slot-oriented
version of the algorithm suggested in the Manual on VHF Digital Link (VDL) Mode 2 (Doc 9776). For any slot n for
which a station has not previously recorded a reservation and not detected a valid training sequence, update an
estimator Tq of the channel noise floor:
Tq[n + 1] = Tq[n] + k(L,Tq[n]) • (L − Tq[n]), when L ≤ Tmax
Otherwise Tq [ n + 1 ] = Tq [ n ] + k ( L ,Tq [ n ]) • ( T max − Tq [ n ])

where
L is the rms received signal level in hard µvolts calculated over the preceding slot n
Tmax is a value in the range of 15 to 30 hard µvolts (exact calibration not required)
Tq [n] is the estimate of the noise floor at slot n
and
( L / Tq ) 1
k ( L, Tq ) = max 0.01 ,
16384
The non-linear function k(L, Tq) is designed to quickly adjust to a reduced noise level and to slowly adjust to an
increased level.
2.4.1.3 Skirt mask
The characteristics of the skirt mask (adjacent channel emissions) are given in Annex 10 — Aeronautical
Telecommunications, Volume III, Part I — Digital Data Communication System where 6.2.4 covers emissions from
ground installations, while 6.3.4 covers emissions from aircraft installations.
2.4.2 Time Division Multiple Access (TDMA) frame structure
Note.— For additional reference, see Part II of this document — Detailed Technical Specifications of the Manual
on VHF Digital Link (VDL) Mode 4.
2.4.2.1 In VDL Mode 4, channel time is divided into fixed length time slots. A “superframe”, which is an
important term used in the VDL Mode 4 channel management, consists of a group of slots that span a period of 60
seconds. The superframe contains 4 500 slots (equivalent to 75 slots per second). This is illustrated in Figure I-2-3.
2.4.2.2 Each time slot is accessible for receiving or transmitting by any station communicating on the data link.
One position report will occupy one time slot on the data link. Other transmissions can occupy more than one slot,
depending on the application. The maximum allowed length of a transmission is 1 second. A transmission of this
maximum length would span 75 slots.
2.4.3 System timing
Digital Data Communication System and Part II of this document — Detailed Technical Specifications of the Manual
VDL Mode 4 requires time synchronization for basic station access without mutual interference. The time standard for
VDL Mode 4 is UTC. The time is primarily based on GNSS but other sources may be used as long as they can be
related to UTC. The timing concept for VDL Mode 4 is designed to satisfy the most stringent accuracy, availability,
continuity and integrity requirements for aviation.
2.4.3.1 System timing techniques
2.4.3.1.1 Different techniques can be used to yield an estimate of UTC. Examples include:
1. GNSS. A user equipped with a GNSS receiver can determine the UTC time to within 400 ns (2 sigma). This is
the primary time source for VDL Mode 4, making it independent from ground stations.
ATN
VDL Mode 4
Subnetwork layer
Link control data and

parameters DLPDUs and DLS user
parameters
LME sub-layer
Link establishment and
Synchronization bursts maintenance (exchange
Peer entity contact table identity protocols)
Net entry Directory of Services
CTRL data, DLS link
management parameters
Synchronization burst data,
VSS user
parameters DLS sub-layer
Mode 4 link initialization VDL Mode 4
Re-transmission data transfer protocol specific
DLPDU error detection (ground-air and air-air)
DLS burst formatting applications
Burst and DLPDU data, Received burst and
VSS user parameters DLPDU data, VSS user
status information
VSS sub-layer
Burst encoding Reservation table update
Burst formatting Reserved access protocols Burst decoding
Slot selection Random access protocol Data error detection
Reservation table Fixed access protocols
Transmission queue management
Burst, time to send, Received burst and frame data,

access control Unsent random transmissions
(reserved or random)
MAC layer Slot occupied/

not occupied processing
Slotted TDMA Transmission formatting
Time synchronization Arrival time
Burst error detection
Transmission, nominal Received transmission,
start of transmission channel busy/idle
notification
Physical layer
Transmission timing Data decoding
Frequency control Data encoding Signal quality notification
Transmitter shutdown Channel sensing
Arrival time
VHF radio
Figure I-2-2. OSI layering in VDL Mode 4

2. Ground station network. VDL Mode 4 ground stations can be used to yield multiple air-to-ground
communication and surveillance coverage. These ground stations are synchronized to UTC via GNSS time
transfer, atomic clocks or other techniques, and broadcast synchronization messages slaved to UTC. The
synchronization messages yield time determination capability for the users with microsecond accuracy. VDL
Mode 4 ground stations transmit synchronization messages on a regular basis to ensure that correct time is
available.
3. Other on-board timing sources, including atomic clocks, may become available for airborne use.
4. Synchronization from other users. A user who is unable to acquire GNSS or a VDL Mode 4 ground station (in
any combination) can rely on other synchronized users in the airspace. This will incur increased time
determination errors but the system time synchronization is maintained, and simulations have shown that the
impact on system performance is negligible. One synchronized user can provide timing in a large area.
5. Floating network. This functionality is similar to synchronization from other users, with the difference being
that all users have lost the GNSS or ground-derived UTC time synchronization. In this case, users will
continue to broadcast position reports and attempt to synchronize on other users. In the absence of
synchronization, each user’s clock will tend to drift. Users will tend to correct their own clocks toward the
“average drift rate” of the user population as a whole. This will preserve a degree of system synchronization
until GNSS or ground-derived time sources can be restored. This is to be considered as a fallback mode that
preserves the basic communications functionality for a substantially longer period of time than is feasible
without coordination.
2.4.3.1.2 The characteristics of the integrated timing include:
• a single worldwide time standard, UTC, is used for all VDL Mode 4 data link applications;
• synchronization can be based on existing techniques (GNSS, VDL Mode 4, and possibly atomic clocks);
• the integrated timing is open-ended and expandable, and future timing systems can be added;
• the integrated timing is seamless in all airspaces and not related to regional boundaries;
1 minute
13.33 ms
Slot 1 Slot 4 500
Current
superframe
Slot 4 501 Slot 9 000

Current
superframe + 1
Legend: Current slot
Figure I-2-3. GFSK superframe

• individual States and Regions are free to choose a low cost communications infrastructure with dispersed
VDL Mode 4 ground stations slaved to GNSS, or a higher cost and higher capability infrastructure with
multiple overlapping coverage and VDL Mode 4 ground stations operating atomic clocks; and
• fallback techniques that require users to use their best estimate of UTC.
2.4.3.1.3 For operation of a VDL Mode 4 system, the SARPs define three categories of timing accuracy
according to the origin and reliability of the timing source:
• The highest accuracy of time source, referred to as primary timing, typically relies on external sources of time.
A user will normally obtain primary time from a GNSS receiver, and this will always be the source of choice,
except when GNSS time is not available. Primary time has the most stringent accuracy requirements.
• When primary time is not available, secondary timing will be used, with less stringent accuracy requirements.
Secondary time may be obtained from other VDL Mode 4 stations including ground and airborne stations
which have (certified) primary time. Secondary time may, for example, be obtained by observing the slot
boundaries used in transmissions by nearby aircraft.
• When neither primary nor secondary timing sources are available, tertiary time sources will be used, with the
least stringent accuracy requirements, in which the aircraft makes the best approximation it can to align its
own slot map up to those of its neighbours.
Note.— Secondary and tertiary timing modes are regarded as failure modes.
2.4.4 Position information and synchronization bursts
In VDL Mode 4, channel access control is based on position information contained in synchronization bursts by mobile
and ground stations. Position information is obtained from GNSS, or in the case of aircraft, it may be obtained from
other on-board sources of position information.
2.4.5 Message types and structure
2.4.5.1 VDL Mode 4 provides a library of messages that can be used to support a wide variety of data transfers
and broadcasts. The VDL Mode 4 generic message structure is shown in Figure I-2-4. This message structure can be
applied to any message type transmitted on the VDL Mode 4 data link. It also accommodates the various slot access
protocols described in 2.4.8 and the channel management mechanisms for ground stations described in Chapter 4.
2.4.5.2 The flexible message structure allows a station to transmit messages while simultaneously placing
reservations for future slot usage.
2.4.5.3 The following message types are used for the management of communications on the VDL Mode 4 data
link:
BURST FORMAT
—— Start flag
—— Reservation field —— Reservation ID
—— Extended reservation ID
—— Reservation data —— Null reservation
—— Source address —— Periodic broadcast reservation —— Periodic time out
—— Version number —— Periodic offset
—— Incremental broadcast reservation Incremental offset
Combined incremental/periodic Incremental offset (periodic offset = 3)

broadcast reservation
—— a/d flag —— Big negative dither Negative dither
—— Reservation ID —— Unicast request reservation —— Destination address

—— Response offset
—— Priority
—— Source/destination
—— Information request reservation —— Destination address

—— Response offset
—— Frequency
—— Length
—— Acknowledgement offset
—— Directed request reservation —— Additional reservation data —— Autotune —— Directed time out
reservation
—— Destination address —— Frequency
—— Plea/response flag —— Length
—— Nominal update rate —— Directed offset
—— Override flag
—— Second frame blocking reservation —— Size —— Receiver control
—— Superframe blocking reservation —— Destination address —— Plea response —— Additional slots

—— Block length —— Offset to first reserved slot
—— Re-broadcast offset
—— Block time out
—— Block start
Figure I-2-4.
—— Block offset
—— Block repeat rate
—— Message field —— Message ID —— Response —— Destination address
—— Synchronization Fixed information field —— TCP/SVQ change flag

—— CRC Variable information field —— 0 Basic —— Baro/geo altitude
—— End flag
—— 1 High dynamic —— CPR Format even/odd
—— 2 Full position —— Position intgrity value
—— 3 Basic ground —— Latitude
—— 4 UTC time —— Base altitude
—— 5 Single slot SVQ —— Longitude
VDL Mode 4 burst structure

—— 6 to 7 Available for future use —— Time figure of merit
—— 8 Two-slot TCP/SVQ —— Data age
—— 9 Single slot TCP —— Information field ID
—— A0 Available for future use —— ID extension 1 – n
—— A1 Aircraft data
—— A2 to A9 For future use —— AAA Extension
—— Compressed DLS —— RTS/INFO type 1 —— AAO High resolution —— AAB to AAF For future use
DLPDU —— RTS/INFO type 2 —— AA1 to AA9 For future —— AB to AF For future use
—— B to E For future use
—— F No information field provided
—— General reponse —— Confirm/fail

—— Application specific ID
—— General request —— VSS user specific parameter —— Synchronization request —— Back-off delay
—— Requested message ID —— Others —— Error type
—— VSS user specific parameter
—— Unicast DLS DLPDU —— SZOM
—— INFO
—— Broadcast DLS DLPDU —— 1-byte UDATA —— CTRL
—— 2-byte UDATA —— INFO_CTS
—— 3-byte UDATA —— CTRL_CTS
—— INFO_ACK
—— CTRL_ACK
—— UDATA_CTS
—— FRMR_ACK
—— INFO_RTS
—— CTRL_RTS
—— UDATA_RTS
—— FRMR
—— DM/DISC
—— DM/FRMR
Note.— Vertical dashed lines indicate an “or” relationship between fields.

Vertical solid lines indicate “and” relationship between fields.
I-2-9
ADS-B messages, transmitted regularly by both mobile stations and fixed ground stations, are used to support both
communications management and the ADS-B service. These synchronization bursts contain a) a fixed part that is used
for general communications management and for providing position for slot-selection algorithms, and b) a variable
part in which additional ADS-B elements may be included. (See Appendix A to Chapter 2 for detailed field
descriptions.)
General request messages are used to instruct an aircraft to change its reporting characteristics (rate, channel,
autonomous/controlled mode) or to instruct it to report periodic or on-demand airborne parameter information. Ground
stations can send a general request message containing an autotune reservation field to direct mobiles to transmit in
particular slots, or at assigned rates and, if required, on different channels.
Blocking messages are used by a ground station to reserve a series of slots for exclusive use by the ground station so as
to protect the transmitted information from unintentional interference from other transmitters.
Network entry messages are used by a mobile to enter the channel quickly. The messages use the big negative dither
(BND) and/or plea response protocols.
Directory of Services (DoS) messages are used to give information about the VDL Mode 4 services available on
different channels.
2.4.6 Slot selection
2.4.6.1 An important feature of VDL Mode 4 is the method used to select slots for a new transmission or for
placing reservations for future transmissions. When a channel is not busy, slot selection is straightforward since a slot
that has not been previously reserved by another station can be easily found. When a channel becomes busier such that
unreserved slots are harder to find, VDL Mode 4 allows a station to use a slot previously reserved by another distant
station. The result is that the coverage area of a station reduces in range gracefully as the channel becomes busy and
there is no sudden reduction in the ability to communicate. A further advantage is that slot selection is carried out by all
stations and there is no reliance on a ground station to carry out channel resource management, although in some
circumstances, a ground station may be used to allocate slots (see Chapter 4).
2.4.6.2 Figure I-2-5 illustrates the slot selection process, which has the following stages:
1) An application wishing to send data or to place a reservation to send data in the future first specifies a range of
candidate slots from which a slot will be chosen.
2) The station then derives a list of available slots. The available slots are a subset of the candidate slots and
consist of slots that are either a) unreserved, or b) although previously reserved by another station, can be
made available for use because of special selection rules (which are discussed in 2.4.6.3). Note that before
finally selecting a slot, it is important to derive a number of available slots, typically 4, in order to reduce the
possibility of more than one station selecting the same slot. For example, if there were only one unreserved
slot among the candidate slots, there would be a high chance of more than one station choosing that slot,
causing garbling of that slot.
3) A slot is selected randomly from the available slots.
2.4.6.3 The special rules for the reuse of previously reserved slots are based on two guiding principles:
1) Robin Hood principle; and
2) Co-channel interference (CCI) protection.

Stage 1: Application specifies candidate slots
Candidate slots
Stage 2a: Station identifies available slots starting with unreserved slots
Candidate slots
Stage 2b: Station identifies further available slots from slots reserved by distant users
Candidate slots
Stage 3: Station randomly selects a slot from the group of available slots
Candidate slots
Legend:
Available Selected
Reserved
Unreserved
Figure I-2-5. VDL Mode 4 slot selection process

2.4.6.3.1 The Robin Hood principle allows a station operating on a busy channel to use slots previously reserved
for broadcast transmission by another station as long as the slots reserved by the most distant stations are chosen in
preference to those of nearer stations. This results in a graceful reduction in the broadcast range (cell radius) of a station
on busy channels as illustrated in Figure I-2-6.
2.4.6.3.2 Co-channel interference (CCI) protection generalizes the Robin Hood principle to allow slots
previously reserved for point-to-point communication between two stations to be used by another station. CCI
protection is based on relative aircraft distance and assumes that even though stations may be in radio range of each
other, each station can successfully discriminate the desired (stronger) signals over the undesired (weaker) ones. VDL
Mode 4 defines a measure of the CCI on the basis of free space attenuation of signals with distance. For GFSK
modulation, discrimination can occur as long as interfering signals are separated by 12 dB or by the equivalent of
approximately 4 times the range ratio between interfering sites.
2.4.6.3.3 As shown in Figure I-2-7, Station 1 wishes to communicate with Station 2 but is unable to find a
suitable free slot. Station 3 has reserved a slot to communicate with Station 4. Since Stations 3 and 4 are more distant
stations, Station 1 considers using the same slot but must first check that the following conditions hold:
• The transmission by Station 1 must not prevent Station 4 from being able to decode the transmission from
Station 3. Hence, by applying the CCI criteria, the range from Station 1 to Station 4 must be greater than four
times the range from Station 3 to Station 4 in order to achieve high delivery reliability.
• Station 2 must be able to decode the transmission from Station 1 without being prevented by the transmission
from Station 3. Hence, by applying the CCI criteria, the range from Station 2 to Station 3 must be greater than
four times the range from Station 2 to Station 1 in order to achieve high delivery reliability.
If both these criteria are met, then Station 1 can use the slot.
Initial cell Resulting cell
Figure I-2-6. Graceful shrinkage of cell radius of a broadcast station

resulting from use of the Robin Hood principle
Station 2 Station 4
Station 1 Station 3
Figure I-2-7. Co-channel intervention protection
2.4.7 Operating modes
2.4.7.1 Introduction
2.4.7.1.1 Slots can be allocated autonomously (referred to as autonomous reporting) or via master control
(directed reporting). When reporting autonomously, a mobile station transmits in self-selected slots. In directed
reporting (or ground-controlled mode), a mobile station is instructed by a ground station to transmit at a certain rate, on
a certain channel, and/or in certain slots. Each mode utilizes various slot access protocols as described in 2.4.8.
2.4.7.1.2 When a mobile station allocates slots autonomously, it will primarily select unused slots. If the data link
is saturated, it will employ the slot reuse algorithm described in 2.4.6 and reuse slots occupied by a distant station
whose position is not critical to the mobile allocating slots. Autonomous operation employs the self-organizing
capability of VDL Mode 4 which allows a mobile station to enter the system, resolve communication conflicts and
dynamically share the data link resource with other users. It also enables the system to operate without the presence of
a ground infrastructure.
2.4.7.2 Autonomous mode
2.4.7.2.1 Autonomous operational scenario
2.4.7.2.1.1 In an operational scenario using autonomous mode (as illustrated in Figure I-2-8), there is no VDL
Mode 4 ground infrastructure present. Communication can take place between any users within communication range
(cell) using the self-organizing protocol. This operational scenario could be used in low-density airspace, such as
oceanic and remote continental areas. All communications use the globally coordinated GSCs, described in 2.4.10.6.
This scenario uses VDL Mode 4 specific services (VSS) which provide broadcast and end-to-end communications
between aircraft (air-to-air).
2.4.7.2.1.2 System time is typically provided by the GNSS function. If the GNSS function is lost, then time can
be derived from one of the other techniques described in 2.4.3. Time synchronization from an external source can also
be used to provide a second order of navigation function as a back-up for GNSS or other on-board navigation function.
Figure I-2-8. Autonomous operational scenario
2.4.7.2.2 Passive ground station operational scenario
The passive ground station operational scenario operates in a similar manner to the autonomous operational scenario
described in 2.4.7.2.1, but in this case, it includes ground stations. These ground stations receive position information
and other communications from mobiles and can use this information to provide Air Traffic Services (ATS)
surveillance based on ADS-B. This mode is well suited for the establishment of low-cost ground surveillance systems
in remote regions.
2.4.7.2.3 Slot access controlled by another mobile station
A mobile station can request data from another station (mobile or ground station) and reserve slots for the response.
This method could be used, for instance, to request additional intent data from a proximate aircraft, or to request MET
data from the ground.
2.4.7.3 Directed mode
This mode is ground-controlled and implies that a ground station controls the overall access to a slot or group of slots.
Whereas the autonomous mode is the preferred mode for airborne en route use, the directed mode may be the preferred
option for surface surveillance or terminal areas in which only one ground station is involved, the coverage area is
limited, and the risk for saturation of the data link is low.
2.4.8 Slot access management
VDL Mode 4 supports a number of slot access mechanisms which usually include information on slot reservation.
These include both autonomous and controlled access to data link resources. The most important autonomous access
scheme for the overall operation of VDL Mode 4 is the “periodic broadcast” protocol. In addition to this, VDL Mode 4
supports several other protocols for a number of broadcast and end-to-end data link communications. The channel
management mechanisms for a ground station are detailed in 4.3.1. Aeronautical Telecommunications Network (ATN)-
compliant communication mechanisms are addressed in 2.4.9.
2.4.8.1 Periodic broadcast protocol
2.4.8.1.1 Introduction
2.4.8.1.1.1 The periodic broadcast protocol supports the broadcast of position and identity information by a
station to all other stations in the vicinity and allows the system to operate effectively regardless of the presence of
ground stations. The protocol is illustrated in Figure I-2-9.
2.4.8.1.1.2 Each station transmits a burst that contains the following information required by the periodic
broadcast protocol:
• the station ID;
• position information; and
• information controlling the periodic broadcast protocol, i.e.:
— the periodic time out value indicating, in combination with the periodic offset parameter, how many more
superframes will be held by the reservation; and
— the periodic offset (range of −128 to +127), indicating the slot to which the reservation will move when
the slot time out expires.
2.4.8.1.1.3 Every other station receiving a periodic broadcast message can build up a “reservation table” using
this information and a time stamp derived from the slot in which the information was received. In the simplest form this
allows all stations to build up a picture of all other stations within range. The information also allows the other stations
to control their own access to the data link as described in 2.4.8.1.1.4.
2.4.8.1.1.4 In the simple mechanism outlined in 2.4.8.1.1.3, all stations occupy a particular slot or series of slots
in each superframe. When transmitting in a particular slot (indicated as the “current” slot in Figure I-2-9), the stations
indicate a reservation for the same slot in the next superframe by using the slot time out counter. They also indicate
which slot they will be moving to in the future superframes via the periodic offset parameter.
2.4.8.1.1.5 The assignment to slots is dynamic in two ways:
1) Current stations change their slot at regular intervals of 4 and 8 minutes. The purpose for this is to ensure that
as two aircraft fly closer to each other, they do not continue to share the same slot or slots and garble each
other’s position reports. In such situations, requiring aircraft to move randomly to new slots greatly reduces
the probability of lost position reports.
2) New stations coming into coverage will continually enter the slot structure with their own broadcasts.
2.4.8.1.1.6 To select slots in the periodic broadcast protocol, the slot selection procedure described in 2.4.6 is
applied in the following ways:
• Station A selects first from slots at level 0 through level 2 including only the potentially reserved slots that are
considered unoccupied. Potentially reserved slots are ordered in increasing order of power when selecting at
level 0. If less than Q4 slots are selected at this stage, Station A then reapplies selection at level 0 through
level 2, this time including also the potentially reserved slots that are considered occupied, in increasing order
of power. If still less than Q4 slots are selected at this stage, Station A continues selecting slots from level 3
until Q4 slots are found.
2.4.8.1.1.7 The slot selection concept relies on the fact that, in channels in which the majority of reservations are
made by the periodic broadcast protocol, it is highly likely that a garbled slot contains reservation information leading
to “potential reservations” in subsequent superframes. The consideration of potential reservations between level 0 and
level 2 and, in particular, the classification as occupied or unoccupied on the basis of a received power check, has been
shown in simulations to improve performance by forcing new transmissions to avoid slots which already appear to be
garbled.
Station 1 transmits
periodic broadcast
reservation
Current superframe
Reserved for Station 1

broadcast
Current superframe + 1

broadcast
Offset after Reserved for Station 1

reservation time out broadcast
Legend:
Current slot
Reserved slot
Figure I-2-9. Periodic broadcast protocol

2.4.8.1.2 Slot changing for current stations (continuous change of slots)
Current stations maintain their slot reservation for a randomly chosen time period of 4 to 8 minutes. Towards the end of
the time out period, the station selects a new slot by using the slot selection method described in 2.4.6, where candidate
slots are grouped around each nominal slot. When a new slot is found, the station indicates in the slot offset field of the
periodic broadcast reservation burst to which slot it will move. When the current slot has timed out, the station moves
to the new slot.
2.4.8.2 Incremental broadcast protocol
2.4.8.2.1 The incremental broadcast protocol is used by applications which must broadcast data over a short
period of time, typically within the same superframe. Each data broadcast can also be used to reserve a slot for the next
broadcast. The protocol is illustrated in Figure I-2-10.
2.4.8.2.2 When transmitting a burst containing an incremental broadcast reservation, the station specifies the
incremental offset (value of 1 to 255). The slots reserved for the next data broadcast are offset from the current slot by a
factor of 4 times the incremental offset (io) value.
Note.— The periodic broadcast and incremental broadcast protocols can be combined (see 2.4.10.3).
2.4.8.3 General request protocol
Station 1 transmits Reserved for Station 1

incremental broadcast broadcast + incremental Reserved for Station 1
reservation broadcast reservation broadcast
Current superframe
Incremental offset
Reserved slot
Note.— Illustration shows delivery of two data or position reports.
Figure I-2-10. Incremental broadcast protocol

2.4.8.3.1 A ground station uses the general request protocol together with an appropriate reservation field to
direct an addressed mobile to:
• change the channel on which it transmits ADS-B or other messages;
• change the rate at which it transmits ADS-B or other messages; and
• transmit a one-off ADS-B or other message.
This mechanism is used to prevent overload of channels, to provide suitable reporting rates for different operational
situations, and to put different services on different channels.
2.4.8.3.2 A general request protocol specifies the content of a requested synchronization burst and may also
contain other information to control ADS-B reporting. The channel and reporting rate for the requested synchronization
burst depends on the reservation field used in the message:
• Unicast request protocol (see 2.4.8.4). The mobile station will respond with a single burst of the type
requested in the specified slot or block of slots on the specified channel. This might be used to extract on-
demand Downlink of Airborne Parameters (DAP) information.
• Directed request/Autotune reservation (see 2.4.8.6). The mobile station responds with multiple bursts of the
type requested by using the periodic broadcast protocol. The mobile may be instructed to perform directed or
autonomous reporting. If performing directed reporting, the mobile is instructed to which slots it has to
transmit. If reporting autonomously, the rate of reporting may be specified. The channel(s) on which to
transmit is also specified. This reservation is used to control ADS-B and periodic DAP reporting
characteristics.
• Information transfer request protocol (see 2.4.8.7). The mobile station responds with a burst occupying a
block of slots reserved by the requesting station. In addition, a slot is reserved for acknowledgement by the
requesting station.
2.4.8.4 Unicast request protocol
2.4.8.4.1 The unicast request protocol is used by a station that requires a response from another station.
Figure I-2-11 illustrates the protocol. Station 1 requests information from Station 2, simultaneously issuing a
reservation for Station 2’s response.
2.4.8.4.2 When transmitting a burst containing a unicast request reservation, the station specifies the following
parameters:
• destination address (d): this identifies the station from which a response is requested;
• response offset (ro) (value of 0 to 4 095): the reservation for a response is offset by an amount equal to the
value of the response offset from the current slot;
• length (lg) (value of 0 to 255): this indicates the length of the response; and
• priority (p) (value of 0 to 15): this indicates the priority of the response data.
Station 1
Request for information Station 2

and issue reservation
for station 2’s response
Station 2 response
Station 1 transmits Reserved for Station 2

unicast request response or
reservation acknowledgment
Current superframe
response offset
Reserved slot
Figure I-2-11. Unicast request protocol
2.4.8.4.3 A variation of the unicast request protocol also allows a station to reserve a slot for a later transmission
by the same station to a destination station. This is controlled by the setting of the source/destination (sdf) flag (sdf = 0
which means that the slot is reserved for a response by the destination station; sdf = 1 means that the slot is reserved for
the source station). The source and destination are relative to the initial state, thus the source is the station that initially
transmitted the unicast and the destination is the station to which the unicast was addressed.
2.4.8.5 Directed request/Plea response reservation
The directed request protocol may be used to respond to a plea for a list of slot reservations from another station
seeking network entry (see 2.4.10.3). In this case, the directed request protocol assumes the plea response burst format
with the plea response flag (pr_flag) set to 1 (pr_flag = 1).
2.4.8.6 Directed request/Autotune reservation protocol
Station 1
Station 1 reserves Station 2

slots for station 2
Broadcast of
regular position
and data reports
Station 1 transmits directed

request reservation Reserved for Station 2 Reserved for Station 2
reserving slots for station 2 broadcast broadcast
Current superframe
Reserved for Station 2 Reserved for Station 2

broadcast broadcast

broadcast broadcast

broadcast broadcast
Legend:
Current slot
Reserved slot
Figure I-2-12. Autotune reservation protocol
2.4.8.6.1 The autotune reservation protocol is a directed request protocol with the plea response flag (pr_flag) set
to 0 (pr_flag = 0). The directed request protocol can also be used by one station to request that another station transmit
in particular slots and/or at a particular rate. Thus the protocol can be used by a ground station to control the broadcasts
of a group of mobiles in a geographical region that is under its jurisdiction. In this case, the directed request protocol
assumes the autotune reservation burst format with the plea response flag (pr_flag) set to 0 (pr_flag = 0). The autotune
reservation protocol is illustrated in Figure I-2-12.
2.4.8.6.2 When transmitting a burst containing an autotune reservation protocol (directed request with
pr_flag = 0), the station specifies the following parameters:
• frequency (f): identifies the frequency for the transmission of the required data;
• destination address (d): this identifies the station which is being directed;
• directed offset (do): this indicates the first slot in which the station should broadcast;
• nominal update rate (nr) (value of 1 to 60): this indicates the number of reservations to be made per
superframe;
• directed time out (dt) (value of 0 to 15): this indicates the number of superframes for which the reservation
shall be maintained;
• override flag (or) (value of 0 or 1): this indicates whether a new reservation placed by a ground station will
override all previous reservations placed by the same ground station;
• length (lg) (value of 0 to 511): this indicates the length of the reserved block of slots; and
• receiver control (rcvr): this provides control information for the protocol.
Autotune reservations can be cancelled by setting the directed time out (dt) parameter to 15 (dt = 15).
2.4.8.7 Information transfer request protocol
2.4.8.7.1 The information transfer request protocol is used by an application to obtain a data series from another
application. Slots are reserved for transmission of the requested information and for an acknowledgement by the
requesting application. The protocol is illustrated in Figure I-2-13.
2.4.8.7.2 When transmitting a burst containing an information reservation, the station specifies the following
parameters:
• frequency (f): the station can specify the channel on which the information transfer should take place;
• destination address (d): this identifies the station from which a response is requested;
• response offset (ro) (value of 0 to 4 095): this indicates the start of the reserved block for the response relative
to the current slot;
• length (lg) (value of 0 to 255): this indicates the length of the response block; and
• acknowledgement offset (ao) (value of 0 to 127): the reservation for an acknowledgement to the information
block by the requesting station is offset by an amount equal to the value of the acknowledgement offset from
the current slot.
2.4.8.8 Random access protocol
2.4.8.8.1 Random access protocol is used by applications when there is no prior reservation. In order to minimize
slot collisions, a station which wishes to transmit by means of random access protocol and which finds a suitable slot
according to slot selection criteria described in 2.4.6 will apply a “dice-throwing” technique to decide whether or not to
transmit in that slot. The purpose of the “dice-throwing” is to reduce the possibility of two stations simultaneously
deciding to transmit at once. In the terminology of SARPs, the “dice-throwing” is referred to as a p-persistent algorithm.
The protocol is illustrated in Figure I-2-14.
2.4.8.8.2 It should be noted that the p-persistent algorithm is based on the one used in the VDL Mode 2 system
except that the parameters are changed. In particular, the value of the p in the p-persistent algorithm has been increased
to p = 64/256 because the number of opportunities to transmit has been reduced. This thus requires a recalculation of
the parameter VS3 which determines the maximum consecutive transmit opportunities for which the station, using the
“dice-throwing” process described in 2.4.8.8.1, chooses not to transmit. When VS3 opportunities have occurred, the
station then transmits regardless of the p-persistent factor. Following the logic used in the VDL Mode 2 system, VS3 is
set in such a way that the probability of deciding not to transmit VS3 times in a row is less than 0.1 per cent. Therefore
(1 – p)VS3 = 0.001. This results in a value of VS3 = 24 if p = 64/256.
Station 1
Request for Station 2

information
Transmission of requested
information (sent in 4 slots)
Station 1 acknowledgement
Reserved for Station 2 to

transfer 4 slots of information
Station 1 transmits
in response to Station 1's
information transfer Reserved for Station 1
request
reservation acknowledgement
Current superframe
Reserved slot
Note.— Illustration shows delivery of information occupying 4 slots.
Figure I-2-13. Information transfer request protocol

Station 1
Transmission of broadcast or
directed data (sent in 3 slots)
Gap too small Reserved for

Reserved for Reserved for for Reserved for
other station other station user 1 data other station other station
Current superframe
Legend: Reserved
Note.— Illustration shows delivery of data occupying 3 slots.
Station 1 sends data
Figure I-2-14. Random access protocol
2.4.8.9 Fixed access protocol
Ground stations can be programmed to transmit at pre-defined times regardless of reservations on the channel. For
example, this allows a ground station to transmit regular data uplinks of DoS and channel control messages. This mode
of operation is supported by ground quarantining (described in 2.5.2.4) which prevents mobile users from reserving
slots adjacent to ground station reservations under certain circumstances. See Chapter 4 (Channel Management).
2.4.8.10 Slot conflict procedures
2.4.8.10.1 Slot reservation conflicts are expected to occur as a result of slot reuse under CCI protection. In the
event that a reservation conflict is detected, the slot selection criteria described in 2.4.6 are reapplied to determine
whether the slot could still have been selected given the knowledge of the new conflicting reservation. If so, the station
keeps the same reservation. If not, a number of rules are applied to determine whether or not a station must move its
reservation. The detailed slot conflict rules are described in 2.4.8.10.2 and 2.4.8.10.3.
2.4.8.10.2 Slot conflict procedures are used in cases where a station, A, has placed a reservation to transmit in a
particular slot or slots. Station A then receives a burst from another station, B, which contains a reservation for the
same slot or slots. Station A must then reassess the situation as follows:
1) If the conflicting reservation from Station B also requires Station A to transmit, then Station A transmits a) the
response with the higher priority, or b) in case of equal priority, the first requested transmission.
2) If Station A no longer needs to transmit in the existing reservation or does not have the necessary information
to transfer, then it will not transmit in the slot.
3) If the existing reservation for Station A to transmit was made by a station other than Station A (i.e. by a
unicast request protocol where the source/destination flag is set at “0” (sdf = 0), information transfer, or
directed request reservation), then Station A transmits in the slot in accordance with the existing reservation.
The reason for this is that it is assumed that the station that originally made the reservation for Station A to
transmit has sufficient information to have correctly asked Station A to transmit in the slot. It is undesirable
for Station A to override that decision (i.e. the control remains with the station that originally made the
reservation).
4) If the existing reservation for Station A to transmit was made by Station A itself, then Station A will first use
the slot selection rules to see whether the reservation is still valid. If the reservation is still valid because of
CCI criteria, then the transmission of Station A will still be received by the required destination stations.
Station A will then transmit according to its existing reservation. If the slot is no longer available, then the
decision as to whether to transmit or not will be based on the type of reservation protocol applicable to the
original and conflicting reservations.
2.4.8.10.3 For the last stage in the process, Table II-1-13 in Chapter 1 of Part II of this document, namely
Detailed Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4, describes how the decision to
transmit depends on reservation type. The “design philosophy” for this table is as follows:
• If the protocol used by Station A will result in transmission over several superframes (i.e. a periodic broadcast)
and the conflicting reservation will only last for one superframe (i.e. an incremental, BND, unicast or
information transfer), then the conflict will only last in the current superframe and Station A may very well
transmit because any station that does not receive the next transmission will still receive an update in the next
superframe.
• In the previous case, if the conflicting reservation is another protocol that lasts for several superframes (i.e.
another periodic broadcast), the conflict will last for several minutes. Hence, Station A will not transmit but
will move its reservation. If it has the time, it will announce its intention. If not, it will use random access to
re-establish a stream.
• If Station A’s transmission is a “one-off” transmission in the current superframe, the conflict will mean that it
will not be heard by the destination station(s). Hence, Station A will not transmit and will make a new
transmission using the re-transmission and random access procedures.
2.4.8.11 Re-transmission procedures
2.4.8.11.1 If a station transmits a burst containing a reservation for another station and does not receive a
response by the expected slot, the station either:
• re-transmits the burst, or;
• informs the user how many attempts have been made to transmit, or;
• informs the user how long it has been since the last attempt to transmit was made.
2.4.8.11.2 The first of these options, re-transmission, will continue until a certain number of attempts (also
known as Q5num) have been made to transfer the information (set by the parameter Q5num) or until a certain time has
elapsed (set by Q5wait, also known as maximum time to wait for a reply), at which point the user will be informed that
transmission has been unsuccessful. The rate of re-transmission depends on the current channel usage and on the
number of times that a burst has been re-transmitted.
2.4.9 Aeronautical Telecommunication Network (ATN)

communication mechanisms
2.4.9.1 Data link service (DLS) protocols
The data link service (DLS) provides a point-to-point protocol supporting both ground/air and air/air exchanges. For
ground/air exchanges, connection management is handled by the Link Management Entity (LME), using a Negotiated
Set-Up Connection-Orientated Protocol (NSCOP). For air/air exchanges, the DLS defines a Zero Overhead
Connection-Orientated Protocol (ZOCOP) with link establishment and disestablishment controlled by timers, allowing
rapid link negotiation between aircraft. Essentially, the DLS is a simple information exchange protocol which provides:
a) explicit acknowledgement of each DATA packet (or DLPDU).
b) mechanisms to provide data transfer in reserved slots, thus avoiding loss rates and delays associated with
random access. This includes the ability to link sequences of DATA packets, providing continuous transfer in
reserved slots.
c) packet fragmentation that allows long user DATA packets to be transferred across the link in fragments
optimally matched to the link conditions.
d) duplicate detection and suppression via a simple toggle bit mechanism.
e) explicit support for the 15 priority levels defined for the ATN, including the ability to send high priority
messages in the middle of a fragmented low priority message.
Furthermore, as illustrated in Figure I-2-14a, the DLS:
• provides services to external users in order to support point-to-point, multi-cast and broadcast
communications;
• provides services to the LME to support link management;
• supports services between peer DLS; and
• uses the services of the VSS in order to send and receive messages.
DLS user
LME DLS Peer DLS
VSS
Figure I-2-14a. DLS services
Figure I-2-14b illustrates the use of various services provided by the DLS and VSS in supporting the DLS user and the
LME.
2.4.9.1.1 Data link service (DLS) burst format
2.4.9.1.1.1 A DLS burst consists of:
• burst id (fixed or variable), and
• one or two DLPDUs.
The structure of the normal unicast DLS burst is shown in Table I-2-1. The broadcast DLS burst (UDATA) structure
differs from that of the unicast DLS burst described in Table I-2-1 in that the burst ID contains a fixed part identifying a
broadcast INFO (UINFO) or a broadcast CTRL (UCTRL) burst, and a variable part identifying the different UINFO or
UCTRL DLPDU types.
2.4.9.1.1.2 The DATA DLPDUs are defined as follows:
• CTRL — used by the LME to establish and maintain links for NSCOP communication.
• INFO — contains a user data field.
• UDATA — enables the broadcast of user data — it is unacknowledged.

Table I-2-1. Unicast DLS burst format
Bit Number
Description Octet 8 7 6 5 4 3 2 1
Burst id (fixed) 5 res res res res 1 1 0 1

6
7
DLS DLPDU 8 Filled in according to the particular DLPDU used
9
10
Note.— “res” denotes currently unused.
DLS User LME
Directed data Broadcast data

(INFO, CTRL) (UDATA)
Connection management (IB/SZOM)

Message segmentation (M-bit)
Delivery order (T-bit)
DLS
Short Long Short Long

acknowledged acknowledged unacknowledged unacknowledged
Unicast request Information transfer

reservation request
VSS
General response
protocol Re-transmission
Figure I-2-14b. Use of DLS and VSS functions

2.4.9.1.1.3 The RTS (request to send) DLPDUs are defined as follows:
• CTRL_RTS — sent to request the sending of link maintenance data.
• INFO_RTS — a request to send user data (for long transmission procedures).
• UDATA_RTS — a request to send broadcast data.
2.4.9.1.1.4 The ACK (acknowledgement), CTS (clear to send) and other DLS link control DLPDUs are defined
as follows:
• UDATA_CTS — this DLPDU is a clear-to-send in response to a UDATA_RTS.
• INFO_ACK — an acknowledgment of the previous INFO DLPDU.
• INFO_CTS — a clear-to-send (for long transmission procedures).
• CTRL_ACK — an acknowledgment of the previous CTRL DLPDU.
• FRMR (frame reject) — used to reset the link.
• FRMR_ACK — sent to acknowledge receipt of FRMR
• DM/DISC (disconnected mode) — used to indicate that a DLS DLPDU has been received when no link has
been initialized.
• DM/FRMR — used to indicate that a DLS burst has been received when the link is in the process of being
initialized.
• SZOM — sent in combination with an INFO, INFO_RTS or INFO_ACK to establish a link for ZOCOP
communication.
2.4.9.1.1.5 Table I-2-2 shows the DLS burst types.
Where:
• Toggle bit (T): This is used for duplicate detection and rejection (See 2.4.9.1.4).
• Initialize bit (IB): This bit causes the receiver to initialize the state variables Tt (value of Toggle bit for current
transmitted DLPDUs) and Tr (value of Toggle bit for last received DLPDUs) and to clear the send and receive
arrays while processing the burst. It is set to “0” and ignored on receipt unless otherwise stated. (see 2.5.9.1.5)
• More bit (M): This is set to “0” to indicate the end of a message. It is set to “1” to indicate that it is part of a
fragmented message and that there are more fragments to follow (See 2.4.9.1.6).
• Priority (pr): This is the priority of the message (See 2.4.9.1.7).
• Negotiation subfield (neg): This indicates the link management parameters to be used for air/air link control.
• Length (lg): This is the length of the data message in slots.

Table I-2-2. DLDPU contents
Toggle Bit More Bit Negotiation Initialize bit

(T) (M) Priority (p) subfield (neg) (IB) Length (lg)
CTRL
INFO
UDATA
CTRL_RTS
INFO_RTS
UDATA_RTS
UDATA_CTS
INFO_CTS
INFO_ACK
CTRL_ACK
CTRL_CTS
FRMR_ACK
FRMR
DM/DISC
DM/FRMR
SZOM
2.4.9.1.2 Data link service (DLS) timers
The following timers are used in the DLS procedures:
• TD1: ZOCOP link transmit reset timer. This timer is reset when a burst is sent to the peer. If it expires, then Tt
is set to “0” and the send channel array cleared.
• TD2: ZOCOP link receive reset timer. This timer is reset when a burst is received from the peer. If this timer
expires, then Tt is set to “0”, the send channel array is cleared and the link is considered to be terminated.
2.4.9.1.3 Data link service (DLS) counters
The following counters are used in the DLS procedures:
• ND1: maximum number of octets that may be submitted to the DLS for transfer.
• ND2: maximum length of a DLS transmission that may use the short transmission procedures.
• ND3: maximum length of a fragment with M-bit processing.
• ND4: maximum length of a broadcast DLS burst (UDATA).
2.4.9.1.4 Toggle bit (T)
The T-bit allows detection and rejection of duplicate DLPDUs. It is alternately set to “1” and “0” on each successive
DATA transmission, except for re-transmissions. The associated RTS, CTS and ACK DLPDUs should have the same
T-bit value as the DATA packet. (See Figure I-2-14c)
2.4.9.1.4.1 State variables (Tt and Tr)
2.4.9.1.4.1.1 When a message being transmitted is not the first message between the two stations, the sending
station sets the T-bit to the inverse value that it had for the previous message. The value it transmitted previously is
stored in the state variable Tt.
2.4.9.1.4.1.2 The receiving station compares the value of the T-bit it receives with the value it received
previously in order to check that the received T-bit is of the correct value. The value it received previously is stored in
the state variable Tr.
2.4.9.1.4.1.3 When the sending station receives an ACK or a CTS, it compares the value of the T-bit with the
value it sent (which was stored in Tt) to check that it has the correct value.
2.4.9.1.4.1.4 Messages may be discarded or resent if the T-bit is found to be incorrect.
2.4.9.1.5 Initialize bit (IB)
2.4.9.1.5.1 When the first message to another station is being transmitted, the sending station always sets the
T-bit to “0” (T = 0), and correspondingly sets its value of Tt to “0” (Tt = 0). For the first message transmitted between
two stations, the receiving station should not compare the T-bit it receives with a previous value of Tr.
2.4.9.1.5.2 Therefore there is an IB in the messages, which is usually set to “0”, but which for the first message is
always set to “1”. When the receiving station receives a message with IB = 1 and T = 0, it knows to reset its value of Tr
to “0” instead of performing a comparison.
2.4.9.1.6 More bit (M)
The M-bit controls message fragmentation and concatenation. It is set to “0” to indicate the end of a message. It is set
to “1” to indicate that it is part of a fragmented message and that there are more fragments to follow.
2.4.9.1.7 Priority (pr)
The pr is the priority of the message. The priority levels are defined by the Q1 quality of service (QoS) parameter (see
Part II of this document — Detailed Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4.)
A B
Data T = 1
ACK T = 1
Data T = 0
ACK T = 0
Figure I-2-14c. Use of the T-bit in a short transmission procedure

2.4.9.1.8 Message fragmentation and concatenation
2.4.9.1.8.1 If the length of the burst is longer than ND3 (ND3 is the maximum length of fragment) slots, then the
sending station will fragment the message.
• For single fragment messages — the M-bit is set to “0” (M = 0).
• For multiple fragment messages — the M-bit is set to “1” (M = 1), except the last fragment, which is set to
“0” (M = 0).
2.4.9.1.8.2 If any preceding message fragments have been received with the M-bit set to “1” (M = 1), then the
user data part of the DATA DLPDU is concatenated to the end of the message fragments.
2.4.9.1.8.3 If the M-bit is set to “0” (M = 0), then the user data part of the DATA DLPDU, along with any other
message fragments received earlier, is passed to the DLS user as a single message.
2.4.9.1.9 Data link service (DLS) procedures
2.4.9.1.9.1 Selection of DLS procedures.
There are two types of DLS procedures: short and long. After receiving the burst (from the DLS user), the sending
station calculates the total length of the transmission. If the total length is less than or equal to ND2 (maximum length
of a short DLS transmission), then the station will use the short transmission procedures; otherwise, the station will use
the long transmission procedures.
2.4.9.1.9.2 Short transmission procedures
As illustrated in Figure I-2-14d, the short transmission procedures involve the sending of a single DATA packet that
contains a reservation for a subsequent acknowledgement.
A B
Data sent
(M = 0, pr = 2, T = 0, DATA received
unicast reservation) (M = 0, pr = 2, T = 0)
ACK sent (T = 0)
ACK received (T = 0)
Key
Transmission sent by random access

Transmission sent in unicast reservation
Note.— The values shown in Figure I-2-14d for pr and T are for
example purposes only.
Figure I-2-14d. Short transmission procedures

2.4.9.1.9.2.1 Transmission of DATA DLPDU:
• The sending station transmits a burst containing a DATA DLPDU.

• The M-bit is set to “0” (M = 0).
• The priority (pr) subfield is set to the priority of the DATA DLPDU.
• The T-bit is set to “0” or “1” (inverse to previous transmission) (T = 0 or 1).
• The burst may include a CTRL or INFO DLPDU containing a unicast request reservation field for the
acknowledgement.
2.4.9.1.9.2.2 Transmission of ACK (acknowledgement) DLPDU:
The receiving station transmits a burst containing an ACK DLPDU in the slot reserved by the unicast request
reservation in the received DATA DLPDU.
The T-bit is set to the value of the T-bit in the received DATA frame.
2.4.9.1.9.3 Long transmission procedures
The long transmission procedures, as illustrated in Figure I-2-14e, allow transfer of DATA packets in reserved slots,
avoiding the loss rates and delays associated with random access. This includes the ability to link sequences of DATA
packets, thereby providing continuous transfer in reserved slots. The long transmission procedure starts with a request-
to-send (RTS) being sent by random access. (The RTS is in general shorter than the DATA transmission so it is quicker
to find an available slot for sending this by random access.). The receiving station responds by sending a clear-to-send
(CTS), together with an information transfer request reservation — this reserves slots for the DATA from the sending
station and for the subsequent acknowledgement (ACK).
2.4.9.1.9.3.1 Transmission of RTS (request to send):
• The sending station transmits a burst containing an RTS DLPDU.
• The priority (pr) subfield is set to the priority of the INFO_RTS or UDATA_RTS DLPDU to be transmitted.
• The length (lg) subfield is set to the length (number of slots) of the DLS burst required to contain the DATA
DLPDU.
• The T-bit is set to “0” or “1” (inverse to previous transmission) (T = 0 or 1).
2.4.9.1.9.3.2 Transmission of CTS (clear to send):
• The receiving station transmits a burst containing an CTS DLPDU in the slot reserved by the unicast request
reservation in the received RTS DLPDU.
• The burst also contains an information transfer request reservation to reserve slots for the expected DATA
transmission and the subsequent acknowledgement.
2.4.9.1.9.3.3 Transmission of DATA DLPDU:
• The sending station transmits a burst containing a DATA DLPDU.
• The M-bit is set to “0” (M = 0) if the data fragment is not to be followed by any others, or set to “1” (M = 1) if
it is.
2.4.9.1.9.3.4 Transmission of ACK (acknowledgement) frame:
• The receiving station transmits a burst containing an ACK DLPDU in the slot reserved by the unicast request
reservation in the received DATA DLPDU.
• The T-bit is set to the value of the T-bit in the received DATA DLPDU.
2.4.9.1.10 Linking transmissions
A station with a queue of transmissions for the same receiving station can link them in the following ways as illustrated
in Figure I-2-14f:
1) Combine an RTS DLPDU with a DATA DLPDU. In the long transmission procedure, the sending station can
send the DATA of the first message with an attached RTS for the DATA of the second message. The
receiving station then sends an ACK for the first message along with a CTS for the second.
A B
RTS Sent (lg = 4, pr = 2,
T = 0, unicast reservation)
RTS received (lg = 4, pr = 2, T = 0)
CTS sent
CTS received (info transfer request reservation)
Data sent (M = 0, pr = 2,
T = 0) Data received (M = 0, pr = 2, T = 0)
ACK sent (T = 0)
ACK received (T = 0)
Key
Transmission sent by random access

Transmission sent by unicast reservation
Transmission sent by info reservation
Transmission sent by info reservation
Figure I-2-14e. Long transmission procedures
Note.— The values shown in Figure I-2-14e for pr and T are for the purpose of example only.
2) Combine a DATA DLPDU with an ACK DLPDU. If the receiving station has some data to send which would
fit in one slot it can send said data with the ACK transmission.
3) Combine an RTS DLPDU with an ACK DLPDU. A receiving station that has data to send that does not fit in
one slot can send an RTS for itself with the ACK.
4) Combine a CTS DLPDU with an ACK DLPDU. A receiving station that has received data and needs to
respond to an RTS can send a CTS for more data with the ACK for the received data.
5) Combine a SZOM with any other DLPDU. A station that initiates an air-air (ZOCOP) link sends a SZOM
combined with the first DLPDU to be sent on the link.
2.4.9.1.11 Ground-air link management
For ground-air link management, the CTRL DLPDU is used by the LME to establish and maintain the link. The
CTRL_CMD (command) is sent to request the initiation of a link and the CTRL_RSP (response) is sent in response. On
receiving a CTRL_RSP, the link as been made.
2.4.9.1.12 Air-air link management
Air-air link management is supported by a ZOCOP, which makes use of the SZOM DLPDU. A mobile wishing to send
data to another mobile with which it does not currently have a connection should:
• if using the short transmission procedure, combine an SZOM with the first data transmission; or
• if using the long transmission procedure, combine an SZOM with the first RTS transmission.
On receiving an ACK or CTS after transmission of the SZOM, the air-air link is considered established, the timers are
set, and data exchange is carried out. The link is considered terminated when the timers expire.
A B
RTS
CTS
Data / RTS
ACK / CTS
Figure I-2-14f. Linked transmissions

2.4.9.2 Data link service (DLS) usage and performance
2.4.9.2.1 Performance of basic transfer protocols
2.4.9.2.1.1 VDL Mode 4 provides two protocols for the transfer of data: the short transmission procedure and the
long transmission procedure. Each of these is initiated by a random access event. Thereafter, all transmissions take
place in reserved slots.
2.4.9.2.1.2 The performance of the system in terms of link utilization for data transfer depends on the message
length. A simple model illustrates this as shown in Figure I-2-15a. This simple model of link performance assumes that
there is negligible message loss and that a slot budget of 4 slots per random access event is required.
2.4.9.2.1.3 It can be seen that the channel utilization for DATA transfer increases with message length. The short
transmission procedures appear to perform more efficiently than the long transmission procedures. The reason is that
the long transmission procedures require 2 extra slots (containing the RTS and CTS) to make the transfer. However, the
long transmission procedures provide better control of prioritization and a greater immunity to hidden and exposed
terminals as described in 2.4.9.2.2.
2.4.9.2.2 Factors affecting the efficiency of message transfer
The efficiency of message transfer is affected by the following issues:
• bit errors which increase the likelihood of longer messages being corrupted.
Channel usage effiiciency

80%
Channel usage (slots containing DATA)
70%
60%
50% Short transmission

procedure
40%
Long transmission
procedure
30%
20%
10%
0%
0 2 4 6 8 10
Message length (slots)
Figure I-2-15a. Channel usage efficiency

• a mixture of different message lengths which might potentially lead to inefficient usage of the channel and
also the long delays for high priority shorter messages when the same channel is being used for the transfer of
lower priority long messages.
• “hidden and exposed terminals” which arise because of interference from transmitters which are outside line
of sight. The impact is to provide a random interference which affects longer transmissions and which is
greater in the en route scenario where there are greater numbers of both hidden and exposed terminals.
VDL Mode 4 provides mechanisms to deal with each of the factors affecting the efficiency of message transfer. The
mechanisms are described in 2.4.9.2.3 to 2.4.9.2.5.
2.4.9.2.3 Message fragmentation
The impact of bit errors limits the maximum length of a VDL Mode 4 transmission to typically 10 slots. In order to
support the transfer of longer messages, VDL Mode 4 provides a fragmentation protocol (M-bit processing) which
allows message fragments to be sent separately. In addition, by making possible the combination of DLPDU frame
types, it is possible to transfer the message fragments entirely within reserved slots so that only the RTS for the first
fragment is sent using random access.
2.4.9.2.4 Priority handling
2.4.9.2.4.1 A typical profile for user data size and message frequency is illustrated in Figure I-2-15b. Here it can
be seen that:
• the message load is dominated by the ATS class.
• most ATS messages are short (less than 40 octets).
• there is a significant Aeronautical Administrative Communication (AAC)/Airline Operational

Communications (AOC) load with a user data size of 26 octets (this corresponds to the downlink of weather
updates).
• there is a smaller load of long AAC/AOC messages (many of these are associated with transfer of pre-flight
data) which accounts for approximately 10 per cent of messages and 30 per cent of the channel usage.
2.4.9.2.4.2 Figure I-2-15c shows how the message load is transferred to VDL Mode 4 bursts, with length
measured in slots. The actual conversion depends on a number of factors (including the burst overhead) and hence the
results shown here are approximate, although believed to be representative. Most messages can be sent in two slots.
However, some AAC/AOC messages may require more than 2 slots but this forms only a small part of the overall
traffic load.
2.4.9.2.4.3 VDL Mode 4 makes it possible to mix messages of different lengths and priorities on the same
channel while maintaining, in particular, the quality of service for high priority messages:
• It provides a one-to-one priority mapping with the 15 ATN priority levels, making it possible to differentiate
between AAC/AOC and ATS messages and also between high and low priority ATS messages.
• The DLS transfer protocol makes it possible to send a high priority message between two peer stations even in
the middle of the transfer of a long, fragmented, lower priority message.
• The use of long transmission protocols makes it possible for the ground station to prioritize usage of the link
because the ground station has to give the go-ahead, via a CTS, for a mobile to transfer its data. It can
therefore reject the sending of lower priority DATA DLPDUs in favour of higher priority messages.
The VDL Mode 4 protocols therefore prevent a high priority message from getting stuck behind a lower priority
message.
2.4.9.2.5 Use of ground reserved slots
2.4.9.2.5.1 VDL Mode 4 protocols inherently provide a measure of protection against hidden and exposed
terminals. For example:
• The short transmission protocol generally protects downlinks from aircraft at high altitude since all other
aircraft have a good view of the transmitting aircraft. However, the short transmission protocol is less effective
for low-lying and ground-based aircraft.
100
90
90
80
68
70
Frequency (messages/hour)
60
50
40
30
30
24
20 20
20
15.5
10
10 6.5 6 5.5
3.25
3 3 2 3.16
2 1 12 0.5 0.5 1 0.75 0.25 1 0.25
0
31
10
12
13
14
15
25
38
50
100
140
260
400
26
40
63
80
200
1 000
2 000
4 000
20
9
AAC/AOC Message length (octets)
ATSP
Figure I-2-15b. Message frequency versus message length (octets)

• The long transmission protocol can be used to protect uplink transmission since the slot selection is provided
by the aircraft, which has a better view of the slot map because it sees many of the transmitters that would be
hidden to the ground station.
2.4.9.2.5.2 A much greater level of protection can however be provided by making use of quarantined slots
provided by the second frame and superframe reservation protocols. A possible concept of operation is as follows:
• The ground station or a network of ground stations establishes blocks of slots which are reserved for ground
station use only. (“Ground station use only” means that the slots may only contain a) transmissions by ground
station and, b) transmissions by mobile stations directed by ground stations.)
• Uplink transmissions are carried out using the short transmission procedures with the DATA DLPDU
contained within the ground reserved block. As an option, the ACK DLPDU could also be placed within the
ground reserved block.
300
246
250
Frequency (messages/hour)
200
150
100
50
30 26.25
8.66
1 4 0.5 0 0.5 0 1 0.75 0 0.25 0 1 0.25 0
0 0 0 0 0
1 2 3 4 6 8 9 14 33 65 128
Message length (slots)
AAC/AOC ATSP
Figure I-2-15c. Message frequency versus message length (slots)

• Downlink transmissions should be carried out using the long transmission procedures. The mobile sends the
RTS by using random access procedures in the part of the slot map that has not been reserved for ground use
only. The ground station then issues the CTS by placing a reservation for the DATA DLPDU and, as an option,
the ACK DLPDU in the ground reserved block.
2.4.9.2.5.3 This concept ensures that all DATA transfer is carried out within ground reserved blocks which are
afforded maximum protection from hidden terminals and exposed terminals by the use of the second frame and/or
superframe reservation protocols. A further advantage of the concept is that the ground station becomes responsible for
the efficient organization of the slot map, ensuring that all DATA DLPDUs are packed consecutively within the ground
reserved blocks.
2.4.10 Link management
There are two key processes involved in establishing and maintaining links between aircraft and ground stations in
VDL Mode 4:
1) exchange of mobile and ground station addresses and positions using broadcast synchronization transmissions
or “bursts”; and
2) exchange of link control information via CTRL DLPDUs.
This section describes each of these processes and then describes a number of other important aspects of link
management in VDL Mode 4.
2.4.10.1 Synchronization bursts
2.4.10.1.1 Synchronization bursts are broadcast periodically by every mobile and ground station. They comprise
a fixed part and one of a number of possible variable parts. The fixed part is used to support both the ADS-B service
and the management of communications on the data link. The variable part contains additional ADS-B or management
information that need not be included in each synchronization burst.
2.4.10.1.2 The minimum communication requirement is that identity and position are broadcast at least once per
minute on the GSCs using the synchronization burst. However, similar transmissions to support ADS-B applications
which generally require higher update rates in order to achieve adequate surveillance capability will have to be more
frequent than once per minute.
2.4.10.1.3 Synchronization bursts will use the periodic broadcast protocol to reserve slots for the regular
transmission of identity and position. The burst structure is described in 2.4.5.3.
2.4.10.2 Control (CTRL) DLPDUs
Note.—— For additional reference, see Part II of this document — Detailed Technical Specifications of the
Manual on VHF Digital Link (VDL) Mode 4.
Control (CTRL) DLPDU exchange is supported by VDL Mode 4 and allows a ground station to negotiate data link
connection with one or more mobile stations. A key function provided by CTRL DLPDU exchange is the notification
by the ground station to other users of supported services (e.g. ADS-B, Flight Information Service (FIS), TIS etc),
otherwise known as the DoS.
2.4.10.3 Network entry
2.4.10.3.1 Conditions for application of network entry protocols
2.4.10.3.1.1 A station should apply the network entry protocols when:
1) It is turned on.
2) It tunes to a new channel on which it desires to transmit autonomously.
3) It starts listening to a channel after having stopped listening to that channel for a sufficiently long period of
time.
4) It discovers that it has become “exposed” to a large number of previously unknown stations.
2.4.10.3.1.2 Exposure to a large number of previously unknown stations may happen when:
• an aircraft takes off and rapidly becomes aware of many other aircraft which may have been shielded by the
horizon until just a few moments before; and
• a previously hidden aircraft flies over an obstruction into, in particular, a busy airspace (see Figure I-2-16).
Figure I-2-16. Sudden arrival of previously hidden station,

aircraft X, into a busy airspace
2.4.10.3.1.3 Two examples for network entry are described as follows:
• The first example uses a combination of the periodic and incremental broadcast protocols and requires a
station to wait for a period of one minute before it can broadcast its position.
• The second example involves using plea response and BND protocols which enable a station to broadcast its
position within a few seconds of joining the network.
2.4.10.3.2 Network entry with combined periodic and incremental broadcast protocols
2.4.10.3.2.1 VDL Mode 4 allows the combination of the periodic broadcast and incremental broadcast burst
formats. This is useful for a new station placing periodic reservations for the first time.
2.4.10.3.2.2 Assuming that a new station has just started operation, a possible procedure for initiating
transmission is as follows:
1) The new station listens to the GSCs until a complete superframe has been received (this will take one minute).
2) The information obtained during this listening period is used to build up a reservation table that contains a
record of the data received for each slot. The station calculates the bearing and distance of every other station
within range. This information is used to control access in the event that the new station must override the slot
allocation of a distant station. It also assigns a time out value that is a parameter that controls the deletion of
old and inactive entries in the station directory.
3) The new station calculates the position of the “nominal slots” to indicate where it would like to start
transmitting data.
4) The new station chooses actual slots for its broadcasts by using candidate slots grouped around each nominal
slot. The details of the selection process of these candidate slots are described in Part II of this manual —
Detailed Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4, 1.3.10.5.2.
2.4.10.3.2.3 This process of combining periodic and incremental broadcast protocols for network entry is
illustrated in Figure I-2-17. It reduces the chance of slot contention since all other stations will know that the new
station is intending to transmit later in the superframe and they will not use the same slot for other transmissions.
2.4.10.3.3 Network entry procedures using plea response and big negative dither (BND) protocols
With the method described in 2.4.10.3.2, a station is required to listen to a channel for a minimum of 60 seconds prior
to transmitting for the first time in order to build up an accurate map of reserved and unreserved slots. Such a long gap
in position reporting may be unacceptable in a busy terminal area where an aircraft needs to be able to start transmitting
rapidly for safety reasons. Thus, if required by a particular application, other network entry procedures may be used by
the station. These procedures reduce the length of any reporting gap by allowing a station to begin transmitting its
position before it has acquired a complete slot reservation map. These procedures use the following protocols:
• BND reservations;
• Half-slot transmissions; and
• Plea response transmissions.


Station 1 transmits to broadcast next
periodic broadcast periodic reservation
reservation Incremental reservation Next incremental reservation
Current superframe
Reserved for
Station 1
broadcast
Reserved for
Station 1 Periodic broadcast Next periodic broadcast
broadcast reservation reservation
Reserved for
Station 1
broadcast
Reserved slot
Selected for
reservation
Figure I-2-17. Use of periodic broadcast and incremental broadcast

reservations for network entry
2.4.10.3.3.1 Big negative dither (BND) reservations
2.4.10.3.3.1.1 As illustrated in Figure I-2-18, the BND procedure allows a station to reserve a slot in the
following superframe but behind its position in the current superframe. For instance, if the current position (in time) is
slot 2500 in superframe 8, the BND allows the station to reserve in superframe 9 all the slots up till 2499. The BND
reservation can be used by stations which have listened to the channel for a few seconds but have not yet built up a
complete reservation table.
2.4.10.3.3.1.2 The station transmitting the BND will have knowledge of the slot map in the current superframe
for at least the few seconds before its BND reservation message, and will therefore have sufficient knowledge of the
reservations already made for the same period in the next superframe. The station can therefore reserve a slot in that
period in the next superframe by using the BND reservation message without requiring knowledge of the whole slot
map.
BND is allowed
255 slots (3.4 sec) later
Station starts to listen BND reservation
–128 slots
±127 slots
1 second,
75 slots
Normal dither up to ±127 slots BND reserves slots at
least 128 slots behind
Figure I-2-18. BND reservations
2.4.10.3.3.1.3 Every slot reservation can dither by up to 127 slots each way from its nominal position in any
superframe. This is illustrated for one slot reservation in Figure I-2-17. A dither in the BND must however be greater
than 127 slots, i.e. a value of –128 slots or more. A BND reservation must not take up slots which may be occupied by
a station that dithers in a forward direction (by up to 127 slots) in the next superframe. For this reason, a station must
wait at least until the 255th slot (127 + 128) after it starts listening to a channel before it can transmit a BND
reservation, as shown in Figure I-2-18.
2.4.10.3.3.2 Half-slot transmissions
2.4.10.3.3.2.1 Half-slot transmissions allow a station to make a short transmission without knowledge of the
current slot map. A station wishing to make a half-slot transmission on a channel will start listening to that channel. For
each time slot, the station will listen to see if any transmissions are being made in that slot. If after half a slot, there has
been no detectable transmission, the station will “throw a dice” (with a 1 in x chance of returning “yes” where x is a
small number) to decide whether or not to transmit. If the result of the “dice-throwing” is to transmit, the station will
transmit a half-slot message in the second half of the slot, as shown in Figure I-2-19.
2.4.10.3.3.2.2 The purpose of the “dice-throwing” is to reduce the possibility of two stations deciding to transmit
simultaneously at once in the second half of the slot. In the terminology of SARPs, the “dice-throwing” is referred to as
a p-persistent algorithm.
2.4.10.3.3.2.3 The half-slot message will contain the ID of the transmitting station, but not its position because
there is insufficient space within the half slot. There is however space within the half-slot message to transmit a BND
reservation or to transmit a plea to a peer station asking for available slot positions.
2.4.10.3.3.2.4 A BND reservation will result in the station acquiring a reserved slot in the next superframe but
behind its position in the current frame. Thus to acquire n reserved slots in the next superframe, the station would have
to make n half-slot transmissions in the current superframe. On the other hand, a plea to a peer station can result in a
response giving the transmitting station a number of slots in the same superframe in which it may transmit.
2.4.10.3.3.3 Plea response protocol
2.4.10.3.3.3.1 With the plea response protocol, a station wishing to perform network entry can acquire a number
of slots in which to transmit by making a single half-slot plea transmission to other peer stations. The mechanism is
illustrated in Figure I-2-20.
2.4.10.3.3.3.2 Suppose that a station A wishes to achieve network entry in a region of airspace occupied by a
number of aircraft including stations X and Y. Station A uses the SARPs protocols to decide the aircraft to which it will
address a plea transmission, and chooses Station Y. Station A then makes a half-slot transmission in which it makes a
plea to Station Y asking to be given some slots in which to transmit.
2.4.10.3.3.3.3 Shortly afterwards, Station Y responds with a full-slot transmission in which it names a number of
slots that Station A can use to make its first full-slot transmissions. Station Y’s response will contain reservations for
slots which are appropriate for Station A, taking account of all other slot reservations and restrictions which are known
to Station Y. These reservations are all likely to be contained within one superframe of the initial plea transmission to
Station Y. Station A subsequently makes full-slot transmissions in some or all of the slots it has been given.
2.4.10.3.3.3.4 Station A may additionally use BND reservations in the slots it was given by Station Y in order to
move the positions of the donated slots to positions which Station A regards as more appropriate. The use of BND
reservations in these slots is also shown in Figure I-2-20. Station A might do this because it is committed to transmit
always in certain slots or at a certain rate.
2.4.10.3.3.3.5 Alternatively, the station may just decide to use the provided slots in the first superframe
appending null reservations and then, when it has built up its own reservation table, establish new streams using the
periodic/incremental broadcast protocol. This avoids the need for an implementation to include the transmission
functions associated with the BND protocol.
2.4.10.4 Block reservation protocols
There are two types of block reservation designed to provide protection for important ground station transmissions: the
superframe block reservation and the second frame block reservation.
2.4.10.4.1 Superframe block reservation
2.4.10.4.1.1 A ground station may use the superframe block reservation protocol in order to reserve blocks of
slots for its own use. This protocol establishes a series of blocks of slots in which no other station is allowed to place a
reservation or to transmit. Network entry protocol transmissions (see 2.4.10.3) are also prohibited.
2.4.10.4.1.2 The superframe block reservation protocol provides a facility for a ground station to rebroadcast its
message via a mobile. The advantage of this is that since the mobile will be in a better position than the ground station
to see other mobiles, it will provide better protection of the slots than if there was sole reliance on the ground station
transmissions. If the relay mode of operation is used, the ground station should ensure that it chooses a mobile that is
well placed in order to ensure that as many other mobiles as possible receive the block information. Therefore it should
choose a mobile that is at high altitude and positioned somewhere near the centre of the zone over which the block
information is to be transmitted.
One slot-length
Whole-slot message
Transmission
A new station starts If no sign of any transmission after half a

to listen at or before slot, new station “throws a dice” and then it
the start of a slot may broadcast a half-slot message.
Half-slot message
Transmission
Figure I-2-19. Half-slot transmissions
Station A makes a half Y responds with a list Station A may use BND
slot plea transmission of available slots for reservations to move slots
to Station Y Station A to its desired positions
X Y
Transmission
A A
A Y
Transmission
X Y A B
1 second,
75 slots Station A slots in desired positions
Figure I-2-20. Plea response protocol

2.4.10.4.1.3 The following scenario is illustrated in Figure I-2-21.
• Ground Station G wants to protect three blocks of 10 slots per superframe. Let us refer to these slots as 100 –
109, 1600 – 1609, 3100 – 3109 (note that these are relative to the current slot 0).
• Station G chooses a Mobile M to rebroadcast the message.
• Station G broadcasts a superframe block message defining slots 100 - 109, 1600 - 1609, 3100 - 3109. For
illustration, let us assume this is done in slot 5, but it would more likely to be done in one of the reserved
blocks.
• Station G includes in this transmission the address of Mobile M and the identity of the slot in which Mobile M
is to rebroadcast the information. The slot chosen to rebroadcast the message should not be within the ground
reserved block, but should be just before it. In case slot 96 is chosen, the following steps complete the
superframe block reservation:
• In slot 96, Mobile M transmits the superframe block information.
• If required, Station G can reinforce the protection by requesting transmissions before later reserved blocks, i.e.
just before slots 1600 or 3100, as shown in Figure I-2-21.
2.4.10.4.1.4 Station G can also reinforce the protection by asking other mobiles, namely N and P, to transmit the
same message in a different slot. This is illustrated in Figure I-2-22.
Ground Station G transmits Mobile M uses the slot

a message protecting the reserved for it by
following block(s), and Ground Station G to
use a directed request to rebroadcast the
reserve a slot for message message protecting Protected block
rebroadcast by Mobile M the following block(s) for the ground
transmissions only
M G M G M G
transmission
0 96 100 109 1596 1600 1609 3096 3100 3109
M G M G M G
transmission
M G M G M G
transmission
The mobiles and ground stations A gap between the mobile

periodically repeat their rebroadcast and the next
reservations to continue protected block allows space
protecting blocks of slots for other mobiles to repeat the
message protecting the block(s)
Figure I-2-21. Blocks protected by ground and mobile rebroadcast transmission

2.4.10.4.1.5 In the case of multiple ground stations in a local area, block protection may be more complete if
more than one ground station and/or more than one mobile is used to protect the block. This is illustrated in
Figure I-2-23.
M N P G
transmission
Figure I-2-22. Block protection using multiple mobiles
G A G2
B C
G1
In a region with three

ground stations, i.e. G, G1 and
G2, the rebroadcasting of the
protected block message by
mobiles such as A, B and C
would improve protection of
transmissions from ground
stations G, G1 and G2.
A B C G G1 G2
In addition to the mobiles such as

A, B and C, ground stations G,
G1 and G2 all issue the protected
block message.
Figure I-2-23. Block protection with multiple ground stations and mobiles
2.4.10.4.2 Second frame block reservation
As illustrated in Figure I-2-24, the second frame block reservation allows a ground station to reserve one or more slots
at the start of each second, to be used exclusively by ground stations for important uplink transmissions to mobiles. In
the absence of any second frame block reservation from the ground station, the mobile will, by default, reserve 8 slots
at the start of each second. However, a particular ground station may choose to either reduce or increase this number
according to the applications it wishes to use at the time.
2.4.10.5 Ground quarantining
2.4.10.5.1 Where a ground station is using the autotune reservation to direct mobiles on when to broadcast
synchronization bursts, VDL Mode 4 uses a concept known as ground quarantining to assist in the management of the
channel. The group of slots (typically 4) following a slot that has been reserved by a directed request transmission from
a mobile are “quarantined”, and will not be used by other mobiles for transmissions (see Figure I-2-25). Similarly, the
group of slots following a periodic broadcast reservation placed by a ground station are quarantined.
2.4.10.5.2 The ground station can place reservations for new mobiles into one of the quarantined slots, thereby
reducing the risk of contention with other stations and increasing the efficiency of network entry for ground-directed
systems. The effect of ground quarantining is to form groups of directed reservations, which makes the most efficient
use of the channel and leaves the rest of the channel for autonomous operation.
2.4.10.5.3 If a mobile is farther away from a specified distance to the station which reserved the quarantined slots,
that mobile may regard those quarantined slots as unreserved and may transmit in them as normal operations.
2.4.10.6 Global Signalling Channels (GSC)
Block of slots
reserved for
ground station Mobile
transmissions transmissions
G M N P Transmission
Size of
reserved block G M N P
reduced by Transmission
ground station
1 second (75 slots)
Figure I-2-24. Second frame block reservation

2.4.10.6.1 A pair of GSCs (GSC A and GSC B) provide communication control in most areas up to and
including high-density airspace. In areas with extreme traffic density, such as the Los Angeles Basin (LA Basin) and
the core area of Europe, the GSCs could be supplemented with Local Signalling Channels (LSCs) in terminal areas and
for airport surface surveillance (see Chapter 4).
2.4.10.6.2 The GSCs are also used to transmit the VDL Mode 4 DoS described in 2.4.10.8. The GSCs are likely
to be allocated worldwide and represent a common element of VDL Mode 4 operations.
2.4.10.6.3 The concept assumes two GSC assignments, GSC A and GSC B, in order to support autonomous
operations. The station's single transmitter (minimum hardware configuration) cycles among the two channels, tuning
automatically, while the two receivers monitor each channel full-time.
2.4.10.6.4 The aggregate update rate must satisfy the default-commanded requirement (e.g. at least 12 per minute
averaged over the two GSCs). The global use of dual GSC channels simplifies station operations and spectrum
coordination, and would not adversely affect spectrum utilization in those areas of the world with low-density traffic.
2.4.10.6.5 With two GSCs carrying all link management and ADS-B traffic, VDL Mode 4 is inherently robust in
terms of unintentional interference on either channel. Loss of either channel, due to unintentional and unforeseen events,
results in graceful reduction of the traffic information update rate for all stations. The reduced update rate is still
sufficient to satisfy most applications.
2.4.10.6.6 In areas with low GSC loading, local authorities could permit broadcast applications and tactical ATS
communication on the GSC channels.
Directed ADS-B
messages
Ground
transmissions in
quarantine slots
Aircraft out of ground station

coverage avoids quarantined slots
Figure I-2-25. Ground quarantining

2.4.10.7 Frequency management
2.4.10.7.1 Any 25 kHz VHF channel between 108.00 to 136.975 MHz, protected as appropriate, can be used by
the VDL Mode 4 data link, depending on the application. Two GSCs will be assigned as a result of international
agreement. It may however be better to split them so as to provide better resistance to broadband interfering signals.
2.4.10.7.2 Frequency management provides the following:
• spectrum efficiency via a limited set of worldwide global frequency assignments for basic functions;
• flexibility for augmented operations and local spectrum management on a national and regional basis; and
• protection of safety-critical functions.
2.4.10.7.3 The principles for channel management are illustrated in Figure I-2-26. Subject to regional
requirements and frequency management constraints, optional additional channels may be assigned for particular
applications such ADS-B, Automatic Dependent Surveillance — Contract (ADS-C), etc. This allows each Provider
State to follow its own spectrum management policies for radio-navigation, and thereby helps to preserve the
independence of data communications on and navigation utilization of the radio-frequency spectrum. These channels
could be defined in an on-board database or via the DoS received on the GSCs.
2.4.10.7.4 A VDL Mode 4 ground station may autotune a station operating on the GSCs to special LSCs and
back again when entering or leaving a specified airspace or geographical area (see Chapter 4).
137.0 MHz
DoS GSC A
ADS-B
GSC B
MHz
Optional
LSC
Optional
ADS-C
Optional
118.0 MHz Protected band Other
Figure I-2-26. Channel assignments

2.4.10.8 Directory of Services (DoS)
2.4.10.8.1 Authorized ground stations may transmit a DoS on the GSCs or other channels, using a DoS parameter
format contained in CTRL DLPDUs. The DoS messages define the frequencies and associated operations available in
the local domain. Sample services could include ADS-B and Traffic Information Services — Broadcast (TIS-B) on the
same channel or on a dedicated frequency. The DoS message can be used to override on-board database information in
order to accommodate regional changes in policy, frequency management, and level of service. Selection of services
may be made automatically by using the autotune function or manually by the pilot/controller.
2.4.10.8.2 The DoS parameter is defined in Annex 10 — Aeronautical Telecommunications, Volume III, Part I
— Digital Data Communication System, Chapter 6. It has a flexible structure which can accommodate the following
features:
• the ability to refer to channels other than the channel on which the DoS parameter is transmitted. Each DoS
parameter contains a compulsory subfield containing information on the channel on which the DoS parameter
is transmitted and may optionally contain information on one or more additional channels within the
additional channel subfield.
• the assembly of a large database of DoS information through the use of sequential entry numbers (i.e. each
new transmission either replaces previous information if it has the same entry number or adds to it if the entry
number is different).
• the availability of services is flagged in two ways:
1) by adding a unique byte for each service. The number of bytes added is indicated in the application
number (anum) subfield. These bytes are open for future definition. However, four application numbers
(identifiers) have been defined in Part II of this document — Detailed Technical Specifications of the
Manual on VHF Digital Link (VDL) Mode 4, 3.7, including ADS-B and TIS-B.
2) through the use of a service information (si) field. This is a compressed means of giving the service
information. Each bit in a service information field represents a particular service. If the bit is set, then the
service is available. The information represented by each bit is a matter for application definition and the
meaning depends on the value of the service information type subfield contained at the end of the DoS
message. One service information field type has been defined in Part II of this document — Detailed
Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4 in order to provide a
compressed means of indicating support for services that include ADS-B and TIS-B.
2.4.10.8.3 A compression technique, defined in Part II of this document — Detailed Technical Specifications of
the Manual on VHF Digital Link (VDL) Mode 4, 1.5.2.6 and 1.5.3.6.6, enables a basic CTRL DoS parameter to be
compacted into a single slot by encapsulating the DoS parameter in a GSIF frame. In this case the UCTRL identity
(ucid) bit is set to 1 (ucid =1), indicating that the GSIF contains a DoS parameter only. Examples on the uses of the
CTRL DoS parameter are given in Appendix A to Chapter 2.
2.5 OPERATION
This section describes the operation of mobile and ground stations in VDL Mode 4, applying the procedures on
operating modes, reservation protocols, GSCs and frequency management described earlier in this chapter.
2.5.1 Mobile stations
2.5.1.1 Network entry
When first switched on or following a loss of power or memory, a mobile station has the option of gaining network
entry through the network entry protocols described in 2.4.10.3. The network entry protocols have the advantage of
allowing rapid access to the network, with a mobile being able to broadcast its position within a few seconds of being
switched on. However, if the mobile does not use the network entry protocols, it must:
• tune one receiver to each GSC and monitor the two channels until the mobile has obtained a map of current
and future slot reservations. This will take one minute (i.e. one superframe).
• start transmitting on the GSC channels at the combined default rate (see 2.5.1.2) by using autonomous
reporting. This is achieved by using the combined periodic and incremental broadcast reservation protocols
(see 2.4.10.3.2). After the first minute of reporting, the mobile station will only use the periodic broadcast
protocol.
Subsequently, the mobile station may be instructed by a ground station to change the characteristics of its reporting. It
may, for instance, be instructed to change from the GSCs to other LSCs.
2.5.1.2 Autonomous Automatic Dependent Surveillance — Broadcast (ADS-B) reporting
2.5.1.2.1 When initially switched on, a mobile station will use the network entry procedure described in 2.5.1.1.
It will then start to transmit and receive ADS-B messages on the two GSCs.
2.5.1.2.2 The station will begin transmitting at the combined default rate on the GSCs. Transmissions will be
distributed between the two GSC channels in order to achieve an evenly spaced overall reporting rate. The use of two
channels eliminates a single point of failure in case of a loss of one channel for whatever reason.
2.5.1.2.3 The current and future use of slots by a mobile station is announced in advance by using one of the
access protocols described in 2.4. By announcing in advance its intention to transmit in a particular slot, a station
attempts to ensure that no other station transmits in the same slot in such a way that would cause unacceptable
interference.
2.5.1.2.4 A mobile station uses the periodic broadcast protocol (see 2.4.8.1) to make regular ADS-B reports. This
protocol allows a station to reserve slots in consecutive superframes. Each reservation is for the same slot (with a dither,
if required) in the following superframe, and the reservation of a slot from minute to minute is known as a “stream”. A
station must create as many streams as necessary in relation to the number of ADS-B messages that it wishes to send in
a minute. For instance, if a station wishes to send a message every 6 seconds, then it must create 10 streams.
2.5.1.3 Directed Automatic Dependent Surveillance — Broadcast (ADS-B) reporting
2.5.1.3.1.1 A mobile station may be directed by a ground station to report ADS-B messages on a specified
channel and at a specified rate. This is achieved by using the general request message (see 2.4.8.3) with an autotune
reservation (see 2.4.8.6). When the mobile station receives the autotune reservation, it stops reporting autonomously
and starts reporting as it has been instructed. To cancel autonomous reporting, the station must transmit a reservation
cancellation in each of the reserved slots. This announces to other stations that those slots are now vacated.
2.5.1.3.1.2 The general request message includes the ID (type) of the message that is to be transmitted by the
mobile. This will usually specify an ADS-B message but it could also specify, for instance, a waypoint message. The
general request message also includes a time out value, specifying the number of superframes for which the reservation
will be held; the reporting rate; and a “directed offset” field. The directed offset field is used to indicate:
• that the mobile should broadcast autonomously, i.e. decide on its own slots using the specified rate (“directed
rate reservation”); or
• that the mobile should use pre-defined slots specified by the ground station (“directed slot reservation”).
The general request message also includes a frequency to force the mobile station to change channel (“autotune”) if
this is required.
2.5.1.3.1.3 When issuing a directed slot reservation, it is the responsibility of the ground station(s) to ensure that
if two different mobiles are given the same slots, they are separated at sufficient intervals and on divergent paths so that
there is no risk of a possible loss of communications.
2.5.1.3.2 Transmission of a single ADS-B or other message
2.5.1.3.2.1 A mobile station may be instructed by another station to report a single ADS-B or other message in
one slot. This is achieved by using a general request message with a unicast request reservation transmitted from one
station to another.
2.5.1.3.2.2 A unicast request reservation may be sent from a mobile to another mobile or to a ground station, or
from a ground station to a mobile. The station replies in the slot indicated in the general request message. This
procedure may be used to obtain information from a station, such as:
• data which is normally transmitted at low rate (e.g. next waypoints) and which for whatever reason has not
been received for some time or not at all; and
• more frequent position reports from a nearby aircraft.
2.5.1.3.3 Sleep mode
2.5.1.3.3.1 Sleep mode is used for parked aircraft. When an aircraft is in sleep mode and stationary, the reporting
rate will be low. When the aircraft moves, the reporting rate will be increased automatically. Sleep mode is used to
reduce the load on the data link.
2.5.1.3.3.2 An autotune reservation may include an instruction to enter sleep mode. The autotune reservation
includes two parameters that the receiver may use to determine when to leave the sleep mode. The first is the distance
from the current position and the second is the velocity. If either parameter is exceeded, then the mobile will leave the
sleep mode and start transmitting ADS-B reports at a high rate. This is achieved by using the incremental broadcast
protocol. The reporting rate while in sleep mode is specified in the autotune reservation. The reporting rate when
leaving the sleep mode is decided by the mobile station.
2.5.1.3.4 Waypoint reporting
The VDL Mode 4 message set supports waypoint reporting. Waypoint reporting could be performed autonomously at a
low rate on each of the channels on which the mobile station transmits ADS-B reports. In addition, waypoint messages
can be sent in response to directed or general request messages from another station.
2.5.1.3.5 Downlink of Airborne Parameters (DAP)
A mobile station may transmit data (other than ADS-B messages) known as DAP. DAP messages may be sent:
• periodically as broadcast messages; or
• on demand ( e.g. using the unicast request or autotune reservation protocols).
DAP messages may be sent either autonomously (as decided by a DAP application) or in response to instructions from
another station. They are expected to be consistent with the DAP messages defined for Secondary Surveillance Radar
(SSR) Mode S.
2.5.2 Ground stations
This section describes the general operation of ground stations. The management of channel switching is described in
more detail in 4.3.1 on ground station management. Ground stations are not required to conduct autonomous operation
on the pre-assigned GSCs. They uplink different types of information to support communications management and a
range of other applications:
• ADS-B messages, used for communications management and the ADS-B service;
• General request messages, used to instruct an aircraft to change its reporting characteristics (rate, channel, and
autonomous/directed mode) or to instruct it to transmit periodic or on-demand DAP information;
• DoS messages, used to give information about the VDL Mode 4 services available on different channels;
• Blocking messages, used to reserve a series of slots for exclusive use by a ground station in order to protect the
transmitted information from unintentional interference from other transmitters;
• TIS-B messages, used by the ground system to broadcast radar position data and to rebroadcast aircraft
position information to other aircraft; and
• Other messages, used by the ground system to broadcast data to support other applications.
All of these transmissions are broadcast messages, with the exception of the general request message which is
addressed to a particular mobile station.
2.5.2.1 ADS-B messages transmitted from a ground station
2.5.2.1.1 A ground station transmits ADS-B messages by using synchronization bursts that are made up of a
fixed part and one of several possible variable parts (see 2.4.5 and 2.4.10). The variable part termed “basic ground” is
likely to be used most often by ground stations, although other variable parts which have been defined may also be
used by ground stations (see Annex 10 — Aeronautical Telecommunications, Volume III, Part I — Digital Data
Communication System, Chapter 6)
2.5.2.1.2 The reporting rate for ground station ADS-B messages is an implementation option, but is likely to be
lower than the reporting rate for mobile stations. It should not however be lower than one message per minute.
2.5.2.2 Mechanisms for a ground station to control a mobile
2.5.2.2.1 The use of autonomous or directed reporting is an implementation option. However, it is expected that
autonomous ADS-B reporting will be used for aircraft in en route and unmanaged airspace, while directed reporting
will be used for aircraft in busy terminal areas and for mobiles (aircraft and ground vehicles) on the airport surface.
Directed reporting is a flexible protocol that can be used to specify a channel for transmissions and a reporting rate. It
can also be used to specify actual slots for transmissions.
2.5.2.2.2 The mechanisms used by a ground station to control a mobile was addressed in 2.5.1.3 and more details
are given in Chapter 4.
2.5.2.3 Traffic Information Service — Broadcast (TIS-B)
A ground station may uplink TIS-B messages with information about non-ADS-B equipped aircraft. TIS-B messages
may also be used by a ground station to re-transmit ADS-B reports. This can be useful when an aircraft transits into an
area where a different channel is being used for ADS-B reporting. In this case, the ground station can provide an
aircraft in the new area with position information about other aircraft entering the area (and vice versa).
2.5.2.4 Protecting ground station transmissions
2.5.2.4.1 Ground stations may use quarantining to reduce the likelihood of a mobile station transmitting in slots
used by a ground station (see 2.4.10.5). This technique is useful because a ground station will usually be at lower height
compared to mobiles and the coverage of its transmissions will be limited. This means that an aircraft A at low altitude
and at long range may not receive transmissions from the ground station. Slots being used by the ground station will
then appear to be vacant and will therefore be used by the aircraft A. This will cause interference to other aircraft that
wish to receive the ground station transmissions.
2.5.2.4.2 In addition, a ground station’s transmissions are likely to have higher priority than an aircraft’s ADS-B
reports. The priority of the ground station transmissions will depend on the message category as contained in Annex 10
— Aeronautical Telecommunications, Volume III, Part I — Digital Data Communication System, Chapter 3, Table 3-3.)
2.5.2.5 Managing ground station transmissions
2.5.2.5.1 Ground stations will generally transmit synchronization bursts containing several different types of
messages. Figure I-2-27 shows uplink transmissions containing:
• system control messages (synchronization bursts);
• DoS messages;
• TIS-B messages;
• other applications messages; and
• general request messages.
2.5.2.5.2 Figure I-2-27 also shows:
• Blocked slots. These are reserved slots for use by ground stations only. In areas with multiple ground stations,
their pre-planned transmissions are coordinated. The blocked area covers all transmissions by these stations.
Blocked slots can be established by a variety of means, as specified in 2.4.10.4.
• Directed reporting by aircraft that is reporting under direction of a ground station. The slots immediately
following the uplink transmissions have been assigned.
• Ground quarantine slots. These are the slots immediately following the slots used for directed reporting.
2.5.2.5.3 Uplink transmissions may be a contiguous transmission across several slots, without breaks. To prevent
the transmission from becoming too long, the ground station may insert some breaks.
System control DoS TIS-B Other applications General

request
Blocked
area
Ground station
transmissions
Figure I-2-27. Ground station transmissions
— — — — — — — — —
Appendix A to Chapter 2
LINK MANAGEMENT
This appendix comprises detailed information on the format of the synchronization burst. This information is used for
the management of the VDL Mode 4 link and is also used by Automatic Dependent Surveillance — Broadcast (ADS-B)
and other applications. Only information related to the link management function is addressed here. References to
Part II of this document — Detailed Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4 are
given.
1. SYNCHRONIZATION BURST
1.1 The link management entity (LME) in VDL Mode 4 uses a synchronization burst to control the
communications. A synchronization burst can also contain ADS-B related data.
1.2 The synchronization burst is divided into a fixed part which contains information required for
communications maintenance as well as for basic ADS-B information, and a variable part which contains additional
information used by the applications (e.g. ADS-B).
1.3 The complete synchronization burst is made up of the general burst header, the fixed part of the
synchronization burst, and one of a number of possible variable parts of the synchronization burst.
2. GENERAL BURST HEADER
The general burst header contains information on:
• the reservation type (VDL Mode 4 specific information — ground controlled or autonomous);
• the version number (to support growth);
• the source address (ICAO 24-bit address plus 3 bits to define the address type — see Part II of this document
— Detailed Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4, Chapter 1,1.4.2.2.
The rest of the burst is filled in according to the type of burst being transmitted.
I-2A-1
I-2A-2 Manual on VHF Digital Link (VDL) Mode 4
3. FIXED DATA FIELD OF SYNCHRONIZATION BURST
Note.— For additional reference, see Table II-1-64 and Table II-1-65 in Part II of this document — Detailed
Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4.
3.1 Fixed field information is always transmitted. The fixed data field contains information on:
• autonomous/directed flag
• altitude type, either barometric (baro) or geometric (geo)
• Compact Position Reporting (CPR) format;
• navigational integrity category (NIC)
• latitude and longitude (accuracy for en route phase)
• base altitude
• Time figure of merit (TFOM)
• data age or latency
3.2 The remaining part of the burst is set aside for one of the possible variable information fields (see Section 4
in Appendix A to Chapter 2 and Appendix B to Chapter 2).
3.3 The contents of the various data fields are detailed in Table I-2A-1 of Part I and Table II-1-64 of Part II of
this manual.
Table I-2A-1. Encoding for the fixed part of the synchronization burst
Information field No. of bits Comment
Message ID 1 “0” indicates that the slot contains a synchronization burst.

Autonomous/directed mode 1 The bit is used to denote an autonomous or directed burst.
Time figure of merit (TFOM) 2 4 timing states defined (primary certified, primary, secondary and tertiary).
Navigation integrity category 4 Provides for the definition of 16 possible states, including 4 reserved states for
(NIC) future definition.
Compact position reporting 1 Denotes whether the position information (CPR encoding) is the odd or the even
(CPR) odd/even identifier part.
Latitude 12 The 12-bit CPR encoding provides position to a resolution of approximately
±140 m, within a segment (patch) of approximately 600 NM.
Longitude 14 The 14-bit CPR encoding provides position to a resolution of approximately
±120 m, within a segment (patch) of approximately 600 NM.
Barometric(baro)/ geometric 1 Denotes whether baro or geo altitude is transmitted. As default, barometric
(geo) altitude identifier altitude is sent if available (“0”).
Altitude 12 Altitude is reported using a specific format specified in Table II-1-67 in Part II
of this document — Detailed Technical Specifications of the Manual on VHF
Digital Link (VDL) Mode 4.
Appendix A to Chapter 2 I-2A-3
Information field No. of bits Comment

Data age (latency) 4 Describes the age of the transmitted data encoded as presented in Table II-1-68
in Part II of this document — Detailed Technical Specifications of the Manual
Variable part ID 4 Identifies the information contained in the variable part within the
synchronization burst. If needed, additional 8 bits for the ID are available in the
variable part.
Total: 56
4. VARIABLE DATA FIELD OF SYNCHRONIZATION BURST
Table I-2A-2. Encoding for the variable part of the synchronization burst
Information field No. of Bits Encoding Notes
Latitude 4 A high-resolution component to enhance the 12-bit

low-resolution encoding transmitted in the fixed part
Longitude 4 A high-resolution component to enhance the 14-bit
low-resolution encoding transmitted in the fixed part
Altitude offset 7 Barometric — geometric altitude
Specific encoding defined in Part II of this document
— Detailed Technical Specifications of the Manual on
VHF Digital Link (VDL) Mode 4, 3.3, Table II-3-12.
UTC year 8 Current year = 1970, 0 = N/A 1 to 255
UTC month 4 Linear
UTC day 5 Linear; 00 = N/A
UTC hours 5 Linear
UTC minute 6 Linear
UTC second 6 Linear
Slot 8 linear = 0 indicates the first slot in the second frame 0 to 255
Note.— UTC stands for Universal Coordinated Time.
Table I-2A-3. Link management information fields
Information field ID ID extension 1 ID extension 2

(id) (id1) (id2) Information field name
3 hex not present not present Basic ground (see Table I-2A-4)
4 hex not present not present UTC time (see Table I-2A-5)
Note.— “hex” refers to “hexadecimal”.

4.1 Information field 3 hex — Basic ground
Table I-2A-4. Information field 3 hex — Basic ground:

A variable field to be transmitted by ground stations
Bit number
information field (ID) 11 x x x x 0 0 1 1

UTC hours (h) 12 res res res h5 h4 h3 h2 h1
UTC minute (min) 13 pid10 pid9 min6 min5 min4 min3 min2 min1
patch ID (pid) 14 pid8 pid7 pid6 pid5 pid4 pid3 pid2 pid1
baro/geo offset (bgo) 15 res bgo7 bgo6 bgo5 bgo4 bgo3 bgo2 bgo1
slot (slt) 16 slt8 slt7 slt6 slt5 slt4 slt3 slt2 slt1
4-bit longitude offset (lon4), 17 lon44 lon43 lon42 lon41 lat44 lat43 lat42 lat41
4-bit latitude offset (lat4)
UTC second (sec) 18 sec6 sec5 sec4 sec3 sec2 sec1
Note.— “res” denotes currently unused. “x” denotes part of fixed data field.
4.2 Information field 4 hex — UTC time
Table I-2A-5. Information field 4 hex — UTC Time:

provides the possibility to transmit UTC time
Bit number
information field (ID) 11 x x x x 0 1 0 0

UTC day (day) 12 res res res day5 day4 day3 day2 day1
UTC year (yr) 13 yr8 yr7 yr6 yr5 yr4 yr3 yr2 yr1
UTC hours (h), UTC month (mon) 14 h4 h3 h2 h1 mon4 mon3 mon2 mon1
UTC minute (min) 15 res h5 min6 min5 min4 min3 min2 min1
slot (slt) 16 slt8 slt7 slt6 slt5 slt4 slt3 slt2 slt1
4-bit longitude offset (lon4), 17 lon44 lon43 lon42 lon41 lat44 lat43 lat42 lat41
UTC second (sec) 18 sec6 sec5 sec4 sec3 sec2 sec1
Note.— “res” denotes currently unused. “x” denotes part of fixed data field.
5. DIRECTORY OF SERVICES (DoS) MESSAGE
The DoS message format was described in 2.4.10.8. This section provides examples of typical DoS parameter formats.
5.1 Example 1: Use of GSIF for DoS and other CTRL parameters (no compression)
5.1.1 Table I-2A-6 provides an example of the encoding for a DoS/GSIF (Ground Station and Identification
Frame) message which could be broadcast by using the periodic reservation format or within a blocked or reserved slot
by using the null reservation protocol. This specific example illustrates the bit encoding pattern for a GSIF containing a
VSS sub-layer parameter and a DoS parameter including information for two channels. It should be noted that this is
only one example for a particular set of CTRL parameters.
5.1.2 In the example, octets 1 through 5 are the standard VDL Mode 4 header. Typically, the reservation ID (rid)
field (bit 2 of octet 1) would be set to “1”, consistent with a periodic reservation field at the end of the transmission.
5.1.3 The CTRL parameter ID in octets 7 and 12 indicate the inclusion of the VSS sub-layer and the DoS
parameters, respectively. The parameter length indicates that the length of the information fields belonging to the VSS
and DoS parameters are 3 and 9 bytes, respectively.
5.1.4 The contents of each channel subfield in the DoS parameter is determined by the additional service
information (ai) subfield in octets 14 and 19. Note that for illustration in this particular example, the current channel
subfield defines the available services using a combination of service information (si), application number (anum) and
application (a) subfields. However in practice either of the si or the a (and corresponding anum) subfields is used. The
latter provides an alternative way of encoding the information. An si field can denote a particular group of applications
in an efficient format since each bit in the subfield represents the availability of an application. The significance of each
bit is defined by the service information type (sit) subfield defined by application standards. The alternative method of
encoding this information in a less compact way is by inserting the unique reference of the application (a) subfield
directly in the message. In this case, each application is encoded in an octet-long subfield. Currently there exist ICAO
definitions for ADS-B, TIS-B, FIS-B and secondary navigation capabilities. The advantage of this over the use of the si
subfield is that there is no limitation imposed by the particular combinations defined by the sit subfield. However there
is presently little advantage of using this latter method due to the currently restricted set of applications. For
comparison, the (additional) channel subfield in the example defines available applications solely through the use of the
si subfield.
5.2 Example 2: Exclusive use of the GSIF message for DoS
5.2.1 Broadcast GSIF frames can also be used to transmit DoS parameters in a compacted form. In this case, the
GSIF contains only the DoS parameter. This is achieved by setting the ucid subfield in the GSIF header to one and
thereby omitting the CTRL parameter ID. It should be noted that, as in this example in Table I-2A-7, it is possible to
transmit a single slot of basic DoS information.
5.2.2 Note that both service information (si) and application (a) subfields may be used in this type of GSIF. In
the following example, the current channel subfield uses the service information (si) subfield to define the applications,
while the (additional) channel subfield uses the application number (anum) and application (a) subfields. Table I-2A-7
provides a typical example of the use of this compacted DoS scheme.
Table I-2A-6. Overall structure of the GSIF message with two CTRL parameters
(VSS sub-layer and DoS) included without compression
Bit position within octet

Parameter field Octet 8 7 6 5 4 3 2 1 Comments
Flag — 0 1 1 1 1 1 1 0
Autonomous/directed Bit 1 is a reserved bit and set to
flag (a/d), 1 indicating a burst.
Reservation ID (rid), Bit 2: rid = 1 for periodic
Version number (ver) 1 s s s ver ver ver 1 1
reservation. (Same structure is
Source address (s) used for null and incremental
reservations.)
Burst header
Source address (s) 2 s s s s s s s s

3 s s s s s s s s
4 s s s s s s s s
Message ID (mi) Bits 1 to 7 contain the burst
type ID indicating that this is a
5 0 0 1 1 0 0 0 1 DLS burst.
Bit 8 is reserved and set to 0 in
this example
UCTRL DLPDU ucid = 0 indicating GSIF
header
ucid4 ucid3 ucid2 ucid1

DLS
header 6 0 1 0 0 contains one or more CTRL

(0) (0) (0) (0) parameters
CTRL parameter ID id8 id7 id6 id5 id4 id3 id2 id1 Unique ID identifying the VSS
7
(0) (1) (0) (0) (0) (0) (0) (1) sub-layer parameter
VSS parameter
Parameter length (lg) lg8 lg7 lg6 lg5 lg4 lg3 lg2 lg1 Indicating 3 octets to follow in
8
(0) (0) (0) (0) (0) (0) (1) (1) the information field
Parameter value 9 VS5 VS5 VS5 VS5 VS1 VS1 VS1 VS1 VS1 and VS5 parameters
10 0 0 VS2 VS2 VS2 VS2 VS2 VS2 VS2 parameter
11 0 VS4 VS4 VS4 VS4 VS4 VS4 VS4 VS4 parameter
CTRL parameter ID id8 id7 id6 0 id5 id4 id3 id2 id1 Unique DoS parameter
12
(1) (1) (0) (0) (0) (1) (0) (1) identifier
Parameter length (lg) lg8 lg7 lg6 lg5 lg4 lg3 lg2 lg1
13 Indicates 9 octets to follow.
(0) (0) (0) (0) (1) (0) (0) (1)
CURRENT CHANNEL
parameter
SUBFIELD (octets 14 to 18):

DoS
Bits 1 to 4: entry number (ent),

This may be seen as a sub-
directory flag which allows the
user to build up a DoS
database. Any received DoS
message overrides any previous
DoS message with the same
entry number.

Bits 5 to 7: additional service
information (ai) all bits set
indicating the presence of si,
anum and a fields. Note that
this is for illustration and that
gsc ai3 ai2 ai1
14 ent4 ent3 ent2 ent1 normally applications are
(1) (1) (1) (1) announced either by si OR a.
See below for further
explanation.
Bit 8 (gsc) is set indicating this
channel is a GSC.
si8 si7 si6 si5 si4 si3 si2 si1 Bits 1 to 8: service information
15 (si). Bit 1 is set indicating
(0) (0) (0) (0) (0) (0) (0) (1) availability of ADS-B.
Bits 1 to 4: application number
(anum) indicates 2 applications
anum4 anum3 anum2 anum1
16 res4 res3 res2 res1 presented below.
(0) (0) (1) (0)
Bits 5 to 8: res field (absent if
anum field is absent).
a8 a7 a6 a5 a4 a3 a2 a1 Application 1 encoded to
17 decimal equivalent 1 indicating
(0) (0) (0) (0) (0) (0) (1) (0) TIS-B.
a8 a7 a6 a5 a4 a3 a2 a1 Application 2 encoded to
18 decimal equivalent 3
(0) (0) (0) (0) (0) (0) (1) (1) indicating FIS-B.
Parameter value
CHANNEL SUBFIELD
(octets 19 to 22):
i.e. Additional DoS parameter
(optional subfield) for another
channel
gsc ai3 ai2 ai1
19 f12 f11 f10 f9 Bits 5 to 7: ai bit 5 only set
(0) (0) (0) (1)
indicating presence of, si
subfield.
Bit 8: GSC flag (gsc) set to
zero indicating a non-GSC
channel.
Octet 20 bits 1 to 8 and octet
19 bits 1 to 2: frequency (f)
denoting the operating
20 f8 f7 f6 f5 f4 f3 f2 f1 frequency of this second
channel. Note that the current
channel subfield does not
contain this field.
Bits 1 to 8: service information
si8 si7 si6 si5 si4 si3 si2 si1 (si) first two bits set indicating
21
(0) (0) (0) (0) (0) (0) (1) (1) the availability of ADS-B and
TIS-B.
sit6 sit5 sit4 sit3 sit2 sit1 Octet 22 Bits 3 to 8: service
22 pt2 pt1 information type (sit) defines
(0) (0) (0) (0) (0) (0)

the significance of each bit in
the service information field
and is itself defined by
application standards. The
Detailed Technical
23 po8 po7 po6 po5 po4 po3 po2 po1 Specifications of the Manual
VDL Mode 4 provides one
definition (00 hex) for the sit
Burst Footer
subfield and this definition is

used in the above example.
Octet 23 bits 1 to 8 and octet
22 bits 1 to 2: Reservation
data. Periodic reservation is
illustrated in this example.
CRC 24 crc crc crc crc crc crc crc crc 16-bit CRC check and end-of-
burst flag.
CRC 25 crc crc crc crc crc crc crc crc
Flag — 0 1 1 1 1 1 1 0
Table I-2A-7. Example of a compressed channel management CTRL burst format

(VDL Mode 4 header excluded)

ucid = 1 indicating
UCTRL DLPDU ucid4 ucid3 ucid2 ucid1
6 0 1 0 0 GSIF contains a DoS
(GSIF) header (0) (0) (0) (1)
parameter only
lg8 lg7 lg6 lg5 lg4 lg3 lg2 lg1 Information field is 8
Parameter length (lg) 7
(0) (0) (0) (0) (1) (0) (0) (0) octets long
CURRENT
CHANNEL
SUBFIELD
Bits 1 to 4: entry
number (ent).
Bits 5 to 7: additional
gsc ai3 ai2 ai1 service info (ai)
Parameter value 8 ent4 ent3 ent2 ent1
(1) (0) (0) (1) indicates that only the
si field is present in
the current channel
subfield;
Bit 8: GSC flag (gsc)
flag is set indicating a
GSC channel.
service information
si8 si7 si6 si5 si4 si3 si2 si1 bits 1 and 2 set
9
(0) (0) (0) (0) (0) (0) (1) (1) indicating ADS-B and
TIS-B services.

CHANNEL
SUBFIELD:
Bits 5 to 7: additional
service info (ai): bits
gsc ai3 ai2 ai1 6 and 7 set indicating
10 f12 f11 f10 f9
(1) (1) (1) (0) the presence of the
anum and a subfields.
GSC flag (gsc) set
indicating another
GSC channel
11 f8 f7 f6 f5 f4 f3 f2 f1 frequency (f)
Bits 1 to 4:
anum4 anum3 anum2 anum1 application number
12 res res res res
(0) (0) (1) (0) (anum) indicating 2
applications
a8 a7 a6 a5 a4 a3 a2 a1 application 1 (a)
13
(0) (0) (0) (0) (0) (0) (0) (0) ADS-B available
a8 a7 a6 a5 a4 a3 a2 a1 application 2 (a)
14
(0) (0) (0) (0) (0) (0) (0) (1) TIS-B available
service information
type (sit) defined to
sit6 sit5 sit4 sit3 sit2 sit1 00hex as in previous
15 pt2 pt1
(0) (0) (0) (0) (0) (0) example and defines
the si subfield for this
DoS parameter,
Octets 15 bits 1 to 2
and octet 16:
16 po8 po7 po6 po5 po4 po3 po2 po1 Reservation subfield:
Periodic reservation
used in this example
— — — — — — — — —
Appendix B to Chapter 2
AUTOMATIC DEPENDENT SURVEILLANCE —

BROADCAST IMPLEMENTATION
This appendix comprises detailed information on the format of the Automatic Dependent Surveillance — Broadcast
(ADS-B) report. References to Part II of this document — Detailed Technical Specifications of the Manual on VHF
Digital Link (VDL) Mode 4 are given.
1. FIXED DATA FIELD
ADS-B is implemented by combining information from the fixed part of the synchronization burst (see Appendix A to
Chapter 2) and various ADS-B specific variable parts.
2. VARIABLE DATA FIELDS
In order to meet the Minimum Aviation System Performance Standard (MASPS) of the Radio Technical Commission
for Aeronautics (RTCA) requirements, a set of ADS-B variable information fields have been defined. See Table I-2A-1
to Table I-2A-8.
Table I-2B-1. Encoding for ADS-B variable information fields
No. of
Information field bits Encoding Notes
Surveillance Integrity Level 3 Values 0, 1, 2 and 3 in accordance with four SIL Provides for the definition of 8
(SIL) categories specified for ADS-B MASPS by possible states
RTCA/DO-242
Navigational accuracy Values 0 through 11 in accordance with the twelve
category for position (NACP) NACP categories specified by RTCA/DO-242A
Navigational accuracy Values 0 through 4 in accordance with the five NACV
category for velocity (NACV) categories specified by RTCA/DO-242A
Latitude 4/6/8 A high-resolution component to enhance the 12-bit Different possibilities for different
low-resolution encoding transmitted in the fixed part variable parts
Longitude 4/6/8 A high-resolution component to enhance the 14-bit Different possibilities for different
low-resolution encoding transmitted in the fixed part variable parts
I-2B-1
I-2B-2 Manual on VHF Digital Link (VDL) Mode 4
No. of
Information field bits Encoding Notes
Altitude offset 7 Barometric — geometric altitude; Specific encoding
defined in Part II of this document — Detailed
Technical Specifications of the Manual on VHF
Digital Link (VDL) Mode 4.
Altitude rate flag 1 0 = barometric altitude rate
1 = geometric altitude rate
Altitude rate 9/11 Linear encoding with a step of 100 fpm 1 bit is used as climb/descend flag
(sign) and the other are used to
provide a range of ±10 250 fpm
for the 11 bit case
Ground speed 11/13 Specific encoding is specified in Table II-3-13 in 0 to 3 070 knots for 11 bits and to
Part II of this document — Detailed Technical 27 640 for 13 bits. Variable step
Specifications of the Manual on VHF Digital Link from 1 knot to 4 knots.
(VDL) Mode 4.
Ground track 11 0 = due North, Resolution is 360/2 048 = 0.1757 0° to 359.824°
degrees, linear Note.— Ground track is the
same as true track.
Turn indication 2 0 = left, 1 = right, 2 = straight, 3 = unknown
Patch ID 10 Encoding is described in Part II of this document —
Detailed Technical Specifications of the Manual on
VHF Digital Link (VDL) Mode 4.
Trajectory point/leg type 4 As per Mode S A.4.9.1 0 to 15
Trajectory change point 1 0 = invalid; 1 = valid
(TCP) data valid
TCP type 1 0 = current; 1 = next
TCP time to go 6 As per Mode S A.4.9.5
Call sign 42 Encoding for call sign:
Call sign left (csl) 1) Call sign shall be left justified
Call sign right (csr) 2) Only valid characters are A to Z, 0 to 9 and null:
Assign A to Z = 0 to 25, 0 to 9 = 26 to 35, null = 36
3) Call sign shall be an eight character string “c1, c2,
c3, c4, c5, c6, c7, c8”
4) csl = c1 363 + c2 362 + c3 36 + c4
5) csr = c5 363 + c6 362 + c7 36 + c8
Aircraft category 5 24 categories are specified in the
MASPS.
Aircraft status 3 8 categories are specified in the
MASPS.
Appendix B to Chapter 2 I-2B-3
Table I-2B-2. ADS-B information fields
Information field ID ID extension 1 ID extension 2

(id) (id1) (id2) Information field name
0 hex not present not present Basic (see Table I-2B-3)

1 hex not present not present High dynamic (see Table I-2B-4)
2 hex not present not present Full position (see Table I-2B-5)
3 hex not present not present Basic ground
4 hex not present not present UTC time
5 hex not present not present Single slot SVQ
6 to 7 hex not present not present Available for future use
9 hex not present not present TCP (see Table I-2B-6)
A hex 0 hex not present Available for future use
Aircraft data (call sign, category, status) (see
A hex 1 hex not present Table I-2B-7)
A hex 2 to 9 hex not present Available for future use
A hex A hex 0 hex High resolution (see Table I-2B-8)
A hex A hex 1 to 9 hex Available for future use
Extension (available for future use via further ID
A hex A hex A hex extension fields)
A hex A hex B to F hex Available for future use
A hex B to F hex not present Available for future use
B to E hex not present not present Available for future use
F hex not present not present No information field provided
Note.— Additional variable data fields are foreseen to meet long-term European Air Traffic Management (ATM) concept
requirements. “hex” refers to hexadecimal.
Table I-2B-3. Information field 0 hex — Basic information field:

for transmission in most synchronization bursts from mobile stations
on VHF Digital Link (VDL) Mode 4, 3.3, Table II-3-3.
Bit number
information field ID 11 x x x x 0 0 0 0
navigational accuracy category
(nac)
surveillance integrity level (sil) 12 sil2 sil1 lat66 lat65 lat64 lat63 lat62 lat61
6-bit longitude offset (lon6)
baro rate/geo rate (br/gr) 13 res br/gr lon66 lon65 lon64 lon63 lon62 lon61
baro/geo offset (bgo) 14 altr9 bgo7 bgo6 bgo5 bgo4 bgo3 bgo2 bgo1
altitude rate (altr) 15 altr8 altr7 altr6 altr5 altr4 altr3 altr2 altr1
ground speed (gs) 16 gs8 gs7 gs6 gs5 gs4 gs3 gs2 gs1
Bit number
17 gs11 gs10 gs9 gt5 gt4 gt3 gt2 gt1
ground track (gt) 18 gt11 gt10 gt9 gt8 gt7 gt6
Note.— “x” denotes part of the fixed data field “res” denotes currently unused.
Table I-2B-4. Information field 1 hex — High dynamic:

provides higher resolution for faster moving aircraft.
Bit number
baro rate/geo rate (br/gr),
baro/geo offset (bgo) 12 br/gr bgo7 bgo6 bgo5 bgo4 bgo3 bgo2 bgo1
altitude rate (altr) 13 altr8 altr7 altr6 altr5 altr4 altr3 altr2 altr1
Surveillance integrity level (sil) 14 altr9 sil3 sil2 res gs12 gs11 gs10 gs9
4-bit longitude offset (lon4),
4-bit latitude offset (lat4) 16 lon44 lon43 lon42 lon41 lat44 lat43 lat42 lat41
17 gt8 gt7 gt6 gt5 gt4 gt3 gt2 gt1
ground track (gt) 18 gt12 gt11 gt10 gt9 res res
Table I-2B-5. Information field 2 hex — Full position:

provides an unambiguous global position.
Bit number
6-bit latitude offset (lat6) 12 pid10 pid9 lat66 lat65 lat64 lat63 lat62 lat61
baro/geo offset (bgo) 14 gt11 bgo7 bgo6 bgo5 bgo4 bgo3 bgo2 bgo2
Bit number
6-bit longitude offset (lon6) 15 gt10 gt9 lon66 lon65 lon64 lon63 lon62 lon61
ground track (gt) 16 gt8 gt7 gt6 gt5 gt4 gt3 gt2 gt1
Surveillance integrity level (sil) 18 gs11 gs10 gs9 sil3 sil2 res
Note.— “x” denotes part of fixed data field; “res” denotes currently unused.
Table I-2B-6. Information field 9 hex — Trajectory Check Point (TCP):

provides the possibility to transmit a TCP.
on VHF Digital Link (VDL) Mode 4, 3.3, Table II-3-8b.
Bit number
base altitude (balt) 12 balt8 balt7 balt6 balt5 balt4 balt3 balt2 balt1
TCP number (no) 13 balt12 balt11 balt10 balt9 no2 no1 pid10 pid9
latitude (lat) 15 lat8 lat7 lat6 lat5 lat4 lat3 lat2 lat1
16 lat12 lat11 lat10 lat9 lon14 lon13 lon12 lon10
longitude (lon)
17 lon10 lon9 lon8 lon7 lon6 lon5 lon4 lon3
time to go (ttg) 18 ttg6 ttg5 ttg4 ttg3 ttg2 ttg1
Table I-2B-7. Information field A1 hex — Aircraft data

(contains the aircraft call sign)
Bit number
aircraft category (ac) 12 0 0 0 1 ac4 ac3 ac2 ac1
status (st) 13 ac5 st3 st2 st1 csl 12 csl 11 csl 10 csl9
call sign left (csl) 14 csl 8 csl 7 csl 6 csl 5 csl 4 csl 3 csl 2 csl1
Bit number
15 csl 20 csl 19 csl 18 csl17 csl 16 csl 15 csl 14 csl 13
16 csl 21 csr 7 csr 6 csr 5 csr 4 csr 3 csr 2 csr1
call sign right (csr) 17 csr 15 csr 14 csr 13 csr 12 csr 11 csr 10 csr 9 csr8
18 csr 21 csr 20 csr 19 csr 18 csr 17 csr16
Note. — “x” denotes part of the fixed data field.
Table I-2B-8. Information field AA0 hex — High resolution:

dedicated for use by high performance aircraft
Bit number
11 x x x x 1 0 1 0
information field ID
12 1 0 1 0 0 0 0 0
Surveillance integrity level (sil) 13 res sil3 sil2 res gs12 gs11 gs10 gs9
8-bit longitude offset (lon8) 16 lon88 lon87 lon86 lon85 lon84 lon83 lon82 lon81
8-bit latitude offset (lat8) 17 lat88 lat87 lat86 lat85 lat84 lat83 lat82 lat81
ground track (gt) 18 gt8 gt7 gt6 gt5 gt4 gt3 gt2 gt1
turn indication (tind) 18 gt12 gt11 gt10 gt9 tind2 tind1
— — — — — — — — —
Appendix C to Chapter 2
COMPACT POSITION REPORTING

(CPR) ENCODING ALGORITHM
1. CHARACTERISTICS OF THE
COMPACT POSITION REPORTING (CPR) ALGORITHM
1.1 The Compact Position Reporting (CPR) algorithm was designed originally for use with Mode S bit encoding,
the purpose of which is to obtain a full position report by using the smallest possible number of bits.
1.2 The raw latitude and longitude values from the aircraft’s avionics are divided into CPR-encoded low
resolution components which are sent in the fixed data field of the synchronization burst, and high resolution offset
components that may be sent with one or more of the different variable data fields.
1.3 The low resolution components are 12 bits in length for latitude and 14 bits in length for longitude, while the
high resolution offsets consist of either 4, 6, or 8 bits. The use of 14 bits for the low resolution longitude encoding, as
opposed to 12 bits for latitude encoding, is to compensate for the fact that maximum errors in the longitude encoding
were found to be nearly four times greater than those in the latitude encoding, with the longitude errors being highest
near the polar regions.
1.4 To send position information, the CPR encoding algorithm is first used to encode the 12/14-bit low resolution
components in the fixed data field of the synchronization burst. Then the encoding for the high resolution offset
components is performed.
1.5 When a position report is received, the 12/14-bit low resolution components are first decoded with the CPR
algorithm. Depending on the resolution required, one of the high resolution offset components may have been
transmitted in one of the variable data fields of the synchronization burst. If so, the high resolution component may
then be added to the 12/14-bit position to improve the overall resolution.
1.6 Single reports may be decoded if a reference position is already known. Alternate position reports are encoded
slightly differently as either even format or odd format reports in order to permit globally unambiguous decoding by the
combination of consecutively received reports of opposing format. Thus:
• A single 12/14-bit encoded position report may be unambiguously decoded over a range of 1 113 km
(601 NM), with a resolution of approximately ±140 m for latitude and ±120 m for longitude. In this case, an
observer or reference position must be known and be within ±557 km (±300.5 NM) of the position to be
decoded. The reference position will in most cases be the last globally unambiguous position to be decoded.
• A pair of 12/14-bit encoded position reports (i.e. one of even and one of odd format) may be unambiguously
decoded globally, with a resolution of approximately ±140 m for latitude and ±120 m for longitude, when the
two reported positions are separated by less than 15.9 km (8.57 NM). For typical aircraft velocities (625 knots),
this permits the use of odd and even position reports of up to 50 seconds apart.
I-2C-1
I-2C-2 Manual on VHF Digital Link (VDL) Mode 4
Note.— CPR is an angle compression algorithm. References to distances in this section are approximate and based
on 6 378 km (3 442 NM) earth radius, 60.1 NM per latitude degree, and 1 852 m/NM.
2. REPRESENTATION OF LATITUDE AND LONGITUDE ANGLES
2.1 In the VDL Mode 4 CPR algorithm, as illustrated in Figure I-2C-1, angle is represented by an integer in the
range of 0 to MAXC. The value of MAXC is defined as 251 for 64-bit signed integer encoding and decoding. However, a
lower value of MAXC may be used for 32-bit signed integer decoding.
2.2 The range of 0 to MAXC maps onto the angle range of 0 to 360 degrees. This representation will be used in the
following discussion. With this scale, the northern latitudes range from 0 to MAXC/4 and the southern latitudes range
from 3MAXC/4 to MAXC. Longitude ranges from 0 at Greenwich, increasing Eastward around the globe to a value of
just less than MAXC immediately west of Greenwich.
2.3 The CPR uses a local orthonormal approximation to a Cartesian coordinate, which will be used here to
support position reporting over a range of 1 113 km (601 NM). To do this, the angle scale is divided into 36 segments,
each 10 degrees wide (i.e. 601 NM or 1 113 km). In latitude, 9 segments cover the northern hemisphere (i.e. 0 to
MAXC/4) and 9 segments cover the southern hemisphere (i.e. 3MAXC/4 to MAXC). In longitude, the number of segments
is varied from 35 at the equator to 1 at the poles; in a way, this keeps the dimension of the narrowest segment in each
region roughly equal to 10 latitude degrees (601 NM or 1 113 km).
0 MAXc/4 MAXc/2 3MAXc/4 MAXc
(0°) (90°) (180°) (270°) (360°)
Figure I-2C-1. Angle scale based on integer representation
3. COMPACT POSITION REPORTING (CPR):

CONSTANTS, VARIABLES AND FUNCTIONS
3.1 Constants used in the CPR calculations are given in Table I-2C-1.
Table I-2C-1. Constants used in Compact Position Reporting (CPR) calculations
Type Constant Value Description
Integer LATZ 9 Number of zones from 0° to 90° latitude.

Integer MAXC = 251 Maximum value for longitude and latitude.
Integer MAXTlat = 212 1 Maximum transmitted latitude value.
Integer MAXTlon = 214 1 Maximum transmitted longitude value.
Appendix C to Chapter 2 I-2C-3
3.2 CPR calculations convert between three representations of a station’s position, namely:
1) The external representation of latitude and longitude which is meaningful to applications.
2) The internal representation which provides an integer representation of the position.
3) The link representation which is the encoded position.
Tables I-2C-2 and I-2C-3 divide the variables and functions used in the CPR calculations into these three categories.
The type and range restrictions of the variables used in CPR calculations are defined in Table I-2C-2.
Note.— When a user of VDL Mode 4 services would only use the values of latitude and longitude available outside
the VDL Mode 4 box, this is the external representation. When VDL Mode 4 equipment needs some method for storing
position internally in integer format, this is referred to as the integer representation. When VDL Mode 4 needs an
efficient way of relaying position information across the link, this is referred to as the link representation. CPR
encoding in general provides a means of relating between these three representations.
Table I-2C-2. Variables used in CPR calculations
Type Name Range Description
External representation
Real latitude [0,90], [270, 360] The input latitude (arbitrary precision real number).
Real longitude [0,360] The input longitude (arbitrary precision real number).
Internal representation
Integer type, typelast 0 or 1 The type of CPR (0 = even, 1 = odd).
Integer clatin, clonin [0, MAXC] Latitude and longitude to be encoded.
Temporary variable number n. Only used to make expressions and
Integer tmpn [0, MAXC] functions more readable.
Integer clatref [0, MAXC] Reference latitude for local decoding.
Integer clonref [0, MAXC] Reference longitude for local decoding.
Integer x Any integer.
Integer pos1, pos2 [0, MAXC] A latitude or longitude.
Integer clatdec [0, MAXC] Decoded latitude.
Integer clondec [0, MAXC] Decoded longitude.
Integer bits 3, 5 or 7 Number of bits in the correction message.
Integer latoffs [0, 2bits – 1] Latitude correction.
Integer slat 0 or 1 Sign of the latitude correction.
Integer lonoffs [0, 2bits – 1] Longitude correction.
Integer slon 0 or 1 Sign of the longitude correction.
Integer latp [0, 19] The latitude patch.
Integer lonp (pid) [0, 35] The longitude patch.
Link representation
Integer cprf 0 or 1 CPR format even/odd
Integer lat [0, MAXTlat] Encoded latitude.
Integer lon [0, MAXTlon] Encoded longitude.
Integer latref, lat0, lat1 [0, MAXTlat] Encoded latitude.
Integer lonref, lon0, lon1 [0, MAXTlon] Encoded longitude.
Integer lat4, lat6, lat8 [0, 2bits +1 – 1] Encoded latitude offset
Integer lon4, lon6, lon8 [0, 2bits +1 – 1] Encoded longitude offset
Integer pid [0, 719] Encoded patch id (pid).
Note 1.— [A, B] means greater than or equal to A and less than or equal to B.
Note 2.— All CPR computations use integer-valued longitude and latitude (in the range of [0, MAXC], where each
step is 360/(MAXC + 1) ≈ 0.1598721155 x 10 -12 degrees).
Table I-2C-3. Input parameters and return values for functions used in CPR calculations
Type Name Description
Function returns value in internal representation

Integer nz(type) Number of zones depending on the type (odd/even) of CPR format.
Integer dlat(type) Latitude patch size for type type.
Integer nl(clatin, type) Looks up the value in the transition level table (Table II-4-5).
Integer dlon(clatin, type) Longitude patch size at latitude clatin for type type.
Integer latofs(lat, latref) Latitude zone offset.
Integer lonofs(lon, lonref) Longitude zone offset.
Integer declat(clatref, lat, latref, type) Local latitude decoding.
Integer declon(clatdec, clonref, lon, lonref, type) Local longitude decoding.
Integer latseg(lat0, lat1, typelast) Latitude segment for global decoding.
Integer lonseg(lon0, lon1, clatin, typelast) Longitude segment for global decoding.
Integer globalDeclat(lat0, lat1, typelast) Global latitude global.
Integer globalDeclon(lon0, lon1, clatdec, typelast) Global longitude global.
Integer fix(x) Converts negative coordinates to positive.
Integer lookup(clatin, type) The value that corresponds to clatin and type in the transition level table.
Integer diff(pos1, pos2) The (shortest) distance between pos1 and pos2.
Integer sign(pos1, pos2) The sign of diff(pos1, pos2).
Integer offsetdeclat(latoff, slat, bits, type) Calculates the true offset for the latitude offset given in bits bits.
Integer offsetdeclon(clatdec, lonoff, slon, bits, type) Calculates the true offset for the longitude offset given in bits bits.
Integer latp(clatin, type) Calculates the latitude patch.
Integer lonp(clatdec, clonin, type) Calculates the longitude patch.
Integer fullDeclat(lat, latp, type) Decodes full position latitude.
Integer fullDeclon(clatdec, lon, lonp, type) Decodes full position longitude.
Function returns value in link representation
Integer enclat(clatin, type) Returns the CPR encoded value for clatin using type type.
Integer enclon(clatdec, clondec, lat, type) Returns the CPR encoded value for clonin using type type.
Integer offsetenclat(clatin, clatdec, bits, type) The difference between clatin and clatdec expressed using bits bits.
Integer offsetenclon(clatdec, clonin, clondec, bits, type) The difference between lonin and clondec expressed using bits bits.
Integer encpatch(latp, lonp) Encode the patch id (pid).
3.3 The “modulo” function denoted MOD(n, d) accepts two arguments and returns the remainder of its first
argument divided by its second argument. The result has the same sign as the second argument. The function can also
be expressed as:
MOD(n, d) = n – d • INT(n/d)
Where n is the numerator and d is the denominator.
For example, MOD(–15.456, 59) = 43.544.
3.4 The number of longitude segments, nl, is obtained from a function lookup(clatdec, type) in Table I-2C-3. The
received latitude, clatdec, is used to look up the value of nl in Table I-2C-4. First clatdec is converted into a northern
hemisphere latitude (i.e. a value between 0 and MAXC/4):
IF (clatdec > MAXC/2 ) THEN clatdec = MAXC – clatdec
ELSE clatdec = clatdec
Then clatdec is compared with the latitude ranges given in the Transition latitude lookup table (Table I-2C-4) and with
the corresponding value of nl obtained in the table.
Table I-2C-4. Transition latitude lookup table
Latitude range (based on MAXC = 251) nl Latitude range (based on MAXC = 251) nl
< 84559299976949 35 [374509087692437, 385839842234890] 17

[84559299976949, 119863286269066] 34 [385839842234890, 396973067553844] 16
[119863286269066, 147147092426093] 33 [396973067553844, 407927071618287] 15
[147147092426093, 170314332279771] 32 [407927071618287, 418717654880330] 14
[170314332279771, 190874016391806] 31 [418717654880330, 429358297069654] 13
[190874016391806, 209598760787195] 30 [429358297069654, 439860192688716] 12
[209598760787195, 226946895939473] 29 [439860192688716, 450232093501524] 11
[226946895939473, 243216719782307] 28 [450232093501524, 460479863588517] 10
[243216719782307, 258615264457015] 27 [460479863588517, 470605547878490] 9
[258615264457015, 273293195154609] 26 [470605547878490, 480605524480339] 8
[273293195154609, 287364232684706] 25 [480605524480339, 490466748984332] 7
[287364232684706, 300916739329498] 24 [490466748984332, 500158557411138] 6
[300916739329498, 314021014573143] 23 [500158557411138, 509612576768200] 5
[314021014573143, 326734093052511] 22 [509612576768200, 518663923862256] 4
[326734093052511, 339103013392294] 21 [518663923862256, 526821353991124] 3
[339103013392294, 351167110605961] 20 [526821353991124, 531674956009016] 2
[351167110605961, 362959661644475] 19 ≥ 531674956009016 1
[362959661644475, 374509087692437] 18
Note 1.— The table search procedure (e.g. binary search) may be used to obtain the value of nl for a particular
latitude. The final value of nl is decremented if type is odd and nl is not 1:
IF (nl > 1) nl = nl – type
Note 2.— The following formula summarizes the process described in Note 1 of Table I-2C-4:
nl (clat in , type ) = lookup ( clat in , type ) if clat in < MAX C 2
Otherwise , nl ( clat in , type ) = lookup ( MAX C – clatin , type )
Note 3.— The following equation may be used in computing the table of transition latitudes:
1
MAX C 1 − cos (π /18 ) 2
TransitionLat = arccos for nl = 35 to 2
2π 1 − cos ( 2π / nl )
4. COMPACT POSITION REPORTING (CPR) ENCODING
4.1 Overview
The CPR encoding process calculates the encoded 12/14-bit position values lat and lon from the given latitude and
longitude, and the CPR format type (0 for even format and 1 for odd format) by performing the sequence of
computations in the Tables I-2C-5, I-2C-6, and I-2C-7. Each line in the tables is numbered for references made in the
descriptions that follow the tables in 4.2, 4.3 and 4.4 of Appendix C to Chapter 2.
Table I-2C-5. Fixed data field latitude/longitude encoding
Parameter Equation Example
Given parameters
1 type = (0, 1) 0
2 latitude = 84.1234567680
3 longitude = 125.4651379560
4 clatin = INT(latitude • (MAXC + 1) / 360) 526 192 178 546 504
5 clonin = INT(longitude • (MAXC + 1) / 360) 784 784 372 981 430
Latitude encoding
6 nz(type) = 4 • LATZ type 36
7 dlat(nz) = INT[MAXC / nz(type)] 62 549 994 824 590
8 tmp1 = 2 • MAXTlat 8 190
9 tmp2 = INT(MAXC / tmp1) 274 945 032 196
10 tmp3 = INT(MAXC / MAXTlat) 549 890 064 392
11 tmp4 = nz(type) • MOD[clatin, dlat(type)] + tmp2 928 794 863 224 420
12 lat = enclat(clatin,type) = INT(tmp4 / tmp3) 1 689
Longitude encoding
13 tmp5 = dlat(type) • INT[clatin / dlat(type)] 500 399 958 596 720
15 tmp7 = tmp6 • lat 928 764 318 758 088
16 clatdec = declat(clatin,lat,lat,type) = INT[tmp7 / nz(type)] + tmp5 526 198 967 451 111
17 tmp8 = lookup(clatdec,type) 3
18 nl(clatdec,type) = IF (tmp8 > 1) nl = tmp8 type, ELSE nl = tmp8 3
19 dlon(clatdec,type) = INT[MAXC / nl(clatdec,type)] 750 599 937 895 083
20 tmp9 = 2 • MAXTlon 32 766
21 tmp10 = INT(MAXC / tmp9) 68 723 671 296
22 tmp11 = INT(MAXC / MAXTlon) 137 447 342 592
23 tmp12 = nl(clatdec,type) • MOD[clonin, dlon(clatdec,type)] + tmp10 102 622 028 930 337
24 lon = enclon(clatdec,clonin,lat,type) = INT(tmp12 / tmp11) 746
4.2 Fixed data field latitude/longitude encoding
4.2.1 In Table I-2C-5, the parameter name is in Column 2, Column 3 contains the equation, and the Column 4
gives a numeric example to illustrate the equation. The example in Column 4 is explained in 4.2.2 to 4.2.7 and
illustrated in Figure I-2C-2, and this same example is used in the subsequent decoding sample equations.
4.2.2 The process starts with inputs (lines 1 to 3). The CPR format, type, is either even (0) or odd (1). Latitude
and longitude are input as degrees (real numbers) and then expressed as integers in lines 4 and 5. This example is for
even format encoding of latitude = 84.12...° (5.26...E+14) and longitude = 125.46...° (7.84...E+14).
4.2.3 The latitude encoding lines 6 to 12 are paralleled by the longitude encoding lines 18 to 24. In line 6 the
latitude angle scale is divided into 36 equal zones (35 if type = 1), and the width of a latitude segment is calculated in
line 7. The longitude scale is divided in line 18 into nl = 3 equal segments, based on a table lookup using the decoded
latitude clatdec, and the value of type. The width of a longitude segment is calculated in line 19.
4.2.4 We describe the longitude encoding in detail by rewriting lines 20 to 24 more clearly as follows:
MOD ( clonin , dlon ) 1

lon = MAX Tlon +
dlon 2
The actual calculations are not performed in the order indicated by this equation because of the restrictions imposed by
integer division, integer truncation, and the requirement never to exceed MAXC in any calculation.
4.2.5 Referring to the formula in 4.2.4, the term MOD(clonin, dlon) gives the remainder after the input latitude is
divided by the width of a segment dlon. Division of this by the segment width dlon gives a segment fraction. This
quantity, within the square brackets, is multiplied by the maximum integer which can be transmitted, MAXTlon, in order
to give the encoded value. As this must be truncated in conversion to type integer, an extra ½ is added to negate the
effect of the truncation.
4.2.6 To illustrate the longitude encoding, we have divided the angle range of 0 to MAXC into nl = 3 equal
segments as shown in Figure I-2C-2.
4.2.7 In this example in Table I-2C-5, clonin is at a slightly greater angle than the width of one segment. It
therefore has a segment index (SI) of 1 that is not transmitted in the fixed part of the synchronization burst, and a
segment fraction (SF) of 0.045... that is equal to MOD(clonin, dlon)/dlon and which is transmitted after multiplication
by MAXTlon.
SI = 0 1_SF = 0.045 2 nl = 3
MAXc
lon
Figure 1-2C-2. Illustration of longitude encoding

Table I-2C-6. Information field offset encoding
Information field offset encoding — Latitude
25 diff(clatin,clatdec) = clatin – clatdec – 6 788 904 607

IF (diff(clatin,clatdec) ≥ 0), THEN sign = 1
26 sign(clatin,clatdec) = ELSE sign = 0 0
27 tmp3Y = 2 • nz(type) • MAXTlat • (23 – 1) 2 063 880
28 tmp3Y2 = INT(MAXC / tmp3Y) 1 091 051 715
lat4(bits 1 to 3) =
29 offsetlatenc(clatin,clatdec,3,type) = INT{[|diff(clatin,clatdec)| + INT(tmp3Y2 / 2)] / tmp3Y2} 6
30 lat4(bit 4) = sign(clatin,clatdec) 0
32 tmp5Y2 = INT(MAXC / tmp5Y) 246 366 516
lat6(bits 1 to 5) =
36 tmp7Y2 = INT(MAXC / tmp7Y) 60 136 708
lat8(bits 1 to 7) =
Information field offset encoding — Longitude
39 tmp15 = dlon(clatdec,type) • INT[clonin / dlon(clatdec,type)] 750 599 937 895 083

41 tmp17 = tmp16 • lon 102 535 717 573 632
42 clondec = declon(clatdec,clonin,lon,lon,type) = INT[tmp17 / nl(clatdec,type)] + tmp15 784 778 510 419 627
43 diff(clonin,clondec) = clonin - clondec 5 862 561 803
IF[diff(clatin,clatdec) ≥ 0]
44 sign(clatin,clatdec) = THEN sign = 1; ELSE sign = 0 1
45 tmp3X = 2 • nl(clatdec,type) • MAXTlon • (23 – 1) 688 086
46 tmp3X2 = INT(MAXC / tmp3X) 3 272 555 776
lon4(bits 1 to 3) =
47 offsetlonenc(clonin,clondec,3,type) = INT{[|diff(clonin,clondec)| + INT(tmp3X2 / 2)] / tmp3X2} 2
48 lon4(bit 4) = sign(clonin,clondec) 1
49 tmp5X = 2 • nl(clatdec,type) • MAXTlon • (25 – 1) 3 047 238
50 tmp5X2 = INT(MAXC / tmp5X) 738 964 207
lon6(bits 1 to 5) =
53 tmp7X = 2 • nl(clatdec,type) • MAXTlon • (27 – 1) 12 483 846
54 tmp7X2 = INT(MAXC / tmp7X) 180 377 090
lon8(bits 1 to 7) =
4.3 Information field offset encoding
4.3.1 The high resolution latitude offset is encoded in Table I-2C-6 in lines 25 to 38. The high resolution
longitude offset is encoded in lines 43 to 56, following calculation of the decoded longitude clondec in lines 39 to 42.
4.3.2 In the case of longitude, the offset diff is calculated as the difference between the actual longitude clonin and
the decoded longitude clondec in line 43. The sign of the offset is then output as a single bit sign in line 44.
4.3.3 The magnitude of the longitude offset diff is encoded differently according to the resolution required, either
as 3, 5, or 7 extra bits. The offset magnitude is encoded as a fraction of the maximum possible offset which can occur
through rounding errors, which for longitude is:
MAX C
.
2 ⋅ nl ⋅ MAX Tlon
4.3.4 The fraction is expressed as an integer (e.g. lon4(bits 1 to 3)) by multiplying by the range available for
encoding the offset magnitude, either 23 1, 25 1, or 27 1. A similar method is used for encoding the latitude offset.
4.4 Patch ID encoding
4.4.1 The patch ID (pid) is encoded in Table I-2C-7 in lines 57 to 60. It was noted in 4.2 of this Appendix C to
Chapter 2 that the segment index (SI) is not transmitted in the fixed part of the synchronization burst. The pid encodes
both the latitude and longitude SIs, latp and lonp as a single quantity pid. The pid may be sent in a variable part of the
synchronization burst such that when pid is decoded, providing the latitude and longitude SIs, the pid allows a single
position report to provide an unambiguous global position.
4.4.2 Latp and lonp are calculated in lines 58 and 59, and combined into an encoded patch ID (pid) in line 60. The
southern hemisphere segment indexes (SIs) are decremented by 16 in order to reduce the maximum size of the quantity
pid, and thereby save on bits.
Table I-2C-7. Patch ID (pid) encoding
Patch ID encoding
57 tmp18 = INT(MAXC / 4) 562 949 953 421 312
IF (clatin tmp18)
THEN latp = INT[clatin / dlat(type)]
ELSE IF (clatin > tmp18)
58 latp = THEN latp = INT[clatin / dlat(type)] - 16 8
59 lonp = clonin / dlon(clatdec, type) 1
60 pid = encpatch(latp, lonp) = 36 • latp + lonp
289
4.5 Transmitted parameters
The resultant parameters which may be transmitted in the fixed and variable parts of the synchronization burst message
are summarized in Table I-2C-8.
Table I-2C-8. Parameters sent in the synchronization burst
Synchronization burst
Fixed part Variable part
CPR- 12/14-bit Patch ID One of the following offset outputs

format output (pid) 3-bit 5-bit 7-bit
Latitude type = 0 lat = 1 689 pid = 289 lat4(bits 1 to 3) = 6 lat6(bits 1 to 5) = 28 lat8(bits 1 to 7) = 113
lat4(bit 4) = 0 lat6(bit 6) = 0 lat8(bit 8) = 0
Longitude lon = 746 lon4(bits 1 to 3) = 2 lon6(bits 1 to 5) = 8 lon8(bits 1 to 7) = 33
lon4(bit 4) = 1 lon6(bit 6) = 1 lon8(bit 8) = 1
5. COMPACT POSITION REPORTING (CPR)

DECODING FROM A SINGLE REPORT
5.1 Overview
Each CPR can be decoded with full precision within an angle range equal to one segment. The quasi-orthonormal
encoding gives a one-segment decoding range of about 1 113 km (601 NM). This decoding range is usually positioned
with its centre at the observing sensor location, but it could be shifted toward more likely locations, as in the case of a
sensor with a directional antenna. So, in addition to the received report (lat, lon, type), the decoding of a single report
needs a position for the decoding range — usually the observer position (latref, lonref). These inputs are used in the
decoding equations outlined in Tables I-2C-9, I-2C-10 and I-2C-11. Again, the examples are on the right columns of
the tables.
5.2 Fixed data field latitude/longitude decoding
5.2.1 In Table I-2C-9, the latitude decoding lines 6 to 22 are paralleled by the longitude decoding lines 24 to 40.
The number of latitude segments, nz, is determined from type, while the number of longitude segments, nl, must await a
table lookup following decoding of the received latitude, clatdec. The encoded values corresponding to the observer’s
position are calculated in lines 6 to 12 and 24 to 30.
5.2.2 In the example illustrated in Figure I-2C-3, the observing sensor, with longitudinal position lonref, is located
to the East of the reporting aircraft, that is located at a longitude of lon. Note that the observing sensor assumes that the
reporting aircraft's position is within the one-segment decoding range when only one report is available. Note that this
potential ambiguity is removed when both even and odd reports have been received (see Section 6 of this appendix).
The one-segment decoding range, denoted by the dashed arrow, extends to the west by half a segment and includes the
position of the reporting aircraft.
5.2.3 To determine the segment index of the reporting aircraft, the relative position of the reporting aircraft to the
observer is computed in the segment offset adjustment, latoffs and lonoffs, in lines 13 to 17 and 31 to 35 of Table I-2C-9.
The adjustment will be the following:
• -1 if the reporting aircraft is in the segment to the left of the observer;
• 0 if it is in the same segment; or
• 1 if it is in the segment to the right of the observer.

5.2.4 In the example in Table I-2C-9 and Figure I-2C-3, the observer is in the second segment. The adjustment
lonoffs = 0 because the reporting aircraft is also in the second segment. The segment index of the reporting aircraft is the
sum, INT(clonref/dlon) + lonoffs = 1 (line 36). The adjustment is added to the segment index of the observer and
multiplied by the segment width in lines 18 and 36, giving the total number of the whole segments for the reporting
aircraft.
5.2.5 The contribution from whole segments and the remaining fraction of a segment (obtained from lon/MAXTlon)
are added to obtain the total decoded latitude and longitude in line 39. This is converted to an angle in degrees in
line 40.
Table I-2C-9. Fixed data field latitude/longitude decoding
Received parameters
1 type = 0
2 lat = 1 689
3 lon = 746
4 clatref = 523 070 194 310 757
5 clonref = 961 696 813 007 057
Latitude decoding
6 nz(type) = 4 • LATZ type 36
7 dlat(type) = INT[MAXC / nz(type)] 62 549 994 824 590
8 tmp1 = 2 • MAXTlat 8 190
9 tmp2 = INT(MAXC / tmp1) 274 945 032 196
11 tmp4 = nz(type) • MOD[clatref, dlat(type)] + tmp2 816 403 430 737 528
12 latref = enclat(clatref,type) = INT(tmp4 / tmp3) 1 484
13 tmp5 = latref lat -205
lat
14 tmp6 = MAXT / 2 2 048
15 tmp7 = IF(tmp5 > tmp6) tmp7 = 1 ELSE tmp7 = 0 0
16 tmp8 = IF(tmp5 < - tmp6) tmp8 = -1 ELSE tmp8 = 0 0
17 latoffs(lat, latref) = tmp7 + tmp8 0
dlat(type) • {INT[clatref / dlat(type)] +
18 tmp9 = latoffs(lat, latref)} 500 399 958 596 720
20 tmp11 = tmp10 • lat 928 764 318 758 088
21 clatdec = declat(clatref,lat,latref,type) = INT[tmp11 / nz(type)] + tmp9 526 198 967 451 111
22 latitude = 360 • clatdec / (MAXC + 1) 84.1245 421245
Longitude decoding
23 tmp12 = lookup(clatdec, type) 3
IF (tmp12 > 1) nl = tmp12 type, ELSE nl =
24 nl(clatdec,type)= tmp12 3
25 dlon(clatdec,type) = INT[MAXC / nl(clatdec,type)] 750 599 937 895 083
Parameter Equation Example Parameter

lon
26 tmp13 = 2 • MAXT 32 766
27 tmp14 = INT(MAXC / tmp13) 68 723 671 296
nl(clatdec,type) • MOD[clonref, dlon(clatdec,type)]
29 tmp16 = + tmp14 633 359 349 007 218
lonref = enclon(clatdec, clonref, lat,
30 type) = INT(tmpd16 / tmpd15) 4 608
31 tmp17 = lonref lon 3 862
32 tmp18 = MAXTlon / 2 8 191
33 tmp19 = IF(tmp17 > tmp18) tmp19 = 1 ELSE tmp19 = 0 0
34 tmp20 = IF(tmp17 < -tmp18) tmp20 = -1 ELSE tmp20 = 0 0
35 lonoffs(lon,lonref) = tmp19 + tmp20 0
dlon(clatdec,type) • {INT[clonref /
36 tmp21 = dlon(clatdec,type)] + lonoffs(lon,lonref)} 750 599 937 895 083
lon
37 tmp22 = INT(MAXC / MAXT ) 137 447 342 592
38 tmp23 = tmp22 • lon 102 535 717 573 632
39 clondec = INT[tmp23 / nl(clatdec,type)] + tmp21 784 778 510 419 627
40 longitude = 360 • clondec / (MAXC + 1) 125.4642006958
0 SI = 1 2 nl = 3
0 MAXc
lonref
lon
Figure 1-2C-3. Illustration of longitude decoding
5.3 Information field offset decoding
5.3.1 In Table I-2C-10, decoding of the high resolution latitude and longitude offsets takes place in lines 45 to 50
and 51 to 56. This example only illustrates decoding of the highest resolution 8-bit offsets and describes how the
longitude offset is decoded.
5.3.2 The maximum possible offset which can occur through rounding errors, which for longitude is expressed as
follows:
MAX C
2 ⋅ nl ⋅ MAX Tlon
is multiplied in lines 51 to 53 by the encoded offset over the maximum encoding range, i.e. lonoffs/(27 1). The result is
adjusted to the correct sign in line 54. Finally, the offset is added to the decoded latitude or longitude in line 55, and
converted to a new value in degrees in line 56.
Table I-2C-10. Information field offset decoding

Received offset parameters
41 slat = lat8(bit 8) 0
42 latoffs = lat8(bits 1 to 7) 113
43 slon = lon8(bit 8) 1
44 lonoffs = lon8(bits 1 to 7) 33
Offset decoding
45 tmp24 = 2 • MAXTlat • nz(type) • (27 1) 37 444 680
46 tmp25 = INT(MAXC / tmp24) 60 136 708
47 tmp26 = tmp25 • latoffs 6 795 448 004
IF(slat = 1)
THEN offsetlatdec = tmp26
48 offsetlatdec(latoffs,slat,bits,type) = ELSE offsetlatdec = - tmp26 -6 795 448 004
49 clatdec(+offset8) = clatdec + offsetlatdec 526 192 171 768 198
50 latitude(+offset8) = 360 • clatdec(+offs8) / (MAXC + 1) 84.1234556843
lon 7
51 tmp27 = 2 • MAXT • nl(clatdec,type) • (2 1) 12 483 846
52 tmp28 = INT(MAXC / tmp27) 180 377 090
53 tmp29 = tmp28 • lonoffs 5 952 443 970
IF(slon = 1)
THEN offsetlondec = tmp29
54 offsetlatdec(clatdec,lonoffs,slon,bits,type) = ELSE offsetlondec = - tmp29 5 952 443 970
dec
55 clondec(+offset8) = clondec + offsetlat 784 784 463 568 195
56 longitude(+offset8) = 360 • clondec(+offs8) / (MAXC + 1) 125.4651524383
5.4 Patch ID (pid) decoding
5.4.1 In Table I-2C-11, decoding by using the patch ID (pid) to obtain an unambiguous global position from a
single report is performed in lines 58 to 62 for latitude and 63 to 70 for longitude.
5.4.2 To describe the process for longitude, the number of whole longitude segments for the reporting aircraft is
calculated from pid in line 63 as lonp. The value obtained for clatdec in line 62 is used in lines 65 and 66 in the
calculation of nl and dlon. The number of whole segments dlon • lonp and the remaining fraction of a segment
(obtained from lon/MAXTlon) are added to get the total decoded latitude and longitude in lines 62 and 70.
Table I-2C-11. Patch ID (pid) decoding
Received patch ID
57 pid = 289
Patch ID decoding
IF (pid 359)
THEN latp = pid / 36
58 latp = ELSE latp = pid / 36 + 16 8
lat
59 tmp30 = INT(MAXC / MAXT ) 549 890 064 392
60 tmp31 = tmp30 • lat 928 764 318 758 088
61 tmp32 = INT[tmp31 / nz(type)] 25 799 008 854 391
62 clatdecp = fullDeclat(lat,latp,type) = tmp32 + dlat(type) • latp 526 198 967 451 111
63 lonp = MOD(pid, 36) 1
64 tmp33 = lookup(clatdecp,type) 3
IF (tmp33 > 1) nl = tmp33 - type,
65 nl(clatdecp,type)= ELSE nl = tmp33 3
66 dlon(clatdecp,type) = INT[MAXC / nl(clatdecp,type)] 750 599 937 895 083
lon
67 tmp34 = INT(MAXC / MAXT ) 137 447 342 592
68 tmp35 = tmp34 • lon 102 535 717 573 632
69 tmp36 = INT[tmp35 / nl(clatdecp,type)] 34 178 572 524 544
clondecp =
70 fullDeclon(clatdecp,lon,lonp,type) = tmp36 + dlon(clatdecp,type) • lonp 784 778 510 419 627

GLOBAL DECODING WITH TWO REPORTS
6.1 Compact Position Reporting (CPR) is designed so that an unambiguous global position can be recovered from
two successive reports of different format type (i.e. one even and one odd). The spatial positions broadcast in
successive odd and even reports must be fairly close together in order to obtain a valid global position. The maximum
distance which can be tolerated between points in the latitude direction is about ±15.9 km (±8.57 NM), while the
allowable longitude spacing can be greater.
6.2 Using the scenario represented in Figure I-2C-4, we consider that the aircraft is travelling East at 625 knots.
The even-format latitude-longitude position report described in Section 4 (now referred to as point (a)) was the
aircraft’s first position report, and after 9.8 seconds it transmits a second odd-format position report corresponding to
the latitude-longitude position point (b). This gives a longitude separation of 3.2 km (1.73 NM) between points. The
parameters to be included in the synchronization burst for point (b) are given in Table I-2C-12. The global decoding
equations for obtaining a globally unambiguous position from combining points (a) and (b) are given in Table I-2C-13.
6.3 The starting point for the global decoding process is to obtain two position reports (both must be either
surface or airborne reports) of different CPR formats (one even and one odd in either order). Thus, we have the
received reports for points (a) and (b) as shown in lines 1 to 6 in Table I-2C-13.
6.4 The number of latitude segments (nz) is computed in lines 8 to 9 for points (a) and (b) (always 36 and 35 or
vice versa). The number of longitude segments (nl) is computed in lines 21 to 22 for points (a) and (b) following a table
lookup in line 20.
6.5 The decoding of the latitude (lines 10 to 19) and longitude (lines 23 to 32) is illustrated with Figure I-2C-4
and with reference to the example in the right column of Table I-2C-13. The difference between segment length in the
even and odd cases is called delta, denoted as ∆.
Table I-2C-12. Parameters sent in the synchronization burst for point (b)
Synchronization burst
Fixed part Variable part
CPR- 12/14-bit Patch ID One of the following offset outputs

format output (pid) 3-bit 5-bit 7-bit
Latitude type = 1 lat = 732 pid = 288 lat4(bits 1 to 3) = 5 lat6(bits 1 to 5) = 22 lat8(bits 1 to 7) = 89
lat4(bit 4) = 0 lat6(bit 6) = 0 lat8(bit 8) = 0
Longitude lon = 11 419 lon4(bits 1 to 3) = 6 lon6(bits 1 to 5) = 26 lon8(bits 1 to 7) = 106
lon4(bit 4) = 1 lon6(bit 6) = 1 lon8(bit 8) = 1
Table I-2C-13. Compact Position Reporting (CPR) global decoding equations

Received parameters
1 type0 = 0
2 lat0 = 1 689
3 lon0 = 746
4 type1 = 1
5 lat1 = 732
6 lon1 = 11 419
7 typelast = type1 1
Global latitude decoding
8 nz(0) = 4 • LATZ type0 36
9 nz(1) = 4 • LATZ type1 35
10 nz(typelast) = 4 • LATZ typelast 35
11 lattypelast = lat1 732
lat lat
lat0 • nz(1) + 2 • nz(typelast) • MAXT + INT(MAXT
12 tmp1 = / 2) lat1 • nz(0) 321 460
lat
13 tmp2 = INT(tmp1 / MAXT ) 78
14 latseg(lat0,lat1,typelast) = MOD[tmp2, nz(typelast)] 8
15 dlat(typelast) = INT[MAXC / nz(typelast)] 64 337 137 533 864
16 tmp3 = dlat(typelast) • latseg 514 697 100 270 912
lat
17 tmp4 = INT(MAXC / MAXT ) 549 890 064 392
18 tmp5 = tmp4 • lattypelast 402 519 527 134 944
19 clatdec = globalDeclat(lat0,lat1,typelast) = INT[tmp5 / nz(typelast)] + tmp3 526 197 658 189 053
Global longitude decoding
20 tmp6 = lookup(clatdec,typelast) 3
21 nl(clatdec,0) = tmp6 3

IF (tmp6 > 1) nl(clatdec,1) = tmp6 1, ELSE
22 nl(clatdec,1) = nl(clatdec,1) = tmp6 2
IF (tmp6 > 1) nl(clatdec,typelast) = tmp6 typelast,
23 nl(clatdec,typelast) = ELSE nl(clatdec,typelast) = tmp6 2
24 lontypelast = lon1 11 419
lon
lon0 • nl(clatdec,1) + 2 • nl(clatdec,typelast) • MAXT +
25 tmp7 = INT(MAXTlon / 2) lon1 • nl(clatdec,0) 40 958
lon
26 tmp8 = INT(tmp7 / MAXT ) 2
27 lonseg = MOD[tmp8, nl(clatdec,typelast)] 0
28 dlon(clatdec,typelast) = INT[MAXC / nl(clatdec,typelast)] 1 125 899 906 842 620
29 tmp9 = dlon(clatdec,typelast) • lonseg 0
lon
30 tmp10 = INT(MAXC / MAXT ) 13 744 7342 592
31 tmp11 = tmp10 • lontypelast 1 569 511 205 058 050
clondec =
32 globalDeclon(lon0,lon1,clatdec,typelast) = INT[tmp11 / nl(clatdec,typelast)] + tmp9 784 755 602 529 024
6.6 Figure I-2C-4 shows lon encoded in the odd format (type = 1) on the top part of the figure, and the even
format on the bottom part of the figure. Observations based on this figure are presented in Table I-2C-14.
Table I-2C-14. Observations on differences in segment length
Odd format (type = 1) Even format (type = 0)

a) One less segment nl = 2 One more segment nl = 3
b) Segment larger by Segment smaller by ∆
c) A segment contains 3 A segment contains 2∆
Sl = 0 SF = 0.69...
1 nl - 1 = 2
type = 1
0 MAXc
2
Sl = 0 1 SF = 0.045... nl = 3
type = 0 2
0 MAX c
lon
Figure 1-2C-4. Illustration of longitude global decoding

6.7 For a given encoded angle, lon, the segment fractions (SF) differ by an integral multiple of ∆. If we call this
integer m, the difference is m∆. It can be seen from Figure I-2C-4 that ∆ = MAXC/nl(nl 1). In this case with nl = 3,
∆ = MAXC/6. The key observation is that if we have received both an even and odd segment fraction (SF), we can solve
for the segment index (SI) by expressing their difference in terms of ∆. From Figure I-2C-4, we see that
MAX C MAX C m ⋅ MAX C

SFeven − SFodd = m∆ =
nl nl − 1 nl ( nl − 1)
or
m = ( nl − 1) ⋅ SFeven − nl ⋅ SFodd
6.8 From Figure I-2C-4, it can also be seen that m is actually the segment index (SI). Although m can be negative,
it will still be correct as negative indices are to be interpreted as wrapping cylindrically. If m is negative, add nl - 1 to
get its positive equivalent.
6.9 Now because the even and odd reports may not exactly represent the same position, m will not at first be
exactly an integer when derived according to the equations in 6.7. When m is rounded to the nearest integer, it must be
within ± 0.5 of the “correct” integer in order to derive the correct segment number for the decoding. It is then clear that
MAX C MAX C
SFeven − SFodd
nl nl − 1
must be within 0.5∆ = MAXC/2nl(nl - 1) in order to obtain the correct segment index (SI).
6.10 As the even and odd segment fractions (SF) are given by lon0/MAXTlon and lon1/MAXTlon respectively, the
segment index (SI) can be written as:
lon0 ⋅ nl ( clatdec ,1) − lon1 ⋅ nl ( clatdec ,0 )

m=
MAX Tlon
To round this quantity to the nearest integer, it is necessary to add 0.5. In order to keep this quantity positive, twice the
number of segments of the most recent position report 2nl(clatdec,typelast) is added, as shown in line 25 of Table I-2C-13.
The modulus of this quantity with nl(clatdec,typelast) in line 27 ensures that the final value obtained for the number of
whole segments is within the range 0 nl(clatdec,typelast).
6.11 The number of whole segments is multiplied by the width of a segment (corresponding to the last position
report) in line 29. Finally, the global longitude position is obtained by adding the segment fraction (SF) (found from
lontypelast/MAXTlon) to the contribution from whole segments, in line 32.
6.12 The computation for the global latitude position (lines 10 to 19) follows the same steps as just discussed for
the longitude example. If a transition latitude (see Table I-2C-4) lies between the points, then the solution is not valid.
If
nl [globalDec lat ( lat 0 , lat 1 , type 0 ), 0 ] ≠ nl [ globalDec lat ( lat 0 , lat 1 , type 1 ), 0 ] ,
then the global decode must be discarded, and a local decode performed.

POSITION REPORT PROCESSING
7.1 Whenever a position report is received by a station A from a station B, a state machine is used to determine
how Station A should process the report. The receiving station has four processing options upon receipt of a new report
from Station B:
1) GL — perform a global decode using the current and previously received position report as an odd-even pair,
or;
2) L1 — perform a local decode on the report just received, using the position of the receiving station as a
reference position, or;
3) L2 — perform a local decode on the report just received, using the last known global position of the
transmitting station as a reference, or;
4) NO — do not do any calculation.
7.2 Decode GL cannot be performed if the transmitting aircraft has travelled more than about 8.5 NM (15.75 km)
since the last report (of opposite format) was received. Decode L2 cannot be performed if the transmitting aircraft has
travelled more than 300 NM (556 km) since the last global position was obtained. Two timers, TR1 and TR2, therefore
record the time since the last local or global decodes were performed respectively, and are used within the state
machine to decide whether the GL and L2 decodes may be used.
7.3 The position report status of Station B can be assigned to one of the following four states (see also Part II of
this document — Detailed Technical Specifications of the Manual on VHF Digital Link (VDL) Mode 4, 4.10.3.1) after
each new position report is received:
1) State 1 — no position report has been received (initial state);
2) State 2 — a position report has been received but no position has been decoded;
3) State 3 — a position report has been received and a local position has been decoded;
4) State 4 — a position report has been received and a global position has been decoded.
7.4 When a position report is received from Station B, the state machine is used to determine:
• the calculation to be performed on the data;
• the new position report status of Station B; and
• whether either or both of the timers should be restarted.
7.5 Transitions from one state to another upon receipt of a new position report from a station B depend on a
number of factors. In all cases, transitions depend on:
• the type of the position report just received from Station B (whether even or odd, and with or without an
accompanying patch ID).
In most cases, transitions also depend on:

• the initial report status of Station B;
• the type of the previously received position report from Station B (whether even or odd);
• whether the receiving station has knowledge of its own position; and
• the status of the timers TR1 and TR2.
7.6 The state machine is shown in Table I-2C-15. The words “resTR1” and “resTR2” mean that the timers TR1
and TR2 are to be restarted.
Table I-2C-15. State transitions for Compact Position Reporting (CPR) processing
In State 1 2 3 4
Last report None Even Odd Even Odd Even Odd

Target position quality None None None Local Local Global Global
Received Timers (exp =
position Own expired)
report posi-
type tion TR1 TR2
N=4 N = 4, N = 4, N = 4,
Even or C = GL C = GL C = GL C = GL
odd with resTR1 resTR1, resTR1, resTR1,
patch ID n/a n/a n/a resTR2 resTR2 resTR2 resTR2
N=4
Not C = L2
exp resTR1
N=4 N=4 N=4
N=3 N=3 C = GL N=3 C = GL N=3 C = GL
Not C = L1 C = L1 resTR1 C = L1 resTR1 C = L1 resTR1
Even Yes exp Exp resTR1 resTR1 resTR2 resTR1 resTR2 resTR1 resTR2
Not
exp N = 4, C = L2, resTR1
N=3 N=3
C = L1 C = L1
Exp Exp resTR1 resTR1 N = 3, C = L1, resTR1
N=4
Not C = L2
exp N=4 N=4 resTR1 N=4
C = GL C = GL N=3 C = GL
Not N=2 N=2 resTR1 N=2 resTR1 C = L1 resTR1
No exp Exp C = NO C = NO resTR2 C = NO resTR2 resTR1 resTR2
Not
exp N = 4, C = L2, resTR1
N=2
C = L1 N=2
Exp Exp resTR1 C = NO N = 3, C = L1, resTR1
In State 1 2 3 4
N=4
Not C = L2
exp N=4 N=4 N=4 resTR1
N=3 C = GL N=3 C = GL N=3 C = GL N=3
Not C = L1 resTR1 C = L1 resTR1 C = L1 resTR1 C = L1
Odd Yes exp Exp resTR1 resTR2 resTR1 resTR2 resTR1 resTR2 resTR1
Not
exp N=3 N=3 N = 4, C = L2, resTR1
C = L1 C = L1
N=4
Not C = L2
exp N=4 N=4 N=4 resTR1
C = GL C = GL C = GL N=3
Not N=2 resTR1 N=2 resTR1 N=2 resTR1 C = L1
No exp Exp C = NO resTR2 C = NO resTR2 C = NO resTR2 resTR1
Not
exp N=2 N = 4, C = L2, resTR1
C = L1 N=2
— — — — — — — — —
Appendix D to Chapter 2
NETWORK ENTRY: THRESHOLD VALUE

FOR CG1 COUNTER
1. This appendix discusses the setting of the threshold for the CG1 (CG1 filter) counter, CG1_limit1, i.e. the
digital filter threshold which triggers network entry due to “exposure” of the station. The threshold is currently set at
2 000.
2. The evolution of the CG1 counter over time depends on the statistics of new peer station identifications, the
expected number of synchronization bursts per M1 (number of slots per superframe) slots (this affects CG1_inc2 or the
digital filter increment when a synchronization burst from a previously unknown station is detected), and the decay rate
of the filter. The nominal values for CG1_inc and CG1_decay3 (i.e. decay rate for CG1 filter) have been previously
selected to match as closely as possible a metric of “reservation uncertainty” associated with newly-detected peer
stations.
3. The CG1 filter should trigger network re-entry in dense airspace when the number of newly identified peer
stations is large, thereby “ungarbling” synchronization bursts which might accidentally remain garbled for several
minutes. Consider a scenario with 100 newly identified peer stations reporting nominally 12 times per M1 slots. These
stations generate a channel load of roughly 25 per cent so each of the “own station’s” synchronization bursts has a
25 per cent chance of being garbled by a random selection from this set of new users. While this probability of garble
might be acceptable in a planned scenario (i.e. Robin Hood), it may be unacceptable in an unplanned scenario. So
network re-entry appears desirable.
4. A station is not required to trigger network re-entry in cases where the number of newly identified peer stations
is small. The reason is that in such cases, the likelihood of unplanned garble is also small.
5. Given the overall stability of the network entry procedure and its positive contribution to system performance,
it would appear to be desirable to pick a smaller rather than a larger value for CG1_limit, so as to provide a safety
margin. This is balanced by the desire to avoid unnecessary network re-entry under steady state conditions, since a
station might not be able to reserve slots for Aeronautical Telecommunications Network (ATN) communications events
for one minute following the re-entry trigger event (on the affected channel only).
6. Simulation has shown that a CG1_limit of 2 000 is well-suited to the task. It has also shown that aircraft
detection rates need to be of the order of 75 to 100 aircraft per minute or higher, on a high report rate channel (nr = 12),
in order to trigger network re-entry. Aircraft in en route airspace are unlikely to experience such a high rate of peer
___________________
1. CG1_limit is a plea parameter that determines how many “new” detected stations (i.e. not in the PECT) before a mobile considers itself
exposed.
2. CG1_inc defines the “resolution” of the CG1 increments, i.e. whenever a new station is detected, the CG1 counter is incremented by
this amount CG1_inc.
3. CG1_decay is the decay rate of CG1 expressed on a per second basis.
I-2D-1
I-2D-2 Manual on VHF Digital Link (VDL) Mode 4
station detections under any conditions except, possibly, initial overflight of the Los Angeles Basin. On the other hand,
aircraft on take-off could easily experience these aircraft detection rates, and should trigger network re-entry in order to
avoid several minutes of unplanned sharing or garble.
7. On a channel with a low nominal reporting rate (nr = 3), a station would have to experience a aircraft detection
rate far in excess of 200 aircraft per minute to trigger network re-entry. This does not seem likely even on take-off.
___________________
Chapter 3
ARCHITECTURES AND IMPLEMENTATIONS
3.1 INTRODUCTION
3.1.1 Users of VDL Mode 4 will include aircraft, airport surface vehicles, Air Traffic Services (ATS) and Airline
Operational Communications (AOC). This chapter addresses architectures and implementation options for airborne,
ground, airport and surface vehicle installations. Certification and approval aspects relating to these implementations
are addressed in 3.8.
3.1.2 Requirements for data link communications, and hence for VDL Mode 4 and ancillary equipment, will
differ significantly, not only between these categories but also between different users within a category. Whereas a
General Aviation (GA) aircraft owner might only wish to benefit from the possibility of making the aircraft’s presence
known to other equipped aircraft through Automatic Dependent Surveillance Broadcast (ADS-B) (and possibly also
to receive and display ADS-B reports), an Air Transport (AT) user would wish to benefit from multiple Airborne
Situational Awareness (AIRSAW) and Airborne Separation Assistance (ASAS) capabilities as well as additional
functions and applications such as the reception of data broadcast from the ground and end-to-end communication
options, both Aeronautical Telecommunications Network (ATN) and non-ATN. The possibilities to accommodate (and
afford) additional on-board equipment with regard to available space and power consumption vary considerably
between AT and GA users, and redundancy requirements are also very different.
3.1.3 The configuration of fixed ground stations and networks must allow different user categories to use the
fixed installations at a level compatible to the users. This in turn reflects the complexity of the airspace. An important
aspect of ground implementation is the requirement of an aircraft for one-way or two-way data exchange with its
appropriate ATS or AOC user inside and outside its own radio coverage.
3.1.4 Automatic Dependent Surveillance Broadcast (ADS-B) provides a new surveillance tool for ATS to
supplement and eventually replace present radar-based systems. Tower controllers are provided with a new and
seamless surveillance tool for monitoring and controlling traffic on the airport surface and in the airport’s vicinity, and
additional applications can expand that capability even further. The VDL Mode 4 installation in an airport surface
vehicle may be restricted to the transmission of ADS-B reports that are needed to support presentation of the vehicle s
position to the control tower and to taxiing aircraft and for input to a runway incursion monitoring system. The ADS-B
reports received from other users in this case only serve as a basis for controlling slot access. Other airport vehicles will
benefit greatly from a situational display presenting the positions of aircraft and other vehicles on the airport.
3.2 REDUNDANCY CONSIDERATIONS
3.2.1 Introduction
3.2.1.1 Redundancy is an important safety aspect of VDL Mode 4 and of its ADS-B-related surveillance,
situational awareness and ASAS applications. In newer AT category aircraft, multiple sensors for navigation are used
(e.g. distance measuring equipment (DME), inertial navigation system (INS) and Global Navigation and Surveillance
System (GNSS)). The position is calculated through hybridization in the Flight Management System (FMS).
I-3-1
3.2.1.2 The Flight Management System (FMS) is a redundant system using redundant sensors powered by a
redundant electrical system. The system is also able to operate on emergency power when required. If a failure should
occur on both FMS systems, GNSS position information will be used directly. GNSS position input would also be used
in retrofit aircraft and in some lower-end GA aircraft. For aircraft operating under Visual Flight Rules (VFR),
redundancy is provided by the requirement to maintain external references for navigation and visual separation to other
aircraft. Aircraft operating under Instrument Flight Rules (IFR) are required to maintain full operational redundancy
within the aircraft.
3.2.1.3 Automatic Dependent Surveillance (ADS) provides dependent surveillance, which means that ATS
surveillance is predicated on the presence of supporting aircraft equipment. As ADS is based on navigation inputs, it is
a vital safety consideration that sufficient redundancy is provided to prevent failures that affect both the ground-based
and airborne-based surveillance systems. For VDL Mode 4, which relies on accurate time for efficient utilization of the
data link, this redundancy requirement is extended to include the time input, regardless of whether this input is from the
navigation system, FMS or a dedicated system.
3.2.1.4 It is expected that ADS-B will be used as a supplementary means of ATS surveillance during a transition
period leading to full ADS-B equipage, and subsequently as a primary means system for extended period of time.
When used as a supplementary means of surveillance system, ADS-B adds availability within a larger surveillance
system where Secondary Surveillance Radar (SSR) is likely to be the primary means system. ADS-B as a primary
means of surveillance (which would be a next step) means that ADS-B would be the preferred means of collecting
surveillance data in an environment where other means, such as SSR Mode S, are still available. ADS-B is not expected
to be used as a sole means of ATS surveillance system for several years.
3.2.1.5 For air-to-air surveillance that supports situational awareness and ASAS capabilities, ADS-B is likely to
provide the only external input. Therefore, the redundancy of the airborne system must ensure uninterrupted service in
order to meet air safety requirements.
3.2.1.6 The redundancy considerations lead to new requirements being placed on the availability, continuity and
integrity of the service for both airborne and ground systems. The problem is greater for the airborne system as the
necessary back-up systems can be implemented more easily on the ground system, with limited constraints with regard
to weight and power consumption.
3.2.1.7 The following standard aviation design rules apply to both the airborne and ground segments of an Air
Traffic Management (ATM) system:
• Technology and procedures must be consistent and compatible.
• A single fault must not increase the operator s workload.
• Loss of a function must not have an impact on the overall system performance.
• Complete or partial failures experienced by one air or ground user must have no impact on other users.
3.2.2 Availability, continuity and integrity requirements
3.2.2.1 Required Communication Performance (RCP)
3.2.2.1.1 The term Required Communication Performance (RCP) refers to a set of quantified communication
performance requirements, such as capacity, availability, error rate, transit delay, etc., in a certain airspace and
communication scenario. RCP is still under development within ICAO, and no numerical values are available at this
time.
Chapter 3. Architectures and implementations I-3-3
3.2.2.1.2 VDL Mode 4 is a generic set of communication capabilities that supports multiple applications in
seamless gate-to-gate scenarios. Service providers and airspace users must determine the best uses of this property and
ensure that the RCPs are fulfilled.
3.2.2.1.3 The efficient utilization of the VDL Mode 4 data link depends on the ability of all users to access the
link in a controlled fashion. Synchronized access to the data link depends on common availability of Universal Time
Coordinated (UTC) time. VDL Mode 4 SARPs define a set of failure modes which maintain the communication
capability if, for some reason, UTC becomes unavailable. Degraded synchronization accuracy will lead to a lower link
capacity.
3.2.2.2 Required Navigation Performance (RNP)
3.2.2.2.1 Required Navigation Performance (RNP) is a statement of navigation performance accuracy within a
defined airspace and includes approach, landing and departure operations based on the combination of the navigation
sensor error, airborne receiver error, display error and flight technical error. RNP types for en route operations are
identified by a single accuracy value defined as the minimum performance accuracy required within a specified
containment level. The RNP types for approach and landing operations are defined in terms of required accuracy,
integrity, continuity and availability of navigation.
3.2.2.2.2 For VDL Mode 4, a navigation system (or the FMS, if present) provides position and also typically,
time data. The quality of position information is essential for the ADS-B function, and accurate time is fundamental for
efficient link utilization.
3.2.2.3 Required Surveillance Performance (RSP)
3.2.2.3.1 Required Surveillance Performance (RSP) refers to a set of quantified surveillance performance
requirements, such as capacity, availability, update rate, etc., in a certain airspace and surveillance scenario. RSP is still
under development within ICAO, and no numerical values are available at this time. The RSP shall express the required
accuracy and integrity of the real time position as well as the active intent of an airspace user(s) as available to other
users. These performance numbers shall depend on the tasks to be performed.
3.2.2.3.2 The Minimum Aviation System Performance Standard (MASPS) of the Radio Technical Commission
for Aeronautics (RTCA) on ADS-B provides availability, continuity and integrity calculations for ADS-B for mobile
users. These calculations include the transmission subsystem and therefore provide useful guidance for the
implementation of VDL Mode 41. The numbers given below relate to both aircraft and ground vehicles:
• Availability: 0.9995
• Continuity of service: 2 x 10–4 per flight hour
• Integrity (probability of an undetected error in a report received by an application, given that the ADS-B
system is supplied with correct source data): 10-6.
3.2.2.3.3 When input to the navigation and surveillance functions is based on the same navigation source,
typically on GA and retrofit aircraft, there might be a need to independently verify position information in ADS-B
reports. In VDL Mode 4, this can be realized by range calculations based on at what point in a time slot the message is
received. However, this is not required in the VDL Mode 4 SARPs; still all parameters are set to make these
calculations possible.
___________________
1. Performance requirements given in the Manual of Air Traffic Services Data Link Applications (Doc 9694) should also be considered.
3.3 AIRCRAFT ARCHITECTURES AND IMPLEMENTATION ASPECTS
3.3.1 Introduction
VDL Mode 4 aircraft architectures depend on the aircraft category. The installation in a GA aircraft, illustrated in
Figure I-3-1, differs considerably from the installation in an AT category aircraft. The GA installation may include a
single integrated transponder box that includes one or more Very High Frequency (VHF) transceivers, a GNSS receiver
and a communications processor as illustrated in Figure I-3-1, whereas an AT installation may employ an external
GNSS receiver or use position and time inputs from the navigation system. The AT aircraft will use duplicated
equipment for redundancy, and multiple VHF sets and antennas to support extended communication capabilities as
described in 3.3.4 and 3.3.7. Lightweight aircraft such as gliders and ultralights can even use self-contained (battery)
power as the power consumption of VDL Mode 4 is very low.
3.3.2 Interfaces
External aircraft interfaces to the VDL Mode 4 transponder may include one or more of the following:
• cockpit display unit providing Cockpit Display of Traffic Information (CDTI) functionality;
• FMS, if available (including access to flight plan/trajectory and navigation data base), or sources of
navigation data through redundant Differential Global Navigation Satellite System (DGNSS), FMS or
INS;
• barometric pressure altitude;
• applications that process ADS-B reports from other aircraft, Traffic Information Service Broadcast
(TIS-B) reports from the ground, and point-to-point message exchange;
• ATN router; and
• Communications Management Unit (CMU).
Combined VHF/GNSS
antenna
VDL Mode 4 transponder with

VHF transceiver and GNSS receiver
Figure I-3-1. Basic VDL Mode 4 installation on GA aircraft

3.3.3 Transceiver configuration options
3.3.3.1 A VDL Mode 4 airborne installation will consist of a number of VHF transmitters and receivers. The
number of transmitters and receivers is not fixed but must be sufficient not only to meet the requirements for ADS-B
reporting and monitoring, but also to support other applications and point-to-point communications.
3.3.3.2 The transceiver must have the capability to receive data on multiple VHF channels simultaneously. The
transceiver must have the capability to receive and to transmit on any one channel in simplex mode. A single
transmitter can report on several VHF channels by changing channels between transmissions. A configuration
consisting of a single transmitter and n receivers can therefore provide full ADS-B reporting and monitoring
capability on n channels. However, the slots selected for ADS-B reports must be such that the transmitter is not
required to transmit on several channels simultaneously.
3.3.3.3 The minimum level of equipage, illustrated by the box on the left in Figure I-3-2, is one transceiver
consisting of one transmitter and two receivers. This configuration supports ADS-B as a minimum and, depending on
the traffic density, it may be sufficient to support other applications as well. Other VDL Mode 4 aircraft installations
will comprise additional receivers, and will therefore be capable of operating on more than two channels
simultaneously. Such capability could be instigated by requirements to employ Local Signalling Channels (LSC) for
use in the busy terminal areas and on busy airports in parallel with the monitoring of a Global Signalling Channels
(GSC). It will also allow ground broadcast services (such as Automatic Terminal Information Service Broadcast
(ATIS-B) and GNSS augmentation) to be received independently from other functions and applications. The outer box
in Figure I-3-2 illustrates a fully redundant installation on a commercial aircraft with extensive capabilities to receive
broadcast services on multiple channels. A single transmitter alternates between channels.
3.3.3.4 The transceiver configuration in an airport surface vehicle may be restricted to one transmitter and one
receiver. The transceiver configuration for an aircraft depends on:
• the services required, e.g. ADS-B, ATN and non-ATN point-to-point communications.
• the Quality of Service (QoS), including possible sharing of channels for different services.
Commercial aircraft. Fully redundant VDL Mode 4 avionics suite
Minimum equipment Present product specification
TX TX
RX1 RX1
TX = Transmitter
RX = Receiver
RX2 RX2
RX3 RX3
RX4 RX4
Figure I-3-2. Airborne transceiver equipment

• the number of aircraft to be supported in a given environment at a given reporting rate. Multiple channels
may be needed to accommodate a large number of aircraft. This impacts on the required transceiver
configuration.
• the redundancy and availability of services (leading to requirements for duplicated equipment, etc.).
3.3.3.5 A likely implementation will have each line replaceable unit (LRU) contain one transmitter and two or
more receivers. Putting multiple receivers in a single LRU is not expected to significantly affect the cost of the
installation.
3.3.3.6 In Chapter 4, a scenario illustrates how VDL Mode 4 receivers and transmitters may be tuned in different
phases of flight. The scenario reflects the need to adapt the number of channels (and hence the transceiver
configuration on the aircraft) to the traffic situation.
3.3.4 Antenna installation considerations
3.3.4.1 Parallel operations on the VHF band always generate interference situations referred to as co-siting
problems. The size of the aircraft fuselage constrains the possible physical separation and the maximum achievable
Radio Frequency (R/F) isolation between multiple antennas. Measurements on aircraft have shown that the typical
achievable isolation on an aircraft is 29 dB or better. Data link operations must coexist with traditional analogue voice
communications. To achieve interference-free communications when operating digital and analogue services in parallel,
a higher isolation level than 29 dB is needed. This can be achieved by separating the frequencies assigned for the
respective services.
3.3.4.2 A single VDL Mode 4 antenna for both receiving and transmitting is sufficient in the case of a basic GA
aircraft installation. Multiple antennas will however be needed for an AT aircraft to support multiple services.
3.3.4.3 Figure I-3-3 illustrates a worst case antenna installation between different VHF services on an AT
category aircraft where the coupling between VHF voice and VDL Mode 4 antennas can be as low as 35 dB. To
support parallel receive/transmit operations of VDL Mode 4, separate antennas are required. As illustrated, these
antennas could also be mounted on the top and bottom of the fuselage to achieve an isolation of 50 dB or more.
Transmission of digital VDL Mode 4

signals on frequency F2
The typical achievable

antenna isolation between
Analogue voice transmitting and receiving Reception of digital VDL Mode 4
transmit/receive on antennas on the same site of signals on frequency F2
frequency F1 the fuselage is 35 db or better.
Figure I-3-3. Antenna installation

3.3.5 Examples of equipage levels
3.3.5.1 In Tables I-3-1, I-3-2 and I-3-3, three levels of radio equipage are described. These range from the most
demanding equipage for AT category aircraft (Level ) down to low-end GA category aircraft (level ). These tables do
not address ATN and non-ATN point-to-point communications, functions which might require additional receivers.
Table I-3-1. Level equipage
Aircraft category Typical AT category aircraft

Services supported ADS-B, TIS-B, other applications.
In airspace where ADS-B is mandatory requirement and operator has low tolerance of disruption
Operation
to mission due to equipment failure.
ADS-B and TIS-B on 2 GSCs and also, at times and under direction of a ground station, on one or
Channel usage
more LSC. [See Note 1.]
VDL 4 transceiver One transmitter and four receivers.
Multiple redundant transceivers, with cross links allowing system-wide reconfiguration in the
Redundancy
event of component failure.
Note 1.— This configuration complies with the maximum configuration illustrated in Figure I-3-2.
Aircraft category Typical high-end GA category aircraft with full IFR capabilities.
Services supported ADS-B, TIS-B, other applications.
More diverse than level . Requires access to airspace where ADS-B is mandatory, but not high-
Operation density airspace and airports where simultaneous channel operation (>2) is required. Lower
equipment redundancy requirements than level .
ADS-B and TIS-B on 2 GSCs and also, at times and under direction of a ground station, on one
Channel usage
LSC. TIS-B and other applications only if services are available on GSCs. [See Note 2.]
VDL 4 transceiver One transmitter and two receivers.
Redundancy Redundant VDL Mode 4 transceiver sets.
Note 2.— This configuration complies with the one illustrated by solid lines in Figure I-3-2. Two equipment sets
operate in parallel. This aircraft will not meet channel requirements in very high-density airspace and busy airports
where multiple LSCs need to be supported.
Aircraft category Typical low-end GA category aircraft as per Figure I-3-1.

Services supported ADS-B message broadcasting.
Predominantly VFR, with possible IFR outside airspace where mandatory carriage
Operation
requirement exists.
Channel usage ADS-B reporting on 2 GSCs, or on 1 GSC and 1 LSC. [See Note 3.]
Aircraft category Typical low-end GA category aircraft as per Figure I-3-1.

VDL 4 transceiver One transmitter and two receivers.
Redundancy Single VDL 4 transceiver set.
Note 3.— This configuration complies with the basic VDL Mode 4 installation illustrated in Figure I-3-1 and the
minimum equipment in Figure I-3-2. The configuration will support ADS reporting on the two GSCs needed to support
visual acquisition by other aircraft. Unlike Levels and , this aircraft is not likely to carry display equipment to
support TIS-B and CDTI information.
3.3.6 Cockpit display
3.3.6.1 Airborne benefits from ADS-B can only be realized if a cockpit display is present to show CDTI. The
physical display unit on which this information is presented is typically the navigation display. In this document, the
term cockpit display unit (CDU) is used generically to mean any cockpit display unit on which a particular type of
information is displayed. Multiple display units may be used.
3.3.6.2 The CDTI provides the flight crew with surveillance information about other aircraft and, when on or in
the immediate vicinity of an airport, about airport surface vehicles. Traffic is typically overlaid on a moving map with
appropriate geographical and aeronautical information elements. CDTI data presented on the CDU may be based on
information from one or multiple sources, including ADS-B, TIS-B and ASAS.
3.3.6.3 The requirements for CDTI will vary depending on the intended use of the data (i.e. application). Traffic
information on the CDU might be mixed with other types of information such as clearances, current weather and
selected portions of a pre-stored aviation database of the terrain, airspace structure, obstacles and detailed airport maps.
Selectable pages might include alphanumerical and graphical data from other information elements that do not need to
be displayed on the primary page.
3.3.6.4 Figure I-3-4 shows an example of a cockpit display operating in an en route environment. The CDU
operates in a consistent manner while airborne and while on the airport surface. The cockpit display will be used in
different ways depending on the particular application. Display features include adjustment of the display range,
altitude filtering to reduce the number of displayed aircraft to those of interest for separation assistance and conflict
management, and highlighting of aircraft symbols if there is a conflict or threat. Automated support for the aircrew may
include predictive traffic position and resolution advisories. The navigation display illustrated in Figure I-3-4 provides
the primary navigation information source for the aircrew along with CDTI functionality.
3.3.7 Redundancy aspects of aircraft installation
3.3.7.1 Redundancy is a vital consideration in aircraft installations. To safeguard against data link outage, a
commercial aircraft could have two independent radio sets, each with several receive and transmit capabilities.
Figure I-3-5 shows a possible architecture.
Note. Figure I-3-5 shows a GNSS receiver internal to the VDL Mode 4 box. Alternatively, an external GNSS
could be used. The timing requirements specified in SARPs do not require one solution or the other.
3.3.7.2 In normal operations, two receivers would be dedicated to the GSCs, while the other two would be used
for receiving other applications on dedicated channels. Both sets would operate in parallel, and in the event of failure of
one set, the aircraft can still continue ADS operations with the operational set. This configuration also supports
simultaneous operations on one GSC and LSC. An additional receiver would be needed to support simultaneous
operations on one GSC and two LSCs. TIS-B is assumed to be uplinked on the GSCs.
This picture shows a navigation display
Figure I-3-4. Cockpit display operating in an en route environment
Agile transmitter Agile transmitter
Rx Rx Rx Rx Rx Rx Rx Rx
1 2 3 4 1 2 3 4
Processor Processor
GNSS GNSS
Input Input
L >FMS< R L >FMS< R
CMC CMC
L >FRO SEL< R L >FRO SEL< R
L >EIS< R L >EIS< R
Cross tie bus Cross tie bus
Output Output
Power supply Power supply
DUAL
Figure I-3-5. Possible transceiver configuration for AT and high-end GA aircraft

3.3.7.3 A high level design for an integrated VDL Mode 4 installation on an AT aircraft is outlined in the
diagrams presented in Figures I-3-6, I-3-7 and I-3-8.
3.3.7.4 Figure I-3-6 illustrates a fully integrated installation. This configuration is fully redundant through the use
of duplicated equipment, with separate bus systems and power sources. Interconnection between the two buses
provides additional protection. In the architecture illustrated in Figure I-3-6, two identical VDL Mode 4 transceivers are
installed on the aircraft and interconnected (as shown in the figure) with GNSS input to both transceivers. In principle,
the two systems are working in parallel. The equipment on the left side is supported by the emergency power system
with battery back-up. The number of receivers could be reduced by dynamically using receivers in both transceivers.
3.3.7.5 The redundancy achieved by the dynamic configuration in Figure I-3-5 could be extended to the
allocation of the radio channels by distributing the channels between the two transceivers.
3.3.7.6 The VDL Mode 4 transceiver and communication processor equipment could preferably be built into the
multi-mode receiver (MMR) when such a unit is present. The installation is simplified by the fact that all wiring, power
supply and input/output units are already in place.
3.3.7.7 An MMR-integrated VDL Mode 4 transceiver is illustrated in Figure I-3-7. It is assumed that the position
information transmitted to support ADS-B applications is the same as the position information used by the aircraft
navigation systems.
3.3.7.8 A possible MMR architecture including VDL Mode 4 is shown in Figure I-3-8.
Ess. Bus Bus No 2
GNSS GNSS
IRS IRS
CMU CMU
FMS FMS
EIS EIS
VDL VDL
Mode 4 Mode 4
Captain Co-pilot
Figure I-3-6. Example of AT category aircraft architecture

Ess. Bus Bus No 2
IRS IRS
CMU CMU
FMS FMS
GNSS GNSS
EIS EIS
VDL Mode 4 VDL Mode 4
MMR MMR
Figure I-3-7. Multi-mode receiver (MMR) integrated VDL Mode 4
Receiver Receiver Receiver Receiver

A B C D
Agile transmitter VDL Mode 4
Comm processor
UTC time base
GNSS
GLS
ILS
MLS
Input/Output
Power supply
Figure I-3-8. Possible internal MMR architecture with VDL Mode 4

3.3.8 Aircraft retrofit aspects
3.3.8.1 Retrofit of Flight Management System (FMS) on Electronic Flight Instrument System (EFIS)
3.3.8.1 equipped aircraft
Aircraft that are equipped with FMS and EFIS will need a significant software upgrade as well as minor hardware
changes to accommodate the full potential of VDL Mode 4. It is likely that there will be no space or power constraints.
The retrofit equipment may have to be physically different from that of a production installation. However, the
operations logic and functions should be essentially the same.
3.3.8.2 Retrofit of aircraft not equipped with FMS and EFIS
Retrofit of a report only function should normally be possible in the space and with the power available. Retrofit to a
higher level would require finding space for a new display surface, including dedicated functional boxes and controllers,
an electronic display surface as well as adequate power supply.
3.4 GROUND ARCHITECTURES AND IMPLEMENTATION ASPECTS
3.4.1 Introduction
3.4.1.1 The VDL Mode 4 system can operate in an environment with or without ground infrastructure. When no
ground infrastructure is present, the system operates in its basic autonomous mode with only mobile units
communicating on the two GSCs. The services supported are the ADS-B function and air-to-air communications.
Adding a ground infrastructure (such as ground stations and a ground network) provides the opportunity to create more
capacity and functionality in the system and to include ATS and other ground users and systems in a larger domain.
3.4.1.2 This section describes the ground architecture elements and the requirements that different applications
generate on the architecture. ADS-B and point-to-point communications will lay down the basis for a growing set of
ATM applications as described in previous chapters.
3.4.2 Ground architecture elements
The ground architecture used for VDL Mode 4 applications must be able to receive and distribute time-critical
information to a large number of users. The architecture must also support uplink of information, sometimes time-
critical, over large areas. The security and reliability of the ground architecture must be high, even though different
implementation levels are possible. The ground architecture consists of the basic elements shown in Figure I-3-9.
3.4.2.1 Channels
The presence of ground stations provides a possibility to add additional channels to complement the two GSCs that
operate autonomously worldwide. Supplementary channels, that is LSCs, will be needed to support ADS-B reporting in
busy terminal areas and busy airports. Additional channels may also be needed to support other applications.
3.4.2.2 Ground station
The VDL Mode 4 ground station has multi-channel capability. The level of functionality and redundancy may vary
between different implementations. A principal ground station architecture includes a VDL Mode 4 transceiver,
Channels
VDL Mode 4 VDL Mode 4

ground station ground station
ATM
Ground network systems
Figure I-3-9. Basic ground architecture elements
DGNSS reference receiver, communications processor, and VHF and GNSS/DGNSS antennas. A modem connects the
ground station to the local server which provides access to ATM, AOC and various databases through a local area
network (LAN) and wide area network (WAN). Figure I-3-10 illustrates a typical ground station set-up with external
interfaces. The GNSS reference receiver in this example is external from the VDL Mode 4 transceiver.
3.4.2.3 Ground network
3.4.2.3.1 The ground network supports secure and efficient distribution of data between the ground stations and
various users and suppliers of application data. Different types of network protocols may be used for different
applications. The Transmission Control Protocol and Internet Protocol (TCP/IP) provides a possibility to use
commercial off-the-shelf (COTS) components in any standard LAN and WAN configuration. However, it is likely that
different States will use several different physical media and data link/transport protocols. The VDL Mode 4 ground
station will have several network connections and may use different protocols for different applications.
3.4.2.3.2 The network established for the North European ADS-B Network (NEAN) project can be used to
illustrate the implementation of a wide-scale VDL Mode 4 ground network that combines national networks. The
primary focus of NEAN was to demonstrate the benefits of ADS-B, but the technology used in the project also had
point-to-point message capability.
3.4.2.3.3 Figure I-3-11 shows the physical topology of the Swedish segment of NEAN. The network makes use
of the Swedish National ATN (NATN) network.
VHF Antenna GPS Antenna
Transceiver and
Transceiver reference station
PSU
PSU
2 x baseband
modems
PSU
Display Stations
Local server
NEAN
LAN
Transceiver (AUI-BNC)
BNC T-connector +
terminator
WAN
Router
Figure I-3-10. Typical ground station set-up with external interfaces
3.4.2.3.4 Figure I-3-12 illustrates the logical interconnection between the Swedish (se), Danish (dk) and German
(de) domains in NEAN. The integrated network allowed ADS-B reports received by any ground station to be
distributed freely across the domains. The arrows indicate the flow of ADS-B data.
3.4.2.4 Interacting ground systems
A large pool of systems supports various VDL Mode 4 services. Ground-based users and providers of data that are
received and uplinked by ground stations may include controller workstations, surveillance trackers, ATIS and MET
systems and databases. For some applications, special services are required as interfaces between the user/provider
systems and the VDL Mode 4 ground stations.
DS ESSA
(Arlanda)
64 kbps leased
line to Denmark B DS
R Firewall NS
LS
ESSB
(Bromma)
LS
NATN
Swedish Backbone
ESGG Frame Relay
(Landvetter)
Network
LS ESSP
(Norrköping)
LS
B LD MS
DS DS DS
ESGJ
LS (Jönköping)
ESMS DS
(Sturup)
LS B DS DS
NS National Server LD Log Device
RS Regional Server B IP Bridge
LS Local Server R IP router (Cisco 2501)
DS Display Station Firewall Firewall

MS Management Station NATN Backbone Node
Figure I-3-11. Physical topology of the Swedish segment of the NEAN network
se NS
NS
se
de+dk
National
de dk domain
National
NS se+dk domain
de
se = Swedish domain
National dk = Danish domain
domain de = German domain
Figure I-3-12. Interconnection of national domains in NEAN
3.4.3 Implementation options
3.4.3.1 Depending on the applications supported, there will be different implementation levels for the basic
ground architecture elements. The high-end solution is a ground architecture with full redundancy. The low-end ground
architecture can be used in an operational scenario in which no safety critical applications are being supported, and in
which data link services only act as complement to other information sources.
3.4.3.2 The requirements on the ground architecture will depend on the operational use of the applications and
available back-up systems. The high-end solution will comprise ground stations with a hot standby capability, listen-
back functions and a ground network with no single point of failure.
3.4.3.3 Figure I-3-13 illustrates full redundancy connections between a ground station and an ATM-system. The
two systems (units A and B in the ground system and ATM system, respectively) work in parallel with the redundant
system that is ready to take over online operations in case of failure of the operational system. Network cross links
provide additional redundancy.
3.4.4 Data distribution in a ground network
The ground network could be viewed as a global network with connections to a large number of systems and
information sources. For distribution of ADS-B data, the multicast technique will be used. This technique can
efficiently deliver data that require one or more senders to send data to multiple receivers, and is therefore very suitable
for distribution of ADS-B data. Multicast technique also minimizes the link bandwidth consumption, sender and router
processing, and delivery delay when sending the same data to multiple receivers. The use of multicast technique will
thus enhance the capability to distribute ADS-B data to different user groups, which is essential for the full benefit of
ADS-B and for realizing the gate-to-gate concept. Figure I-3-14 illustrates the multicast technique.
Full redundancy
VDL Mode 4 ground

station
Hot
standby
Unit Unit
A B
Network Network
routing path A routing path B
Unit Unit
A B
Hot
standby
ATM system
Figure I-3-13. Connections between a ground station and

ATM-system providing full redundancy
Receivers
Sender
Conventional Multicast
distribution distribution
Figure I-3-14. Multicast distribution

3.4.4.1 Data integrity aspects
3.4.4.1.1 The integrity of data distributed in the ground network is a major issue. It relates to the authentication
(i.e. that the originator of the message is authorized to issue it), correctness and timeliness of the messages. Measures
must be implemented to ensure that corruption of messages does not occur during the distribution process.
3.4.4.1.2 Another important consideration is whether the receiver of the data is authorized to use it. Data could
have an attached commercial value, and the owner of the data might wish to protect it from unauthorized use. This
could be accomplished by means of encryption techniques.
3.4.5 System resource management
3.4.5.1 Data link management
3.4.5.1.1 VDL Mode 4 is a multi-channel system consisting of several 25 kHz channels. The basic configuration
is the two GSC channels available globally. Ground stations offer the possibility to add more radio channels in order to
support more ADS-B capacity and additional applications. Such channels are added on a regional basis and are
announced to the users in the Directory of Services (DoS) message, which is broadcast on the Virtual Link
Management Channel (VLMC) on the GSC. The VLMC was introduced to prevent mobile users from gaining access to
specified slots by reserving in advance the first slot in each second (i.e. in each successive block of 75 slots) for
management information transmitted by the ground stations.
3.4.5.1.2 In regions with a mixed radar and ADS-B surveillance environment, TIS-B provides the means to
uplink positions of non ADS-B equipped aircraft. TIS-B data is broadcast on the GSCs in a protected ( blocked ) slot
area reserved for ground station transmissions only. The location of the blocked slots is announced in blocking
messages on the VLMC. In regions where capacity on the GSCs is not a problem, it is possible for ground stations to
block areas on the GSCs for certain ground broadcast applications.
3.4.5.1.3 In an area where several ground stations operate, the transmissions from the ground stations have to be
coordinated in order to prevent unintentional interference. This coordination can be achieved by adhering to a pre-set
planning scheme or by applying an online management function, which offers a dynamic utilization of resources.
3.4.5.2 Ground network management
By connecting the ground stations to a ground network as described in 3.4.2, it is possible for the VDL Mode 4 system
to cover large areas, offering the opportunity for dynamic utilization of resources depending on actual demand in the
region. The ground network itself has to be managed in order to ensure service efficiency, availability and continuity.
Normal network management routines must be applied.
3.4.6 Directory of Services (DoS)
3.4.6.1 The DoS message sent on the GSC channels contains information on available VDL Mode 4 services.
This information must be compiled in a DoS configuration application external to the ground stations.
3.4.6.2 It should be possible to change the DoS contents dynamically in the event of disruption of a service.
When this happens, DoS must be updated immediately.
3.4.7 Implementation of Applications
3.4.7.1 Applications using ADS-B data
3.4.7.1.1 The ATM systems and applications using ADS-B data will connect to one or several ADS-B multicast
addresses in the ground network. The multicast technique will provide distribution redundancy. Several ground stations
receiving the same ADS-B messages will also give additional redundancy in most phases of flight.
3.4.7.1.2 If several ground stations receive the same ADS-B report from an aircraft and forward it to the same
multicast address, there is a risk of report duplicates on the network. Filtering must therefore take place before data are
sent to the multicast address or are in the receiving application. Filtering in the receiving application is the
recommended option. The receiving application can be a tracker or a local ADS-B distribution service.
3.4.7.1.3 The ADS-B messages on the network are typically formatted according to the Eurocontrol ASTERIX
standard prior to their distribution on the network. This interface can be used in most ATM systems.
3.4.7.1.4 The distribution of ADS-B data places specific requirements on networking, since the data is real time
data. The ground architecture must ensure that the distribution delay is minimized. The stream of ADS-B data must
normally have dedicated bandwidth in the network.
3.4.7.2 Traffic Information Service Broadcast (TIS-B)
3.4.7.2.1 The uplink of TIS-B messages takes place on the GSC channels, and slots will be reserved for TIS-B
messages on these channels. No uplink of TIS-B for ADS-B-equipped aircraft should take place, since these aircraft
will transmit and receive ADS-B messages through air-to-air reporting. However, in certain cases the ground station
might rebroadcast ADS-B reports on a channel separate from that on which the reports were received to overcome
transition problems. These transmissions will be made as TIS-B messages.
3.4.7.2.2 The uplink of TIS-B data requires that the time delay between the calculation of the TIS-B data and the
presentation on the CDTI be minimized. Synchronization of the radar tracker output and the uplink of the message by
the ground station are essential. A specific TIS-B service is required to feed the reserved VDL Mode 4 slots with TIS-B
data as illustrated in Figure I-3-15.
3.4.7.2.3 TIS-B is used to provide ADS-B- and CDTI-equipped users with position information on adjacent
aircraft not equipped with ADS-B. TIS-B is based on radar data and is uplinked from the ground. TIS-B reports are
typically restricted to position data relating to non ADS-B-equipped aircraft. Filtering of radar data is therefore required
prior to data transmission. The TIS-B service assembles the radar track data into packages adapted to the size of the
pre-reserved blocks of slots on the GSC channels.
VDL Mode 4
Radar tracker TIS-B service
ground station
Figure I-3-15. Generation and distribution of TIS-B position data

3.4.7.2.4 The TIS-B service also allocates a unique service volume and a reference point. The service volume is a
set of coordinates defining the area in which display of TIS-B tracks can be expected on the CDTI. TIS-B positions are
given relative to the reference point. The unique service volume and reference point are transmitted by each ground
station as part of the TIS-B messages. Service volumes will appear on the CDTI when the aircraft is within the
coverage of the ground stations providing the TIS-B service and disappear when the aircraft is flying away from the
coverage area of the ground stations providing the TIS-B service.
3.4.7.2.5 The TIS-B service volumes (polygons) and reference points (x) are shown in Figure I-3-16. Note that a
possible interpretation of Figure I-3-16 is for each service volume to be associated with a unique ground station. This is
one method of providing the service but may not necessarily be the most efficient. Each service volume represents a
geographical region associated with transmissions from a ground station in a particular set of slots. A single ground
station could in fact service more than one of these service volumes by using a unique set of reserved slots for each
service volume.
3.4.7.3 Advanced Surface Movement Guidance and Control System (A-SMGCS)
The core part of an A-SMGCS application is the surveillance function. Surveillance may be based on Surface
Movement Radar (SMR) data or on ADS-B. Other parts of the A-SMGCS concept require point-to-point
communications, such as taxi guidance information displayed graphically on the CDU. The VDL Mode 4 parts of
A-SMGCS will be combined with other elements in the A-SMGCS concept.
Figure I-3-16. TIS-B service volumes (polygons) and reference points (X)
3.5 AIRPORT AND VEHICLE ARCHITECTURES

AND IMPLEMENTATION ASPECTS
This section describes the architecture and implementation options and aspects of a surface surveillance system based
on ADS-B reporting and the VDL Mode 4 technical platform. Specific applications that build on ADS-B reporting are
also described.
3.5.1 Mobile stations
3.5.1.1 A typical VDL Mode 4 configuration in an airport surface vehicle consists of a VHF transceiver,
communication processor and a GNSS receiver capable of processing differential corrections from a suitable reference
station (which may be a VDL Mode 4 ground station). A typical transceiver comprises one receiver, one transmitter
and a VHF antenna. To this minimum configuration can be added computers, input/output units (including a possible
situation display) for the applications supported, and power supply. The transceiver configuration can be expanded by
multiple VHF receivers and transmitters to meet specific requirements.
3.5.1.2 If ADS-B reports from a vehicle are only intended to be used for presentation on aerodrome control tower
(TWR) and cockpit displays (CDTI), there is no need to install a situation display in the vehicles. However, a vehicle
situation display, possibly combined with a moving map feature and used to display the location of other vehicles and
aircraft on the airport surface, could substantially enhance the benefits of the system.
3.5.1.3 Since a surface surveillance system is likely to include both aircraft and airport surface vehicles operating
on the same channel(s), compatibility aspects should be considered.
3.5.2 Ground controller display
3.5.2.1 Position information derived from ADS-B reports is typically presented to the ground controller on
dedicated surface movement display to support surface surveillance and possibly specific applications as contained in
3.6. As ADS-B reporting provides seamless transition between air and ground surveillance, the display coverage could
include both the airport movement area and the critical final approach area.
3.5.2.2 If desired, analogue or digital data derived from SMR could be mixed with ADS-B-derived data on the
TWR display.
3.5.3 Ground stations
The VDL Mode 4 transceiver does not need support from a ground station to work properly. However a ground station
is needed to support operations on channels other than the GSC channels. Most applications on an airport will require
the use of GNSS differential corrections for them to be useful. In addition, if the use on a particular airport includes
many ground applications (such as surface surveillance and a runway incursion monitoring system), a ground network
enabling all users connected to the network to share the same VDL Mode 4 ground station is useful.
3.5.4 VHF channel requirements
Depending on the use of the VDL Mode 4 equipment, the airport needs to assign a single or multiple VHF channels for
VDL Mode 4 usage. This is dealt with in more detail in Chapter 4.
3.5.5 Operational aspects
3.5.5.1 ADS-B reporting
Since distances between airport surface vehicles usually are very small relative to the speed of the vehicles, the
reporting rate must be high in order to avoid long jumps between reports on situation displays2. In addition, the
contents of the ADS-B reports must be determined with respect to the information and precision required. The reports
should also be compatible with ADS-B reports from aircraft, so that all vehicles, aircraft included, can see each other.
___________________
2. An update rate requirement of one ADS-B report per second is given in the Manual of Air Traffic Services Data Link Applications
(Doc 9694).
3.5.5.2 Differential corrections
3.5.5.2.1 The update rate of the differential corrections must be determined on the basis of the alert time and
precision required in ADS-B reports3. The update rate could be as high as one or even two reports per second, when
supporting A-SMGCS and low visibility operations. At busy airports it is highly likely that, for integrity reasons,
DGNSS corrections will have to be accommodated on channel(s) different from those supporting ADS-B. If multiple
channels are used, then both of these channels could, for instance, send corrections every two seconds with a one-
second displacement, resulting in an aggregate reporting rate of one report per second achieved for a user listening to
both channels. For a lower-density airport not supporting low visibility procedures, GNSS differential corrections could
probably be sent on the same channel(s) as used for ADS-B. Requirement for update rate would be lower in this case.
3.5.5.2.2 Studies on using VDL Mode 4 as a data link providing differential corrections are underway.
3.5.5.3 VHF and GNSS coverage
3.5.5.3.1 Since there are buildings and obstacles on an airport, it is important to consider the VHF and GNSS
coverage characteristics. Coverage does not normally create a major problem. To improve coverage of the ground
system, several VDL Mode 4 ground stations could be interconnected through a network. A computer would then
merge the data received. For data transmissions, the most suitable ground station would be selected. For repetitive data
such as differential corrections, transmissions could alternate between multiple stations.
3.5.5.3.2 It is important that the drivers of a vehicle are aware of the quality of the GNSS navigation in the VDL
Mode 4 transceiver, even if they do not usually use it for their own navigation. For instance, if DGNSS navigation is
lost, this would impact on the accuracy of the vehicle s position as shown on other users situation displays and action
must then be taken accordingly.
3.5.5.4 Minimum equipment and application levels
3.5.5.4.1 The ATS and airport authorities should decide the minimum level of equipment and functionality for
different vehicle categories. Some questions to be answered include:
• What level of redundancy does a particular vehicle need? Some vehicle categories might need duplicated
VDL Mode 4 transceivers.
• What is the reporting rate for each user? For instance, slow vehicles might not need as high report rate as
fast ones. Stationary vehicles could enter a sleep mode and just maintain the communication capability
by reporting once per minute per superframe.
• What applications should each user run? For instance, each vehicle must run a status indication
application that shows the VDL Mode 4 transceiver status (e.g. GNSS navigation status, position, speed,
etc.).
3.5.5.4.2 Many aspects in the implementation and use of VDL Mode 4 equipment in surface vehicles can be
determined by the airport management and local authorities. However, applications interacting with aircraft should be
standardized in terms of message contents and procedures applied.
___________________
3. An accuracy requirement of 3 m is given in the Manual of Air Traffic Services Data Link Applications (Doc 9694). The All Weather
Operations Panel (AWOP) draft Manual of Advanced Surface Movement Guidance and Control Systems (A-SMGCS) requires lateral
accuracy down to 0.4 m for on-board guidance in low visibility conditions to ensure a safety margin between main wheels and the edge
of a taxiway.
3.6 APPLICATIONS
This section describes airport applications based on the use of VDL Mode 4.
3.6.1 Surface movement surveillance
3.6.1.1 Surface movement surveillance by Air Traffic Controller (ATC) is the primary ground application of
ADS-B. Positions derived from ADS-B are significantly more accurate than positions derived from radar systems, and
ADS-B reports include additional elements such as the identity and speed of both aircraft and airport surface vehicles.
Moreover, a surveillance system based on ADS-B provides additional and seamless coverage of the airport surface and
airborne traffic in the airport s vicinity, including the final approach areas.
3.6.1.2 ADS-B also enhances the situational awareness of vehicle drivers and pilots. With a situation display, not
only is the exact position known at all times regardless of visibility conditions, but so are the positions of all aircraft
and surface vehicles operating on the airport in its vicinity.
3.6.2 Runway incursion monitoring (RIM)
3.6.2.1 The unauthorized or unintentional entry onto runways and taxiways by aircraft and airport vehicles
constitutes a serious threat to aviation safety. For instance, hazardous conflict situations may develop between aircraft
and vehicles in snow clearing situations when several vehicles operate on or close to the active runway. The threat is
more critical when poor visibility conditions prevent the control tower (TWR) from visually monitoring ground
movements and aircraft on final approach.
3.6.2.2 Based on ADS-B surface surveillance, a RIM system can be created. A RIM system enables TWR
controllers and vehicle drivers to be alerted automatically when a hazardous situation develops. Each ADS-B-equipped
vehicle could run the RIM application based on ADS-B reports received from other vehicles and aircraft independently
of any interaction with the TWR. This would introduce redundancy into the system as well as reduce reaction time as
the driver now becomes aware of the threat at the same time as the TWR controller. The RIM application does not
require a situation display in the vehicle, as alerts can be provided by appropriate visual and audible signals; however
the overall usefulness of the system is enhanced if a display is present.
3.6.2.3 The TWR would always use a situation display to support surface surveillance, while appropriate
functionality in support of RIM will be available, such as flashing symbols of conflicting targets and colour coding of a
busy active runway.
3.6.3 Snow clearing operations
3.6.3.1 There are many benefits from using ADS-B and VDL Mode 4 in snow clearing operations. As these
operations are often performed in low visibility conditions, vehicles would benefit from the navigation capabilities as
well as the improved situational awareness. This of course requires that the vehicles be equipped with a situation
display with appropriate features (such as a moving map). Equipping the workstation from which the operation is
supervised and coordinated with a situation display which presents the location of all field units will also yield
significant benefits. The VDL Mode 4 data link could also be used to send friction test data for use by the ATIS
application and for presentation on workstations in the TWR and the supervisor s operations room.
3.6.3.2 An example of an actual implementation of an ADS-B surface surveillance system supporting snow
clearing operations is shown in Figure I-3-17. This system is based on a prototype VDL Mode 4 equipment. The
system consists of several components. The vehicles are all equipped with VDL Mode 4 transponders, and some with a
situation display with a moving map. From the base station, the ADS-B reports are distributed to the application which
is used by the coordinator s workstation and the TWR display. The ADS-B reports are also recorded in a database. The
base station equipment generates GNSS differential corrections.
SNOWCATS TWR SQL
LAN
GPS
VDL mode 4
MoDS Transceiver
Base station
Figure I-3-17. ADS-B surface surveillance system supporting snow clearing operations
3.6.4 Rescue coordination
A rescue coordinator can use ADS-B reports from rescue units to coordinate the rescue operation. Even if the accident
is far away from the airport, this could be done by establishing a temporary base station or even by letting a mobile
relay the information via other communication means using the Public Switched Telecommunication Network (PSTN).
The VDL Mode 4 transceivers can also be used to send other information to reduce the risk of misunderstanding related
to voice communications.
3.7 PROCEDURES
To maximize investments benefits and to prevent accidents in new situations, the airport procedures should be carefully
reviewed to determine if adjustments are needed when a VDL Mode 4 system is implemented. For instance, the
availability of new surveillance and situational awareness capabilities by ATC, pilots and vehicle drivers will impact on
the design of low visibility procedures. The users should also know how to act in abnormal situations, such as when
navigation is lost in low visibility conditions.
3.8 CERTIFICATION AND APPROVAL ASPECTS
3.8.1 The new easy-to-read graphical displays and the accuracy of the information presented are likely to
generate a high, possibly too high, level of confidence to the airborne and ground users. This amplifies the need to
implement structured methods for verifying the reliability, integrity and functionality of not only the display systems,
but also of the underlying hardware and software components.
3.8.2 There are differences in the certification and approval requirements for aircraft and ground
implementations of VDL Mode 4. While certification is generally needed for aircraft equipment, certification of ground
equipment is only required for components that have a direct impact on flight safety, such as components interacting
directly with aircraft components. For instance, certification of the data link is required, but airport vehicle equipment
do not need certification.
3.8.3 The availability of ICAO SARPs and Procedures for Air Navigation Services (PANS) for new systems and
for their intended operational uses is a fundamental component in the certification and operational approval processes.
SARPs are not yet in place for VDL Mode 4, and many of the data link functions and applications that are to be
supported by the system are not yet fully defined.
3.8.4 The certification of the aircraft capability requires certification of the design, components, installation and
associated procedures, including:
• certification of the navigational capability of the GNSS receiver;
• certification of the data link components;
• certification of the cockpit display;
• certification of the aircraft design (e.g. redundant design);
• certification of the flight deck operational procedures; and
• crew training and experience.
3.8.5 The different elements in the ground architecture will require different levels of certification. In some cases
only an operational approval by the appropriate authority will be required. It can be foreseen that future ATM systems,
functions and procedures will be more critical since they will involve both the pilot and the controller in the decision-
making process, and this will most probably require a more standardized certification process.
3.8.6 Depending on the intended use of the VDL Mode 4 equipment, the ATM and airport authorities must verify
compliance with local, national and international regulations. If necessary, equipment and applications should be
certified.
___________________
Chapter 4
CHANNEL MANAGEMENT
4.1 INTRODUCTION
4.1.1 This chapter describes methods for channel management and channel switching in VDL Mode 4, focusing
on Automatic Dependent Surveillance — Broadcast (ADS-B) operation. The chapter discusses three sample scenarios
for channel management in high density terminal area airspace and at busy airports. Channel management in less
demanding environments, as well as in possible future environments with extreme traffic loads, might be developed on
the basis of these scenarios. However, the scenarios presented are only intended to provide guidance for actual
implementations and should not be viewed as definitive at this stage.
4.1.2 The purpose of this chapter is to describe methods by which channel management and switching might
work in practice. Simulations are ongoing to verify the requirements for Very High Frequency (VHF) channels needed
to support VDL Mode 4 services, channel management and channel switching procedures described in this chapter.
4.1.3 As noted in Chapter 3, the channels normally used for ADS-B operation in en route and uncontrolled
airspace (the Global Signalling Channels (GSC)) may not provide sufficient capacity in high density terminal areas and
at busy airports. Additional channels may therefore be needed to provide that capacity. Procedures for switching
between various channels are also needed.
4.1.4 Additional channels may also be required to support ground broadcast services such as Traffic Information
Services — Broadcast (TIS-B). Communications and navigation applications and services, of which TIS-B is an
example, are not currently under consideration within the ICAO validation of VDL Mode 4. However they are included
in this chapter as examples of applications that may in the future require separate channels, in addition to the channels
required for ADS-B.
4.1.5 Paragraph 4.2 is an overview of VDL Mode 4 applications and discusses the need for and the use of
multiple channels to support the applications. Paragraph 4.3 provides a general introduction to channel management
and channel switching. The aircraft equipage necessary to support multiple channel use is discussed in 4.4.
Paragraph 4.5 is a brief discussion of the procedures to be used in the transition phase, when all airborne users are not
yet ADS-B equipped. Paragraph 4.6 discusses three scenarios for channel management in a busy environment. The
scenarios are described in detail, with a description of the channel changes necessary at various stages of flight for
inbound and outbound traffic. Various failure modes are addressed in the Appendix A to Chapter 4.
4.2 THE USE OF MULTIPLE CHANNELS
VDL Mode 4 uses multiple VHF channels in order to provide redundancy, growth potential and flexibility. The system
works without ground stations for air-to-air applications, but the presence of ground stations makes it possible to
provide additional functions and services. Ground stations also provide extra capacity to regional terminal control area
(TMA) and local (airport) channels, and they support specific ADS-B applications such as monitoring of parallel
approaches, Advanced Surface Movement Guidance and Control System (A-SMGCS), and other ground broadcast
services. It is of vital importance that the visibility of other aircraft is maintained when an aircraft switches between
channels.
I-4-1
4.2.1 Applications and channel types
4.2.1.1 As described in earlier chapters in this document, VDL Mode 4 can support a range of surveillance
functions and applications. Such examples include:
• ADS-B, consisting of position reporting by aircraft and ground vehicles, and related applications such as
Airborne Separation Assistance System (ASAS) and Air Traffic Services (ATS) surveillance;
• Aeronautical Telecommunication Network (ATN) applications, to support two-way air-to-ground and ground-
ground applications (e.g. Automatic Dependent Surveillance C Contract (ADS-C)); and
• TIS-B, a ground data broadcast application providing radar surveillance information to aircraft in a partially
equipped environment.
4.2.1.2 It is likely that TIS-B can share common channel resources with ADS-B1, but performance issues may
imply some constraints in order to avoid over-reporting. For technical reasons, only limited point-to-point
communications can take place on channels that mainly support ADS-B and other broadcast operations. Hence ATN
applications may need separate channels.
4.2.1.3 A ground station managing communications for air traffic within a certain area will have control over
which applications are available and which channels are used with each application. It will ensure that each application
meets the required Quality of Service (QoS) by matching the requirements of a particular application to the load on the
available channels. If channels become heavily loaded, then more channels need to be made available to support the
desired applications and their users. The need for such channels must be determined by capacity considerations and will
be constrained by the availability of suitable channels.
4.2.2 Global Signalling Channels (GSCs)
4.2.2.1 Two Global Signalling Channels (GSC1 and GSC2), located in the VHF band, will be provided on a
worldwide basis. These channels will be sufficient to provide air-to-air and air-to-ground ADS-B capability in most
areas and will make possible the realization of airborne applications, such as pilot situation awareness and separation
assistance as well as ATS surveillance.
4.2.2.2 Other services, such as TIS-B, might be supported on the GSCs if there is sufficient capacity. If not,
additional channels must be assigned. The availability of such services, either on the GSCs or dedicated channels, is
announced through Directory of Services (DoS) messages on the GSCs. Thus the GSCs, which are known to aircraft
and ground stations a priori, will support:
• the ADS-B application;
• possible non-ADS applications; and
• channel management messages (including channel announcements and channel switching information).
Aircraft will transmit ADS-B on both GSCs, and transmissions will alternate between the two channels in order to
provide redundancy and protection against jamming and rogue transmissions.
___________________
1. TIS-B provides radar surveillance data on non-ADS-B equipped aircraft to equipped users. In an early transition phase, the number of
TIS-B reports on the channel will be high and the number of ADS-B reports low, whereas the situation will be reversed in a later phase.
The total number of reports will either remain constant or increase as the traffic increases.
Chapter 4. Channel management I-4-3
4.2.2.3 If no ground station is present, then transmissions on the GSCs will be self-organized (autonomous mode,
see 2.4.7.2). In the directed mode (see 2.4.7.3), the ground station directs users to transmit in specified slots and at a
specified rate.
4.2.3 Additional channels
Additional VDL Mode 4 channels can be used to increase the overall ADS-B capacity in areas with very high density
of traffic, to support specific ADS-B applications and services (such as monitoring of parallel approaches and
A-SMGCS), and to support ground broadcast services, if necessary. The use of Local Signalling Channel(s) (LSC) to
complement the GSCs in high density terminal areas can potentially remove a significant load from the GSC channels,
and therefore avoid the danger of overloading these channels. LSC channel(s) are planned for use in support of ADS-B
applications both on the airport surface and in the terminal area. If needed, specific channels may also be assigned to
support point-to-point communication services.
4.2.4 Required number of channels
A maximum of four VHF frequencies/channels will be sufficient to accommodate ADS-B services in most current and
future airspace scenarios with high traffic loads:
• GSC1 and GSC2; and
• LSC1 and LSC2.
One of the LSCs could be used on the airport surface and in the air during approach and climb-out after departure. The
LSCs also support position reporting by airport surface vehicles that operate on the airport taxiways and runways.
Note.— Whereas one or both of the LSCs may not be required in environments with low or moderate traffic loads,
it may be necessary to add one or more channels (terminal channels) to support terminal area traffic in an extreme-
density future environment. Simulations will show how traffic figures and distribution (en route/TMA/airport surface,
Instrument Flight Rules (IFR)/Visual Flight Rules (VFR) and altitude) influence the requirements for channels and user
equipment.
4.2.5 Service volume
The planned service volume (range) is 200 NM air-to-air, air-to-ground and ground-to-air. (See Figure I-4-1.) When the
load on the channel exceeds 90 per cent, then the service volume (or “cell”) around a user shrinks as described in
Chapter 2 (The “Robin Hood” principle).
4.3 CHANNEL MANAGEMENT AND CHANNEL SWITCHING
4.3.1 Ground station management
4.3.1.1.1 This section describes ground station management with particular reference to ADS-B operation.
Ground station management is not required for autonomous operation of ADS-B in en route and uncontrolled airspace,
but will typically be required for aircraft in terminal area airspace and for aircraft and ground vehicles at major airports.
Air-air applications do not require the presence of ground stations.
200 NM
Figure I-4-1. Service volume
4.3.1.1.2 In a minimum configuration, the role of a ground station may be restricted to that of a passive receiver
of ADS-B reports. Such ground stations do not make their own transmissions and do not have channel management
capabilities. This could be a typical situation in low density airspace where ADS-B reports from aircraft could provide
ATS surveillance service not available earlier. Other ground stations will be able to send several types of messages to
mobiles (i.e. aircraft and ground vehicles), including the following:
4.3.1.1.2.1 Messages required to support ADS-B operations:
• Ground station position and time are used for communication management and the ADS-B service.
• DoS messages are used to give information about the VDL Mode 4 services available on different channels.
DoS is illustrated in Figure I-4-2.
• General request messages are used to instruct an aircraft to change its reporting characteristics (reporting rate,
channel, and autonomous/directed reporting) or to instruct it to transmit periodic or on-demand Downlink
Airborne Parameters (DAP) information.
4.3.1.1.2.2 Optional messages:
• Blocking messages are used to reserve a series of slots for exclusive use by a ground station in order to protect
the transmitted information from unintentional interference from other transmitters; and
• TIS-B messages are used by the ground system to broadcast radar position data and to re-broadcast aircraft
position information to other aircraft.
All of these transmissions are broadcast messages with the exception of the general request message, which is
addressed to a particular mobile station.
4.3.1.2 Directory of Services (DoS)
DoS are transmitted on both GSCs and contain information about available services as well as the channels on which
these services are available. The update rate for DoS messages may be, for example, 20 seconds on each GSC. The use
of DoS is illustrated in Figure I-4-2.
4.3.1.3 Ground station transmissions
Ground stations will generally transmit bursts containing several different types of message as shown in Figure I-4-3.
The figure illustrates a situation where TIS-B and other services are supported on the GSCs. The figure also shows:
• Directed reporting of some aircraft. These are aircraft that are reporting under direction of the ground station
and they have been directed into the slots immediately after the uplink transmission.
• Ground quarantine slots. These are the slots immediately following a ground station transmission or a
transmission from a mobile in directed reporting. They are not used for ADS-B messages by autonomous
mobiles.
• Blocked slots. These are typically reserved slots for ground station transmissions, intended to protect the
transmitted information from unintentional interference from other transmitters, but mobile stations may also
be directed into blocks. In an area with several active ground stations, their pre-planned transmissions are
coordinated and the blocked area is covering all transmissions from these ground stations.
137.0 MHz
Directory of Service GSC A

ADS-B
GSC B
MHz
Optional
LSC
Optional
ADS-C
Optional
118.0 MHz Protected band Other
Figure I-4-2. Directory of Service (DOS)

System control DoS TIS-B Other applications General

request
Blocked
area
Ground station
transmissions
Figure I-4-3. Ground station transmissions
4.3.1.4 Tuning to a non-GSC channel
4.3.1.4.1 Non-GSC channels may be used to provide additional ADS-B capacity and to accommodate other
services.
4.3.1.4.2 An aircraft transmitting on a GSC will tune to a different channel either when instructed by a ground
station or on its own initiative based on information about services provided on a non-GSC channel. Such information
could be known by the aircraft a priori (i.e. stored in the airborne database) or received in a DoS message from a
ground station. Whereas switching to a different channel for ADS-B reporting is only allowed when commanded by the
ground station, aircraft-initiated retuning is legitimate for non ADS-B applications. As the aircraft will not be allowed
to leave a GSC without a command from the ground station, this means that an aircraft tuning to additional services on
other channels will have a spare receiver to assign to the new channel2.
___________________
2. In the channel management schemes in the generic scenarios described in 4.6, some services operate on dedicated ground-to-air
channels and two VDL Mode 4 aircraft receivers are allocated exclusively for receiving these services.
4.3.1.4.3 When a mobile station changes its ADS-B reporting channels, it will stop being visible to mobile
stations that are only monitoring the old channels. Channel switching must therefore be controlled to ensure that:
• all users in an area have visibility of all other users that they need to have visibility of; and
• there is operational continuity during the transition between channels.
The procedures for switching between GSC and LSC channels as described in the generic scenarios in 4.6 of this
chapter ensure that these requirements are fulfilled.
4.3.1.5 Management of channel switching by ground stations
4.3.1.5.1 A ground station uses the general request message together with an appropriate reservation field to
direct a mobile to:
• change the channel on which it transmits ADS-B or other messages;
• transmit ADS-B reports on an additional channel;
• change the rate at which it transmits ADS-B or other messages;
• transmit a one-off ADS-B or other message;
• switch between autonomous and directed reporting modes; and
• transmit DAP information.
This mechanism is used to prevent the overload of channels, to provide suitable reporting rates for different operational
situations, and to put different services on different channels.
4.3.1.5.2 To initiate a channel change from a GSC to an LSC, the general request protocol is used with a directed
request reservation (see 2.4.8.3) and is sent to the aircraft on the appropriate GSC. The general request message
specifies the content of the requested synchronization burst and may also contain other information to control ADS-B
reporting.
4.3.1.6 Channel transition methodology
As noted in 4.3.1.4, the channel change for ADS-B reporting is initiated by a ground station. The channel transition
maintains reporting continuity, i.e. there is no interruption in the aircraft’s transmissions or reception. Two methods are
available:
a) If the ground station issues a “directed rate” autotune command, the addressed mobile will enter the specified
channel and select its own slots (it may request help from other peer stations in order to initiate transmissions
in the first few seconds or it may wait for a sufficient time to build up a reservation time);
b) If the ground station issues a “directed slot” autotune command, the addressed mobile will enter the channel
and transmit in the specified slots.
In either case, the ground station can subsequently issue additional commands to modify mobile station behaviour.
When the last command times out, the mobile reverts to the GSC(s).
4.4 AIRBORNE EQUIPMENT FOR MULTIPLE CHANNEL USE
4.4.1 The minimum level of VDL Mode 4 equipage comprises of one transmitter and two receivers. This
supports at the very least the ADS-B application and, depending on channel usage in the particular area, it may also be
sufficient to support other applications.
4.4.2 It is likely that some VDL Mode 4 installations on aircraft will have additional transmitters and/or receivers,
and thus it will be possible to operate on more than two VHF channels simultaneously. Current production VDL
Mode 4 units will have up to four receivers and up to four transmitters that operate across channels. As a commercial
aircraft will have two independent VDL Mode 4 units for redundancy, different channels could be allocated to receivers
in both sets, thereby expanding the monitoring capability. The use of additional receivers will improve redundancy and
will allow ground broadcast services to be received independently from other applications. The transmitters and
receivers will share a number of antennas on the aircraft, which may be as low as one. More antennas may be required
depending on the application requirements for multiple channel operations and availability or continuity requirements.
4.4.3 The ability of an aircraft to transmit and receive simultaneously on different channels will depend on the
frequency separation of the channels, the number and location of antennas on the aircraft, and the airborne radio
implementation. The exact requirement for simultaneous transmit/receive on different channels will also depend on the
demands of the various communications applications that are being supported.
4.5 TRANSITION ASPECTS
4.5.1 TIS-B is used primarily to uplink radar surveillance data on non ADS-B-equipped aircraft so that both
ADS-B-equipped and non-ADS-B-equipped aircraft can be visible on the cockpit displays of ADS-B-equipped aircraft.
The service will be used regularly during the transition phase before the whole fleet of aircraft have been equipped.
4.5.2 Since TIS-B reports will not be transmitted for ADS-B-equipped aircraft, this service will not place
significant load on channels. Moreover, TIS-B information does not include intent information.
4.6 CHANNEL MANAGEMENT SCENARIOS
This section describes three airspace scenarios showing how VDL Mode 4 receivers and transmitters in an aircraft may
be tuned during various phases of flight to ensure that continuous ADS-B service is provided. The scenarios have been
chosen to illustrate system design possibilities and are intended to be illustrative rather than definitive. The first
assumes that individual aircraft can be commanded to operate on three ADS-B channels simultaneously, allowing
reduced load on each channel and emphasizing autonomous operations.3 The second and third scenarios assume that
each individual aircraft will only operate on two channels at a time (except for one minute after each frequency retune
when it is cancelling reservations on the “old” channel). These two scenarios make fewer demands on aircraft equipage
but involve higher channel loading and more complex channel management.
4.6.1 Example 1: Channel management for a terminal control area (TMA) with
airspace access requirements for VDL Mode 4 limited to
users equipped with at least three receivers
The scenario requires one transmitter and three receivers in an aircraft to support ADS-B as summarized in Table I-4-1
on channel allocations and switching procedures. The table also includes the airborne receivers which may be required
to support other services. The following assumptions have been made:
___________________
3. This requires a minimum of three receivers on the part of the participating aircraft.
• The scenario assumes that GSC channels (only) are used in Free Flight airspace, the en route part of managed
airspace and unmanaged airspace.
• Two local channels (LSC) are available within the terminal area to support ADS-B for traffic in the vicinity of
a major airport and for aircraft and vehicles on the ground at this airport.
• Ground stations control the channel management and switching between (a) the terminal area and the
approach/departure environments and between (b) the approach/departure and the ground environments.
• Channel switching by the ground station in normal operation will be controlled automatically and without
manual intervention by aircrew, a process referred to as “autotuning”
Table I-4-1. Channel allocations and switching procedures
Ground Entering
Hardware En route Terminal Final After move- departure Climb- Terminal En route
allocation Free Flight area approach landing ment runway out area Free Flight
Rx1 GSC1
Rx2 GSC2 LSC2 GSC2
Rx3 Spare LSC1 Spare
Rx4 Other services
Rx5 Other services
Rx6 Other services
Tx1 (rate) GSC1 20 sec GSC1 10 sec GSC1 10 sec LSC1 3 sec LSC1 3 sec GSC1 10 sec GSC1 20 sec
GSC2 20 sec GSC2 10 sec GSC2 10 sec LSC2 3 sec GSC1 10 sec GSC2 10 sec GSC2 20 sec
LSC1 3 sec GSC2 10 sec
The scenario focuses on ADS-B reporting. The stages in the channel switching process are described in 4.6.1.1 to
4.6.1.3. All channel management and switching “instructions” are transmitted by ground stations. Airport surface
vehicles operate on the LSCs and do not use the GSCs. LSC1 is used on runways and taxiways, while LSC2 is used on
aprons and in other airport surfaces.
4.6.1.1 Inbound traffic
Figure I-4-4 illustrates channel management procedures for an aircraft inbound from en route airspace.
Free Flight, en route and unmanaged airspace. An aircraft transmits on both GSCs at a rate of once every
20 seconds, i.e. a combined, aggregate reporting rate of once every 10 seconds is achieved. The aircraft will be visible
to other aircraft transmitting on the GSCs and will receive reports from those aircraft.
Entering terminal area airspace. On entering terminal area airspace4, the local ground station instructs the aircraft
to increase reporting rate to once every 10 seconds per GSC, i.e. to achieve an aggregate update rate of 5 seconds.
___________________
4. The terminal area could be defined by vertical and lateral variables.
Free Flight/Unmanaged airspace

Transmit on GSC1, GSC2
Update rate: 10 sec
En route/managed airspace
Update rate: 10 sec
Terminal area
10 000 ft (3 048 m) Transmit on GSC1, GSC2 Additional
geometric altitude Update rate: 5 sec Rx/Tx is
deactivated
Unmanaged airspace
Active runway and climb out:
transmit on GSC1, GSC2 Transmit on
Update rate: 5 sec GSC1, GSC2, LSC1
(GA <140 KT 10 sec) Update rate: 2 sec
Major airport
Local airport Taxiways and apron: Transmit on
LSC1, LSC2, monitor GSC1
Update rate: 1.5 sec
At gate: transmit on LSC1, LSC2

monitor GSC1
Update rate: 15 sec
Figure I-4-4. Channel management procedures (inbound traffic)
Note.— Update rates shown are aggregate rates.
Final approach. At a pre-defined point during final descent5, the ground station instructs the aircraft to begin
operations on LSC1 while maintaining operations on both GSCs. This can be done by using the procedures defined in
VDL Mode 4 SARPs, assuming three receivers are available on the aircraft (and also assuming that the airborne
implementation is configured to operate in this mode)6. By listening to LSC1, the aircraft will, in addition to airborne
traffic, receive position reports from departing, landing and taxiing aircraft on the arrival airport as well as airport
vehicles operating on the manoeuvring area and runways. By transmitting on LSC1, position reports from the
approaching aircraft will be received by taxiing aircraft and ground vehicles7. The reporting rate on the GSCs is
maintained at once every 10 seconds, and the reporting rate on LSC1 is once every 3 seconds. The aggregate reporting
rate on the three channels combined will be approximately once every 2 seconds.
___________________
5. This point could be defined by vertical and/or lateral variables.
6. This requires three commands. Other alternatives have been proposed and may be adopted at a later stage after early operational
experience indicates the best approach.
7. An airport vehicle will usually receive ADS-B reports in order to self-organize its own transmissions, but certain vehicles may be
equipped with a mobile display showing aircraft and other vehicles.
Taxiing after landing. When vacating the landing runway8, the aircraft will be instructed by the ground station to
cease reporting on GSC1 and GSC2 and start reporting on LSC2. That channel is used exclusively on the airport
surface by both aircraft and ground vehicles. The aircraft will continue to monitor GSC1 in order to receive possible
additional channel management instructions and DoS information. The reporting rate on the LSC channels is once
every 3 seconds, giving a combined reporting rate of once every 1.5 seconds.
At the arrival gate. Once stopped at the gate, the ground station can command a lower reporting rate (e.g. once
every 30 seconds on each channel), resulting in an aggregate reporting rate of once every 1 second. This is known as
“sleep mode.” Command parameters associated with the sleep mode command require the aircraft to “wake up” and
start transmitting at a higher rate (if its delta position or velocity exceeds specified thresholds).
4.6.1.2 Outbound traffic
Figure I-4-5 illustrates channel management procedures for an aircraft outbound from en route airspace. The stages in
the channel switching process are described below.
Free Flight/Unmanaged airspace

Update rate: 10 sec
En route/managed airspace
Update rate: 10 sec
Terminal area
10 000 ft (3 048 m) Transmit on GSC1, GSC2 Additional
geometric altitude Update rate: 5 sec Rx/Tx is
deactivated
Unmanaged airspace
Active runway and climb out:
transmit on GSC1, GSC2 Transmit on
Update rate: 5 sec GSC1, GSC2, LSC1
(GA <140 KT 10 sec) Update rate: 2 sec
Major airport
Local airport Taxiways and apron: Transmit on
LSC1, LSC2, monitor GSC1
Update rate: 1.5 sec
At gate: transmit on LSC1, LSC2

monitor GSC1
Update rate: 15 sec
Figure I-4-5. Channel management procedures (outbound traffic)
___________________
8. The aircraft will be considered as leaving the active runway when penetrating the boundary of a buffer zone surrounding that runway.
At the departure gate. At system initialization at the departure gate, the aircraft will initially monitor GSC1 and
GSC2, on which instructions will be received to transmit ADS-B reports on LSC1 and LSC2 at a rate of one report
every 30 seconds on each channel (sleep mode). At the same time, the aircraft will continue to monitor GSC1 without
making any transmissions (directed rate command with nominal reporting rate nr = 0). Operations on GSC2 are
terminated since the related equipment is switched to LSC1, and the third receiver supports LSC2). Ground ATS and
other aircraft monitoring LSC1 and LSC2 will receive a report every 15 seconds. The aircraft will continue to monitor
GSC1 in order to receive DoS messages. The aircraft will receive reports from both aircraft on the ground (LSC1 and
LSC2) and in the air (LSC1, GSC1).
Taxiing. As the aircraft leaves the gate, it “wakes up” and the reporting rate on LSC1 and LSC2 is increased to
once every 3 seconds, resulting in an aggregate update rate of once every 1.5 seconds. The aircraft will be visible to
other aircraft on the ground as well as to airport vehicles (LSC1 and LSC2) and will receive reports from aircraft on the
ground and airport vehicles (LSC1 and LSC2) as well as aircraft in the air (LSC1 and GSC1).
Departure runway and climb-out. When entering the active runway9, the aircraft will be instructed to start
reporting on GSC1 and GSC2 and cease reporting on LSC2 (only used on the manoeuvring area). The combined
reporting rate on GSC1, GSC2 and LSC1 will be approximately once every 2 seconds. The aircraft will be visible to
other aircraft on the ground and airport vehicles (LSC1) as well as airborne aircraft (GSC1 and GSC2), and will receive
position reports on the same channels.
Terminal area. At a specified point during climb10, the aircraft will be instructed to cease reporting on LSC1 and to
deactivate the LSC1 receiver. The aircraft will remain visible to other airborne and taxiing aircraft, but will only
receive reports from airborne aircraft and aircraft on the active runway(s).
Free Flight, en route and unmanaged airspace. When leaving the terminal area, the aircraft is instructed to reduce
the reporting rate to once every 20 seconds on both GSCs, generating an aggregate reporting rate of once every
10 seconds.
4.6.1.3 Summary of channel allocations and switching procedures
4.6.1.3.1 Table I-4-1 summarizes how channel switching is managed by a ground station when an aircraft enters
a terminal area from en route airspace, lands, moves on the ground, takes off, then exits the terminal area. The sleep
mode at the gate is not addressed in the table. Airport surface vehicles operate on the LSCs only.
4.6.1.3.2 The channel configuration and switching mechanisms described in 4.6.1.3.1 provide high capacity and
meet requirements for update rates, safe transitions between channels, ATS air and ground surveillance as well as
aircraft-to-aircraft and aircraft-to-surface vehicle visibility. Radar-derived position reports for non-equipped aircraft
could be uplinked by means of TIS-B messages.
4.6.1.3.3 This scenario is modelled on an area with very high traffic loads and is likely to meet the requirements
of any current busy environment. Theoretical calculations have shown a maximum channel load of 86 per cent on the
GSCs and 40 per cent on the LSCs in these scenarios when current Los Angeles Basin traffic figures are applied.
4.6.1.3.4 To meet the requirements of less demanding environments, the number of local channels could be
reduced to one. In most areas the GSC channels will be sufficient to support ADS-B. Additional channels may be
needed in extremely demanding scenarios in the future. However, by modelling switching mechanisms in accordance
with those described in the scenario in Example 1, the number of VDL Mode 4 receivers that have to be carried by
aircraft would not necessarily increase.
___________________
9. The aircraft will be considered as entering the active runway when penetrating the boundary of a buffer zone surrounding that runway.
10. This point could be defined by vertical and/or lateral variables.

4.6.1.3.5 The number of channels required to support ground surveillance is a function of the number of airport
surface vehicles. Additional channels may be required to support a high number of vehicles if, for example, the ground
surveillance system includes aircraft operator support vehicles.
4.6.2 Example 2: Channel management for Core of Europe

assuming airspace access requirements for VDL Mode 4
are limited to two receivers and one transmitter
This example discusses a candidate VDL Mode 4 channel management scheme for the Core of Europe. The traffic
model is derived from the SF21 Link Evaluation Team report for the Core of Europe 2015 scenario and uses air-to-air
receive update rate requirements taken from the Radio Technical Commission for Aeronautics (RTCA)/DO-242
(Minimum Aviation System Performance Standard (MASPS) for ADS-B), dated 19 February 199811. The operational
constraints are:
a) having to satisfy the ADS-B MASPS update rate requirements detailed in Appendix B to Chapter 4 with no
more than two receivers and one transmitter so as to ensure that any SARPs-compliant installation can
participate in the scenario.
b) having to preserve long-range communications performance for users that require such performance for peer
negotiation, etc. (however, minimally equipped users may lose this capability in certain airspaces).
c) having to avoid hard transitions — stations on either side of a transition border should be able to detect a
sufficient number of reports to satisfy the MASPS update rate requirements detailed in Appendix B to
Chapter 4. Only one radio will be tuned on any transition to a new frequency.
d) having the ground direct aircraft by using soft criteria. There are no critical switchovers.
e) having to minimize the use of “blind” transmissions.
Aircraft with additional transmitters and receivers beyond the minimum SARPs level (e.g. transport category aircraft)
can potentially access more than two channels at a time in order to achieve additional levels of service, attain other
services, or for redundancy purposes.
4.6.2.1 Summary of traffic model and performance requirements
4.6.2.1.1 The Core of Europe 2015 scenario, specified in the SF21 Technical Link Evaluation Team’s Phase One
Link Evaluation Report, comprises 2 091 active aircraft within 300 NM of “Ground Zero”, 1 966 airborne and 125 on
the surface (surface aircraft are presumed to be distributed at five major airports, namely Brussels, Amsterdam, London,
Paris and Frankfurt). Each major TMA is presumed to support 29 aircraft at low altitude within a radius of 12 NM, and
an additional 103 aircraft at mid- to high altitude within a radius of 50 NM. An additional 25 aircraft are distributed
uniformly throughout the entire TMA. Therefore, each TMA supports 25 surface aircraft and about 160 (29 + 103 + 25)
airborne aircraft. There are five TMAs for a total of about 800 airborne and 125 surface aircraft. The scenario includes
an additional 1 200 aircraft in en route airspace. Figure I-4-6 provides an illustration of the scenario. Table I-4-2 gives
city distances from Brussels.
4.6.2.1.2 For aircraft below 10 000 ft (3 048 NM) altitude, mutual line-of-sight distance assuming 4/3 Earth
radius is no greater than 270 NM. For aircraft below 5 000 ft (1 524 NM), mutual line-of-sight distance is no greater
than 200 NM.
___________________
11. These receive update rate requirements are not agreed within ICAO, and are more stringent at close range than the ADS-B air/ground
surveillance requirements adopted by Automatic Dependent Surveillance Panel (ADSP).
The current MASPS for ADS-B specifies 99 per cent confidence update intervals (TC) of 6 seconds at 3 NM,
10 seconds at 10 NM, 14 seconds at 20 NM, and 24 seconds beyond 40 NM. Acceptable combinations of report update
period (T) and update probability (P) are given by the formula:
(1–P)TC/T 0.01
For this loading scenario, the default VDL Mode 4 update rates are assumed to be 4 reports/minute on GSC1 and
12 reports/minute on GSC2, yielding one report every 3.75 seconds12. This satisfies the ADS-B MASPS requirements
for users in line-of-sight, if users are transmitting in unused slots.
Table I-4-2. Distances to outlying cities from Brussels

(Core of Europe scenario)
Outlying city Distance (km) Distance (NM)

Amsterdam 174 94
Frankfurt 316 170
London 316 170
Paris 264 142
300 NM Each TMA contains:

• 25 surface aircraft
Amsterdam • 29 aircraft within 12 NM
• 103 aircraft within 50 NM
• additional 25 aircraft
London
Brussels Frankfurt
Additional 1 200 aircraft
(approximately) within
300 NM of Brussels,
uniformly distributed.
Paris
Figure I-4-6. Simplified graphical depiction of Core of Europe 2015 airborne traffic
___________________
12. These default update rates are higher than those required in SARPs, but could be introduced through a database, pilot intervention or
autotuning from the ground (in high-density domestic airspace where ground stations exist), if required for operational use in a region.
4.6.2.2 Basic channel plan and loading estimates
4.6.2.2.1.1 The basic channel management scheme assumes two local ADS-B channels and a surface ADS-B
channel in addition to the two GSCs. TIS-B, Flight Information Service — Broadcast (FIS-B) and two-way air/ground
communications may be provided on additional channels. This analysis will only address ADS-B.
4.6.2.2.1.2 The channels of interest are designated GSC1, GSC2, LSC1, LSC2 and ground (GND). Each provides
75 slots per second. The channel management plan described here should be viewed as a strawman subject to
modification and refinement. The actual management plan that may be obtained in the future, in the Core of Europe,
may deviate substantially from the plan described here in view of the real world scenario and engineering
developments in the next 15 years.
4.6.2.2.1.3 Slot assignment algorithms and loading calculations for the various channels are described in the
subsections here. Then transition strategies are described in 4.6.2.3 for users flying from one region to another.
4.6.2.2.2 Surface users
4.6.2.2.2.1 The 125 aircraft active on the surface are distributed equally among the five major TMAs (25 aircraft
at each airport). These aircraft operate on GND. It is assumed that each airport may be treated independently for
purposes of channel management and loading, with users sharing the same slots and transmissions from other airports
made irrelevant by distance and horizon effects. Therefore, surface users may be deterministically commanded to the
same slots and still ensure good delivery performance in each (local) surface domain.
4.6.2.2.2.2 Stationary aircraft are assumed to transmit once every minute or once every 10 seconds (sleep mode),
while moving aircraft are assumed to transmit once every second. A ground station can command any mobile into sleep
mode when it is determined that the mobile is stationary. VDL Mode 4 protocols require an aircraft to “wake up” and
start transmitting autonomously in the event of movement. This avoids any concern about unexpected aircraft
movement during a low commanded reporting rate. If a sleep command is issued to a moving aircraft, the aircraft will
attempt to enter sleep mode but will immediately “wake up” when it exceeds either or both of its position and velocity
limits, which are associated with the sleep command.
4.6.2.2.2.3 As a strawman, the GND channel may be considered logically subdivided into 1-second blocks as
illustrated in Figure I-4-7. The resource represented by the first several slots in each second is shared by stationary
users. Two slots would support either 20 users (each transmitting once every 10 seconds) or 120 users (each
transmitting once every 60 seconds). It is expected that two slots will therefore suffice for stationary users at any single
airport. These users operate in directed slot mode and impose quarantine, which guards the subsequent block of slots
used for ground station transmissions. These two sets of blocks may be protected by superframe blocking or by Virtual
Link Management Channel (VLMC), but this is not believed necessary since all users on the GND channel have
reliable connectivity to the ground station and their local peers on the airport surface. Therefore the protection afforded
by quarantine is expected to be sufficient.
4.6.2.2.2.4 Following the slots used for ground station transmission, there is a block of slots used for mobiles in
motion. No more than 25 slots are required; the size of the block is dynamically variable, depending on the number of
users in motion and the speed with which the ground station autotunes stationary users back to a sleep mode in the first
few slots of the second. Synchronization burst reports from users in motion also have the autonomous directed flag (a/d)
bit set to 1 (a/d = 1), so mobiles in directed rate mode (those awakening from sleep) cannot access the subsequent 4
slots. An awakening user will initiate directed rate operations in the second half of the second.
4.6.2.2.2.5 Once a user initiates directed rate operations in an unused slot, the ground station can autotune it back
into directed slot mode at a high rate. If there is an unused slot in the block used by moving users, the ground station
can autotune the newly awakened user into that slot. Otherwise, the ground station can autotune the newly awakened
user into the first unused slot protected by quarantine. The quarantined slots may also be used by the ground station to
issue autotuning, retuning and sleep mode commands if the pre-reserved resource at the beginning of the second is
insufficient to clear the backlog of ground station transmissions queued in the previous second.
4.6.2.2.2.6 It is expected that 2 slots will be sufficient for all stationary users, and that the protected resource for
ground station transmissions will consume no more than 2 to 4 slots (this provides a capacity for 120 to 240 commands
per minute — note that an additional 4 slots are provided every second in the quarantined block at the end of the slots
accessed by moving users). If it is assumed that half of the users are moving and half are stationary, the probability of
movement for any given user at any instant is 0.5. The probability that all are moving is 3 x 10–8. The probability that
no more than 20 are moving is 0.998 or 99.8 per cent. Therefore, with probability of 99.8 per cent, the channel loading
is
GND channel loading 2 + 4 + 20 + 4 = 30 slots per second,
which is 40 per cent of the channel resource.
4.6.2.2.3 Airborne users
4.6.2.2.3.1 Airborne users outside the TMAs are assumed to operate at the default reporting rate of
4 synchronization bursts/minute on GSC1 and 12 synchronization bursts/minute on GSC2. This is also true for aircraft
in overflight within the geographic boundary of a TMA, but flying above 18 000 ft (5 487 m). The uneven reporting
rate ensures good long-range performance on GSC1 without any need for ground management. Operations on GSC1
will be autonomous; operations on GSC2 will be autonomous or ground-directed, depending on the outcome of future
optimization studies.
4.6.2.2.3.2 Within a TMA and below an altitude of 18 000 ft (5 487 m), the user operating frequencies and
update rates are controlled by the ground and depend on altitude and range from centre. Channel assignments and
nominal update rates are illustrated in Figure I-4-8. As a user flies into the TMA, it is first commanded to a directed
1 second = 75 slots
... slots available for directed rate

mobiles waking up on the surface
quarantined slots at end of directed slot block
slots accessed by moving users (directed slot)
protected slots for ground station transmissions
slots time shared by stationary users (directed slot)
Figure I-4-7. Strawman resource allocation for LSC/GND channel

rate of 20 reports/minute on GSC1. This anticipates an upcoming frequency change from GSC2 to LSC1 or LSC2, and
ensures that all users perceive an appropriate received update rate (as a function of range) as they fly through the
transition region. As the user flies through the frequency transition boundary (the dotted line in Figure I-4-8), it is
autotuned from GSC2 to one of the LSCs with a directed rate command imposing 12 reports/minute (same rate as for
en route airspace, but on different frequency). The user relies on Rapid Net Entry (RNE) to enter the LSC channel.
Since the command is directed rate, a single command works for up to 15 minutes. The user is free to choose its own
slots and can rebalance its streams for quasi-uniform reporting intervals.
Note.— If a directed slot command had been issued, reporting intervals would be significantly non-uniform. This
could be overcome with a second ground command a minute later by converting the user to directed rate mode, but this
also doubles the management overhead.
4.6.2.2.3.3 When entering the LSC channel using RNE, the user may not be aware of superframe blocking or
VLMC blocking that may have been imposed13. However, the operational impact is effectively nil since the entering
user is likely to hear the local users directly (hence avoiding those slots due to the power measurement). It is also likely
to hear any uplink transmissions from the local ground station (after all, it is being successfully autotuned). It may not
hear uplink transmissions from other major TMAs in the scenario (e.g. depending on its altitude), but these are
comparatively distant. Local transmissions in each outlying TMA will be co-channel interference (CCI) protected. The
entering station will plea to the ground station or to an airborne user in the TMA. The plea response will contain slots
which are appropriate for autonomous use. Therefore, based on this analysis, it may be concluded that superframe
blocking and VLMC are of marginal benefit.
4.6.2.2.3.4 After transitioning the inner boundary, the user’s reporting rate on GSC1 is commanded back to
4 reports/minute. So this leads to an aggregate reporting rate inside each TMA of 16 reports/minute, taking into
consideration GSC1 and the number of available LSCs.
4.6.2.2.3.5 The transition region for a single isolated TMA comprises an annular region with inner radius of
60 NM, outer radius of 70 NM, and ceiling of 18 000 ft (5 487 m), and a circular “cap” over the TMA with radius of
60 NM, lower altitude of 12 000 ft (3 658 m) and upper altitude of 18 000 ft (5 487 m). Given the traffic loading
assumptions for the Core of Europe 2015 scenario, there are 1 200 aircraft en route and 800 aircraft in the five major
Overflight: GSC1 @ 4/minute; GSC2 @ 12/minute
18 000 feet (5 487 m)

Outer Transition: GSC1 @ 20/min and GSC2 @ 12/min
15 000 feet (4 572 m)
Inner Transition: GSC1 @ 20/min and LSCx @ 12/min
12 000 feet (12 000 m)
Terminal Area: GSC1 @ 4/minute

LSCx @ 12/minute
60 NM 10 NM
70 NM
Figure I-4-8. Channel assignments and update rates for Core of Europe
___________________
13. This can occur, for example, if random channel errors corrupt the first several copies of the message. This is a low probability event
since the ground station is only 60 to 70 NM away from the airborne user in the transition zone.
TMAs (roughly 160 aircraft in each TMA). There are 16 to 18 en route aircraft in the annular transition region around
each isolated TMA. Of these 16 to 18 aircraft, 10 are below 18 000 ft (5 487 m). The total transition region typically
contains 25 aircraft14 which, due to their higher reporting rate on GSC1, consume the equivalent resources of
125 aircraft in en route airspace. So the “offered load” associated with the 2 000 airborne aircraft operating on GSC1 is
Offered loadGSC1 = (2 000 – 25 + 125) (4 reports/minute/aircraft) = 8 400 reports/minute
4.6.2.2.3.6 The Core of Europe is more than twice as large as the “nominal coverage domain” of a VDL Mode 4
station. In other words, the Core of Europe is taken as a circle with a radius of 300 NM around Brussels, compared to a
nominal range of 200 NM for a VDL Mode 4 station (assuming sufficient altitude to avoid horizon cut-off effects). The
ratio of areas is (300/200)2 = 2.25. Therefore, a hypothetical resource assignment could support more than
10 000 messages per minute without any sharing among stations with separation distances of less than 200 NM, and
airborne stations should always be able to identify slots that appear to be empty. Ground uplink transmissions from
various ground stations will add approximately 10 per cent additional load, assuming uplink transmission requirements
can be satisfied in the resource nominally associated with the default VLMC (8 slots per second). Therefore,
considering the estimated load due to mobile stations as well as ground stations, it appears that GSC1 will operate
below capacity in the Core of Europe.15, 16
4.6.2.2.3.7 GSC2 supports roughly 1 250 aircraft reporting 12 times/minute (i.e. 1 200 en route aircraft as well as
high-altitude users in the 5 TMAs). This channel is expected to overload with:
(1 250 aircraft) (12 reports/minute/aircraft) = 15 000 reports/minute.
This is an overall offered load of 3.3 times the channel capacity in an area roughly twice the coverage domain of any
single station, or an equivalent “local” load of 1.7:1. So this channel will offer primarily short-range performance.
However, if users are placed under ground control, good performance up to intermediate range can possibly be
maintained. For example, consider a resource assignment methodology for the Core of Europe domain as illustrated in
Figure I-4-9. In the outer periphery, odd-numbered patches have centres separated by 340 NM and can support sharing
in the same slots. Similarly for even-numbered patches, users in the centre patch can be assigned the same slots as
selected users in the outer edges of the outer periphery (especially those at lower altitude). These users may be
separated by 250 to 300 NM. Therefore, four times slot reuse should be achievable while preserving good short- and
intermediate-range performance (i.e. distance of roughly 100 NM).
4.6.2.2.3.8 With respect to the LSCs, there are roughly 170 airborne aircraft in the inner transition region and
terminal area for each isolated TMA. These aircraft will operate on LSCx at 12 reports/minute. These aircraft consume
(170)(12)/60 = 35 slots every second on LSCx. As a strawman, LSC1 is assigned to the Brussels-Amsterdam area and
LSC2 is assigned to the London-Paris-Frankfurt area (London and Frankfurt can implicitly or explicitly share the same
slots since they are separated by 340 NM). So each LSC supports the equivalent of two terminal areas with total load
on the order of 70 slots/minute. Channel management overhead will consume additional resources, so the LSCs will be
operating at close to full capacity — either slightly below or slightly above capacity depending on the amount of
channel management overhead involved17. Acceptable performance can be maintained on each LSC since low-altitude
users in different terminal areas can share the same slots on an autonomous basis, or be commanded to share the same
___________________
14. The aircraft count can be calculated by considering the two parts of the transition region. The annular part contains 10 en route aircraft
and the circular cap typically contains 4 en route aircraft and 11 terminal area aircraft (assuming a truncated exponential distribution for
aircraft altitude within the terminal area, with mean = 4 500 feet (1 342 m) and maximum altitude = 18 000 feet (5 487 m)).
15. Overall performance can be verified through simulation.
16. If it is desired to deterministically preserve a portion of GSC1 for long-range air-to-air communication (e.g. for waypoint or trajectory
negotiation), some or all of the users on GSC1 could be autotuned by using a methodology similar to that proposed for GSC2 in
4.6.2.2.3.7. This would potentially free up 30 to 50 per cent of the channel capacity on GSC1. However, ground control of GSC1 does
not appear to be required for ADS-B state vector reporting.
17. The default VLMC is 8 slots/second, but this can be adjusted to higher or lower values according to operational needs.
slots if it is so required (e.g. Brussels/Amsterdam). These users can be assigned slots prior to the block used by the
local ground stations, so their quarantines overlap the slots used by the ground and do not impose a loading penalty.
This allows the vast majority of users on the LSCs to operate autonomously in directed rate mode, which in turn
minimizes channel management overhead.
4.6.2.3 Timeline and operational scenarios
4.6.2.3.1 The timeline and radio usage for a user entering and leaving a terminal control area are summarized in
Table I-4-3.
Table I-4-3. Timeline and reporting rates by airspace region
Reporting rate by channel and airspace domain (reports/minute)

Transition Approach Transition
Channel En route Outer Inner Terminal land Surface Surface Take off Terminal Inner Outer En route
GSC1 4 20 20 4 4 — — 4 4 20 20 4
GSC2 12 12 — — — — — — — —- 12 12
LSCx — — 12 12 12 — — 12 12 12 — —
GND 60* 60*
Total 16 32 32 16 16 60* 60* 16 16 32 32 16
* Stationary aircraft may be commanded into sleep mode and report at a lower rate.
4.6.2.3.2 Mobiles en route (high-altitude or long range) are allowed to operate autonomously at the default rates.
As a mobile flies into the terminal area, it is detected by the ground station network and autotuned in line with the
transition region operations as indicated in Figure I-4-9 and Table I-4-3. Users are shifted off from GSC2 half-way
through the transition region, but the elevated reporting rate on GSC1 ensures that the overall effective received update
rates are maintained at a rate greater and/or equal to 16 updates/minute across the boundary (i.e. by temporarily
increasing the reporting rate, aircraft in the inner transition region C which are only receiving the reports from aircraft
in the outer transition region and en route airspace on GSC1 — still receive sufficient reports to satisfy the MASPS).
4.6.2.3.3 Once inside the terminal area, the mobile is commanded to the default rate of 4 reports/minute on GSC1.
Users operate autonomously on GSC1 and LSCx until landing18. After landing, the user is autotuned from GSC1 to
GND. After departing the active runway, transmissions on LSCx are commanded off (although, the user continues to
monitor the channel).
4.6.2.3.4 When an aircraft powers up on the ground, it enters the network on GSC1 and GSC2 at default rates. It
is expected that the entering user will plea to a high-altitude aircraft in overflight or to the local ground station within a
few seconds. GSC1 will always have spare capacity on a local basis, and even GSC2 is expected to have sufficient
spare resources on a local basis to allow for big negative dither (BND) and plea. The ground station can detect the
synchronization bursts and immediately autotune the user from GSC1 to GND, from GSC2 to LSCx and then off, and
then command sleep mode on GND as appropriate (i.e. if the aircraft is parked at the gate).
4.6.2.3.5 As an aircraft enters the active runway for take-off, it is already monitoring LSCx and GND, and has
awareness of approaching traffic. It is commanded to start transmissions on LSCx in order to create visibility for
___________________
18. A few low-altitude users might operate under directed-slot mode subject to future optimization.
approaching users (i.e. to minimize the risk of a ground collision), and also to initiate transmissions to users operating
in the terminal area. After take-off, the mobile is autotuned from GND to GSC1 (it uses RNE to enter the GSC1
network in 3 to 5 seconds).
4.6.2.3.6 As an aircraft departs the terminal area, it is first commanded to a high update rate on GSC1 (if not
already so commanded) and then autotuned from LSCx to GSC2 by using a directed rate command. The user then
applies RNE to enter GSC2 in 3 to 5 seconds. A final directed rate command on GSC1 resets the nominal update rate
on GSC1 to 4 transmissions/minute.
Note.— If this command is not sent or received, the last autotune on GSC1 will time out in no more than
15 minutes and result in default operations at that time.
4.6.3 Example 3: Channel management for Los Angeles (LA) Basin,

assuming airspace access requirements for VDL Mode 4
are limited to two receivers and one transmitter
This example discusses a candidate VDL Mode 4 channel management scheme for the LA Basin in California. The
traffic model is derived from the SF21 Link Evaluation Team report for the LA Basin 2020 scenario. The operational
constraints are:
6 2
5 3
Core Europe region (radius ~ 300 NM)
Figure I-4-9. Strawman resource assignment methodology for GSC2

a) having to satisfy the ADS-B MASPS update rate requirements detailed in Appendix B to Chapter 4 with no
more than two receivers and one transmitter so as to ensure any SARPs-compliant installation can participate
in the scenario.
b) having to preserve long-range communications performance for users that require such performance for peer
negotiation, etc. (however, minimally equipped users may lose this capability when deep in the terminal area).
c) having to use only one local channel and one ground channel in addition to the two GSCs.
d) having to avoid hard transitions C stations on either side of a transition border should be able to detect
sufficient reports to satisfy the MASPS update rate requirements detailed in Appendix B to Chapter 4. Only
one radio will be tuned on any transition.
e) having the ground station direct the aircraft by using soft criteria. There are no critical switchovers.
f) having to minimize the use of “blind” transmissions.
Aircraft with additional transmitters and receivers beyond the minimum SARPs level (e.g. transport category aircraft)
can potentially access more than two channels at a time in order to achieve additional levels of service, attain other
services, or for redundancy purposes.
4.6.3.1 Summary of traffic model and performance requirements
4.6.3.1.1 The LA Basin 2020 scenario, specified in the SF21 Technical Link Evaluation Team’s Phase One Link
Evaluation Report, comprises 2 694 active aircraft within 400 NM of “Ground Zero” 2 469 airborne and 225 on the
surface (surface aircraft are presumed to be at multiple airports). The scenario is non-symmetrical to account for lower
aircraft densities over the ocean (i.e. to the southwest of ground zero). Figure I-4-10 provides an illustration of the
airborne traffic model with rounding of aircraft counts in the various sub-regions. The total number of airborne aircraft
in this simplified scenario is 2 480. The altitude distribution is assumed to be exponential with a mean of 4 500 ft
(1 372 m). An additional 225 aircraft are assumed to be distributed on the ground and at multiple airports, yielding a
total aircraft count of 2 705.
4.6.3.1.2 For aircraft below 10 000 ft (3 048 m) altitude, mutual line-of-sight distance assuming 4/3 Earth radius
is no greater than 270 NM. For the large proportion of (mostly GA) aircraft below 5 000 ft (1 524 m), mutual line-of-
sight distance is no greater than 200 NM. In the particular case of the LA Basin, mountainous terrain surrounding the
basin may provide Radio Frequency (R/F) isolation at shorter ranges. However, this factor is not considered in the
candidate channel management schemes described in 4.6.3.2.
4.6.3.1.3 The current MASPS for ADS-B specifies 99 per cent confidence update intervals (TC) of 6 seconds at
3 NM, 10 seconds at 10 NM, 14 seconds at 20 NM, and 24 seconds beyond 40 NM. Acceptable combinations of report
update period (T) and update probability (P) are given by the formula:
(1–P)TC/T 0.01
The default VDL Mode 4 update rates (i.e. in remote areas and on start up) are assumed to be 4 reports/minute on
GSC1 and 12 reports/minute on GSC2, yielding 1 report every 3.75 seconds. This satisfies the ADS-B MASPS
requirements for users in line-of-sight, if users are transmitting in unused slots.
4.6.3.2 Basic channel plan and loading estimates
4.6.3.2.1.1 The basic channel management scheme for the LA Basin assumes a local ADS-B channel and a
surface ADS-B channel in addition to the two GSCs. TIS-B, FIS-B and two-way air/ground communications may be
provided on additional channels. This analysis will only address ADS-B. The four channels of interest are designated
GSC1, GSC2, LSC and GND. Each provides 75 slots/second. Draft SARPs for VDL Mode 4 indicate a VLMC with
default allocation of 8 slots/second. This is assumed to be “turned off” in the LA Basin scenario where required uplink
communications are protected by quarantine and superframe blocking as indicated in 4.6.3.2.2.5.
4.6.3.2.1.2 It is expected that each high density airspace under ground control will be managed in accordance
with a strategy tailored to the needs of that specific airspace (i.e. considering the approach/departure corridors, airports
active in the region, terrain, etc.). For this analysis, which contains a demonstration that the LA Basin 2020 loading
scenario can be accommodated with VDL Mode 4 SARPs-compliant equipage, the aircraft distribution is taken directly
from the bulk geographic distribution of users described in the SF21 Link Evaluation Team report. This may differ
from current and future operations in the LA Basin in significant respects. In particular, it does not take into account the
detailed structure in airspace traffic patterns (e.g. approach and departure corridors, etc.) which could be used to further
subdivide the user population across separate local channels. Therefore, the channel management plan described here
should be viewed as a first strawman subject to modification and refinement. The actual management plan that may be
obtained in the future, in the LA Basin, may deviate substantially from the plan described here, in view of the details of
the real world scenario and engineering developments in the next 20 years.
400
300
400 a/c 400 a/c

200
Distance from centre (NM)
260 a/c 260 a/c

100
0 320 a/c
-100 100 a/c 260 a/c
-200 80 a/c 400 a/c
-300
-400
-400 -300 -200 -100 0 100 200 300 400
Figure I-4-10. Simplified graphical depictions of LA Basin 2020 airborne traffic

4.6.3.2.1.3 Slot assignment algorithms and loading calculations for the various channels are described in the
4.6.3.2.2 and 4.6.3.2.3. Transition strategies are described for users flying from one region to another.
4.6.3.2.2 Surface users
4.6.3.2.2.1 The 225 aircraft active on the surface are assumed to be distributed among the Los Angeles
International Airport, San Diego, Long Beach and five other small airports. These aircraft operate on GND except
when they are on an active runway, in which case they operate on GND and LSC.
4.6.3.2.2.2 It is assumed that each airport may be treated independently for purposes of channel management and
loading, with transmissions from other airports made irrelevant by distance and horizon effects.
4.6.3.2.2.3 Stationary aircraft are assumed to transmit once every minute or once every 10 seconds (sleep mode),
while moving aircraft are assumed to transmit once every second. A ground station can command any mobile into sleep
mode when it is determined that the mobile is stationary. VDL Mode 4 protocols require an aircraft to “wake up” and
start transmitting autonomously in the event of movement. This avoids any concern about unexpected aircraft
movement during a low commanded reporting rate. If a sleep command is issued to a moving aircraft, it will attempt to
enter into sleep mode but will immediately “wake up” when it exceeds the position and velocity change limits which
are associated with the sleep command.
4.6.3.2.2.4 Given the total aircraft count (surface) of 225 distributed across three major and five minor airports,
one may expect less than 75 active aircraft per airport, with roughly half moving.
4.6.3.2.2.5 As a strawman, the GND channel may be considered to be logically subdivided into 1-second blocks
as illustrated in Figure I-4-11. The resource represented by the first two slots in each second may be assigned by the
ground station to stationary mobiles, allowing up to 20 aircraft to report once every 10 seconds or 120 aircraft to report
once every minute in ground-controlled mode. These synchronization burst reports have the autonomous directed flag
(a/d) bit set to 1 (a/d = 1), so autonomous mobiles cannot access the subsequent 4 slots. These quarantined slots may
be used by the ground station to issue autotuning, retuning and sleep mode commands (up to 240 separate individually
addressed commands/minute). A DoS might also be provided at a low rate (e.g. once every minute), duplicating some
or all of the information provided on the GSCs.
1 second = 75 slots
69 slots for autonomous mobiles
4 quarantined slots for ground station transmissions
2 slots time shared for stationary users
Figure I-4-11. Strawman resource allocation for GND channel

4.6.3.2.2.6 If there are only a few stationary aircraft, this scheme might leave some seconds without a
quarantined resource for protected ground station transmission and growth. However, in this case the ground station
could command certain mobiles to transmit at a higher rate while stationary, or the ground station can transmit its own
synchronization bursts as fill (these also support quarantine). The remaining resource of 69 slots/second provides
capacity for more than 65 aircraft in motion at any one time without any need for slot sharing. Mobile aircraft would
operate in “directed rate” mode where they select their own slots consistent with the rate command of the ground
station. When waking up from sleep mode, mobiles also operate in directed rate mode and intermingle their
transmissions with the other aircraft reporting once every second.
4.6.3.2.2.7 If stationary aircraft in the movement area are required to report more frequently than once every
minute, this scheme can be modified for multiple sleep reporting rates. For example, 1 slot per second could be shared
by up to 60 stationary users who are not in the movement area (these would report once every 60 seconds); 5 slots per
second could be shared by up to 50 stationary users on the movement area (these might be commanded to report once
every 10 seconds); 4 slots could be reserved for ground station transmission as before; and 65 slots per second would
still be available for moving aircraft reporting once every second. The capacity of this resource assignment scheme
should be on the order of 170 aircraft at any single airport. Other resource assignment schemes are clearly feasible, and
there is significant flexibility with regard to reporting rates on and off the movement area.
4.6.3.2.2.8 Since the scenario assumptions are consistent with (typically) 75 active aircraft/airport, of which only
35 to 40 might be in motion at any one time, a single GND channel seems to provide adequate capacity for the
LA Basin 2020 scenario, with room for statistical variation and growth.
4.6.3.2.2.9 In the event that planning criteria indicate that in the long term, that traffic loading at a single airport
could dramatically exceed the assumptions contained in the LA Basin 2020 scenario, a second GND channel could be
added. However, this is not considered likely for many years.
4.6.3.2.3 Airborne users
4.6.3.2.3.1 Airborne users outside the extended LA Basin Terminal Area (taken as the 225 NM radius in
Figure I-4-10) are assumed to operate autonomously in default mode with 4 synchronization bursts/minute on GSC1
and 12 synchronization bursts/minute on GSC2. This is also true for aircraft in overflight above 18 000 ft (587 m).
Within a radius of 225 NM and below an altitude of 18 000 ft (587 m), the user operating frequencies and update rates
are controlled by the ground and depend on altitude and range from centre. Channel assignments and nominal update
rates are illustrated in Figure I-4-12. Given the traffic loading assumptions for the LA Basin 2020 scenario, there are
roughly 110 aircraft in the transition region19 and 25 aircraft in overflight. Outside the terminal area and in the
transition region, update rates are as specified in the figure. Inside the terminal area, update rates average
8 transmissions/minute on each channel but individual users may be commanded to unbalanced rates as described in
the following sections (although the total update rate for every user will remain at 16 transmissions/minute considering
the two channels).
4.6.3.2.3.2 Peak loading on GSC1 occurs outside the extended terminal area, and is expected to be on the order
of 40 per cent for synchronization bursts (including ADS-B position, velocity and time (PVT) messages), given the
potential for roughly 450 aircraft operating on GSC1 within line-of-sight. This preserves the majority of GSC1 capacity
for other applications including the transmission of waypoints by Flight Management System (FMS)-equipped aircraft,
long-range air-to-air negotiations between aircraft in overflight, etc. It should be noted that transport category aircraft
(and others with equipage beyond the minimum SARPs requirement) can access GSC1 for non-ADS-B functions even
if autotuned to a local channel for the purpose of ADS-B. Such users would transmit 1 synchronization burst per minute
on GSC1 (for the purpose of declaring their participation on the channel), and would make other application
transmissions as required.
___________________
19. There are 53 aircraft in the annular airspace with inner radius = 215 NM and outer radius = 225 NM, and 56 aircraft in the circular cap
with radius = 215 NM, lower altitude = 12 000 ft (3 658 m) and upper altitude = 18 000 ft (5 486 m).
Overflight: GSC1 @ 4/minute; GSC2 @ 12/minute
18 000 feet (5 487 m)

Outer Transition: GSC1 @ 4/min and GSC2 @ 20/min
15 000 feet (4 572 m)
Inner Transition: LSC @ 8/min and GSC2 @ 20/min
12 000 feet (3 658 m)
Terminal Area: LSC @ 8/minute (average)
GSC2 @ 8/minute (average)
215 NM 10 NM
225 NM
Figure I-4-12. Channel assignments and update rates for LA Basin
4.6.3.2.3.3 Peak loading on LSC and GSC2 occurs in the centre of the region. For the LSC, considering all users
inside the inner transition region and terminal area, the total number of synchronization bursts slightly exceeds
9 000 synchronization bursts/minute. Apparent loading is less due to horizon cut-off effects. Loading on GSC2 is
slightly higher than on LSC due to the increased reporting rate in the transition region. The total offered load within
200 NM of “Ground Zero” is on the order of 9 600 messages/minute. Again, the apparent loading is less due to horizon
cut-off effects. In order to satisfy operational requirements with only 4 500 slots per minute (offered load is more than
twice capacity), the ground implements a slot reuse scheme with several widely-separated aircraft commanded to share
a given set of slot assignments. Many slot reuse schemes can be devised; for simplicity, however, the reuse scheme
illustrated in Figure I-4-13 will be used for purposes of illustration.
4.6.3.2.3.4 In Figure I-4-13, each hexagonal patch is roughly 50 NM in diameter and the LA Basin terminal area
(extending to a range of 225 NM from centre) comprises roughly 61 patches20. The inner terminal area (in lighter
shade), with radius = 60 NM, comprises roughly 7 patches and supports 320 users squawking an average of 8 times per
minute on each channel. The “average patch” contains roughly 320/7 = 46 users.
4.6.3.2.3.5 In order to reassign resources in an efficient way, it is necessary to subdivide the channel resource in
a logical fashion. Again many schemes are possible; however, as a strawman for discussion, let the VDL Mode 4 frame
be subdivided into 9 unequal sets of slots as shown in Figure I-4-14. Thus, in each 15-second epoch there are 4 repeats
of a subframe containing 2 resource groupings for ground station uplink (primarily) and 7 resource groupings for
mobile station assignment. Assign the 7 resource groupings for mobile station use to the various numbered patches in
Figure I-4-13, tessellating the plane as indicated in Figure I-4-13, and reserve the remaining 2 sets of resource
groupings for ground uplink messages (i.e. for DoS, autotuning commands, etc.), growth and statistical fluctuations.
Each patch can support 128 users transmitting an average of 4 times/minute/channel or 64 users transmitting an average
of 8 times/minute/channel.
4.6.3.2.3.6 Let all users be assigned dedicated slots in directed slot mode at the rate of 8 reports per minute per
channel, yielding an update rate of once every 7.5 seconds on each channel and once every 3.75 seconds in aggregate.
The ground station can dynamically shift cell boundaries (e.g. shrink the innermost cell and enlarge the cells in the first
inner ring) in order to equalize loading or allow adjacent cell loading to be unequal.
___________________
20. The patches can be distorted, enlarged or shrunk to a degree (making suitable changes in neighbouring patches) in order to equalize
loading in a local area. Uniform patch sizes in the illustrations should not be construed as a formal constraint on the concept.
50 NM
2
7 3
1
1 6 4
5 2
2 7 3
7 3 1
1 6 4
1 6 4 5
5
1
1
Figure I-4-13. Possible slot reuse scheme for LA Basin
15 seconds = 1 125 slots

562 slots 563 slots
281 slots 281 slots 281 slots 281 slots
G G
N 1 2 3 N 4 5 6 7 (repeat) (repeat) (repeat)
D D
spare
4 groups at 32 slots each (mobile assignments)
1 group at 25 slots (ground uplink use and spare)
3 groups at 32 slots each (mobile assignments)
1 group at 32 slots (ground uplink use and spare)
Figure I-4-14. Strawman resource assignment scheme for LA Basin tesselation

4.6.3.2.3.7 The autotuning commands impose a periodic sequence on the mobiles. With a nominal rate (nr) of
8 transmissions per minute, the intervals between transmissions alternate between 562 slots and 563 slots. This is
accommodated in Figure I-4-14 with the spare slot at the end of the 15-second epoch. Therefore, if a pair of users are
both assigned nr = 8 starting in the same slot, all their assignments will overlap (8 slots assigned with dual-use sharing
in each). Conversely, if they are assigned nr = 8 starting nominally 7.5 seconds apart, every other slot will be shared
and the others will be dedicated (12 slots assigned with 4 shared by user A and user B, 4 dedicated to user A and
4 dedicated to user B). Since each user is assigned slots on two frequencies, slots can be assigned in such a way that
each user receives 4 dedicated assignments and 12 shared assignments in a local area. This partial sharing technique is
applied to slot assignments in the darker shaded annular region of Figure I-4-13, relative to the slot assignments in the
more lightly shaded core area.
4.6.3.2.3.8 For simplicity in constructing the load management illustration as shown in Figure I-4-14, first
assume that the average case applies (i.e. no random load variation). Consider the users in the lightly shaded core area,
patch 1 in Figure I-4-13. We will now construct the slot assignments for one of the two active frequencies (e.g. GSC2).
There are 2 • 32 = 64 starting slots for patch 1 in the first half of Figure I-4-14 (32 in each 281-slot epoch). Start by
assigning every other slot in this resource to users in the central patch 1; after the 32nd user is assigned, return to the
beginning and start filling in the gaps which were left in the first pass, until all users in patch 1 are assigned. With
46 users in the patch, there will be 28 users with adjacent slot assignments, 18 users with alternating (used/unused) slot
assignments, and 18 slots unassigned. Now consider the six patches similarly numbered 1 in the darkly shaded annular
region of Figure I-4-13. These patches contain 15 users each. Take all users in three such patches symmetrically
arranged around the centre at 120 degree intervals, and assign all users in these patches to overlapping assignments
with the users in the centre. For this assignment, deterministically select slots assigned to users in the centre with
adjacent slot assignments (e.g. 32 of the 46 users). This achieves a mix of 2-time and 3-time slot reuse, with sharing
users separated by 75 to 150 NM21. For the remaining three patches numbered 1 near the periphery of the darkly shaded
annular region in Figure I-4-13, stagger the autotuning commands by 7.5 seconds relative to those issued to users in the
centre, and assign these peripheral users to slots shared by users in the centre with alternating used/unused slots. These
users experience 4-time slot reuse for half the slots assigned (every other transmission) due to the 562/563 stagger.
Users in the centre retain 4 slots each on a dedicated basis, and users in the periphery experience 3-time slot reuse at
ranges of 200 NM.
4.6.3.2.3.9 For slot assignments on the other frequency (e.g. LSC), apply the same algorithm but switch the rules
applied in the periphery so that the “other half” of the users get slots shared only at long range.
4.6.3.2.3.10 Overall, each user receives 16 slots (one every 3.75 seconds) balanced across two frequencies.
Seventeen users in the centre receive fully dedicated slots (these could be selected based on an altitude filter,
knowledge of the user’s participation in a pairwise manoeuvre, or left to random chance). For the remainder, each user
receives 12 slots shared by up to 3 other users at ranges of roughly 112 NM, and 4 slots which are either dedicated or
shared by up to 2 other users at ranges of roughly 200 NM.
4.6.3.2.3.11 Table I-4-4 identifies the per message delivery success probability (P) required to satisfy the ADS-B
MASPS requirements, assuming this probability is independently distributed across each transmission (this is only a
first approximation). Due to the CCI characteristics of VDL Mode 4 (1 per cent message loss rate at desired/undesired
rate (D/U) = 12 dB), receive performance will start to be influenced by sharing at Range (RCCI) of
RCCI = (200 NM) • 10 -12/10 = 50 NM
Differences in power calibration and antenna gain will lead to a soft threshold with some users experiencing a start of
degradation at 25 NM and other users experiencing a start of degradation at 100 NM. Delivery performance at ranges
less than 25 NM should be very high. It therefore appears that the ADS-B MASPS air-to-air performance requirements
can be satisfied.
___________________
21. Careful assignment could potentially minimize the variation of distances around the centre of this range (112 NM), or bias the 3-time
slot reuse events so that one or two of the distances involved are closer to 150 NM.
Table I-4-4. Message delivery success probability (P) required to satisfy ADS-B MASPS
(T = 3.75 seconds)
Required per message delivery

Range (R) from transmitter TC (99 per cent update interval success probability
(NM) in seconds) P > 1 - (0.01) T/TC
3 6 0.95
10 10 0.83
20 14 0.71
40 24 0.52
4.6.3.2.3.12 The example in Table I-4-4 has been constructed with the “average values” assumed to obtain
probability (P). In reality, cell loading will vary beyond the range that this simple assignment algorithm can satisfy.
This variation can be accommodated in several ways, including the following options:
a) dynamic distortion of cell boundaries to equalize cell loading;
b) use of spare capacity reserved for uplink transmissions;
c) sacrifice of dedicated slots for long-range performance (i.e. apply sharing for all slot assignments and self-
limit on a basis of range similar to Mode S);
d) reduction in reporting rate (this may be considered more desirable than self-limiting on range, but is a decision
left to the future service provider/Civil Aviation Authority (CAA));
e) splitting of reporting rates to allow more graceful tailoring of shared versus dedicated slots (however, split
reporting rates with directed slot autotune commands will result in non-uniform reporting intervals. As with
option d), the use of this scheme will need to be evaluated by the service provider/CAA).
f) addition of local channels for use in geographically separated airspace (e.g. by approach and departure
corridors). Use of three LSCs would bring load for each local channel to less than 80 per cent at 8 reports per
minute, so no sharing would be required. Alternatively, the load on these additional local channels could be
increased in order to allow a reduction in the load on GSC2.
4.6.3.2.3.13 It is also necessary to evaluate the overhead resources needed to manage the user population. An
autotune command has a maximum time out of 15 minutes, but users are expected to fly from one patch to another
more quickly. Subject to verification, an average hold time of 5 minutes is assumed. Therefore a typical user requires
one command every 5 minutes on each frequency. With roughly 1 000 airborne users in the terminal area within a
range of 225 NM, and subject to ground command, the ground must issue roughly 200 commands per minute. This is
22 per cent of the resource reserved for ground uplink transmission, and some sharing of uplink slots may be
implemented across the terminal area to further minimize load.
4.6.3.2.3.14 Aircraft in overflight can find unused slots on GSC2 in the portions of the frame reserved for uplink
transmission, if these slots are not blocked by superframe blocking or second frame blocking. It is therefore expected
that superframe blocking will be applied to at most one of the two dark-shaded resources in each 281-slot epoch
illustrated in Figure I-4-14, and possibly only a portion of one such resource. GSC1 is lightly loaded in the terminal
area, and aircraft in overflight can use GSC1 for all standard applications, including ADS-B, long-range negotiation
and air/ground communications.
4.6.3.2.3.15 In summary, each user achieves essentially garble-free performance with all transmissions to a range
of 20 to 25 NM, and garble-free performance on 1/4 of its transmissions to a range of roughly 112 NM. This should
satisfy the MASPS update rate requirements if Additive White Gaussian Noise (AWGN) effects do not dominate (this
is a matter of receiver design).
4.6.3.3 Timeline and operational scenarios
4.6.3.3.1 The timeline and radio usage for a user entering and leaving the terminal area are summarized in
Table I-4-5. Mobiles en route (high-altitude or long-range) are allowed to operate autonomously at the default rates.
Table I-4-5. Timeline and reporting rates by airspace region
Reporting rate by channel and airspace domain (reports/minute)
En Transition Approach Take- Transition

Channel route Outer Inner Terminal land Surface Surface off Terminal Inner Outer En route
GSC1 4 4 — — — — — — — — 4 4
GSC2 12 20 20 8 20* — — 20*** 8 20 20 12
LSC — — 8 8 8* — — 8*** 8 8 — —
GND — — — — 60* 60** 60** 60*** — — — —
Total 16 24 28 16 var 60** 60** var 16 28 24 16
* Aircraft on approach may be autotuned from the LSC to GND at the middle marker.
** Stationary aircraft may be commanded into sleep mode and report at a lower rate.
*** Aircraft on take-off report on GND and GSC2. After take-off, they autotune from GND to LSC.
4.6.3.3.2 As a mobile flies into the terminal area, it is detected by the ground station network and autotuned in
line with the transition region operations indicated in Figure I-4-12 and Table I-3-1. Users are shifted off from GSC1
half-way through the transition region, but the elevated reporting rate on GSC2 ensures that overall effective received
update rates are maintained at greater or equal to 16 updates/minute across the boundary (i.e. by temporarily increasing
the reporting rate, aircraft in the inner transition region — which are only receiving the reports from aircraft in the outer
transition region and en route airspace on GSC2 — still receive sufficient reports to satisfy the MASPS).
4.6.3.3.3 Users on final approach may be deterministically commanded to high update rate on GSC2, and then
autotuned from LSC (at low rate) to GND (at high rate) after passing, for instance, the middle marker. After touchdown,
transmissions on GSC2 are commanded off and the user operates solely on GND consistent with the surface operations
concept, including sleep mode for periods of non-movement. In the event of a missed approach, the aircraft continues
to operate on GSC2 and GND as it executes the missed approach procedure, and eventually the ground station will
command it back to GSC2 and LSC. The increased reporting rate on GSC2 during the final phases of the approach
(20 reports per minute) ensures that all aircraft on the ground and in the air continue to monitor the progress of said
aircraft at rates greater than or equal to the MASPS required update rates.
4.6.3.3.4 When an aircraft powers up on the ground, it enters the network on GSC1 and GSC2 at default rates. It
is expected that the entering user will plea to a high-altitude aircraft in overflight or to the local ground station within a
few seconds. GSC1 will always have ample spare capacity, and even GSC2 is expected to have sufficient spare
resources to allow BND and plea. The ground can detect the synchronization bursts and immediately autotune the user
to GND, and then command sleep mode as appropriate (i.e. if the aircraft is parked at the gate). Transmissions on
GSC2 are commanded off, but the receiver remains active to monitor local approaching traffic and build a table of
airborne peers.
4.6.3.3.5 As an aircraft enters the active runway for take-off, it is already monitoring GSC2 and has awareness of
approaching traffic. It is now commanded to start transmissions on GSC2 in anticipation of take-off. Airborne users in
the terminal area “see” the aircraft for the first time prior to the start of its take-off roll. Aircraft on final approach
(those past the middle marker) have already observed it on the GND channel. Following take-off, the mobile is
autotuned from GND to LSC for normal terminal area operations.
4.6.3.3.6 As an aircraft departs the terminal area, it is first commanded to a high update rate on GSC2 (if not
already commanded) and then autotuned from LSC to GSC1 using a directed rate command. The user then applies
RNE to enter GSC1 in 3 to 5 seconds. A final directed rate command on GSC2 resets the nominal update rate on GSC2
for 12 transmissions per minute.
Note.— If this command is not sent or received, the last autotune on GSC2 will time out in no more than
15 minutes and result in default operations at that time.
4.7 DESCRIPTION OF REGIONAL DEFINITIONS

FOR CHANNEL MANAGEMENT
4.7.1 The channel management parameter may be transmitted by a ground station using the UCTRL DLPDU
burst format. As illustrated in Table I-4-6, the channel management parameter has the following basic structure:
Table I-4-6. General structure of channel management parameter
Field Description Size (octets)

Contains the header and the non-repetitive information for
Header block each of the sub-elements. 9
Specifies destination addresses or a defined geographic region
Destination block (regional multicast). 0 to 255
Contains from 0 to 15 user-defined transmission definitions in
Transmission definition block an ordered list. 0 to 15
Frequency block Contains from 1 to 7 frequencies in an ordered list. 1 to 7
Contains Quality of service (QoS) and other transmission
Parameter block parameters to use with the elements of this script. 0 to 11
Contains a repeat rate and from 1 to N script elements in an
Script block ordered list. 1 to 256
4.7.1.1 The header block includes the following types of information:
1) time out value, (dt);
2) script duration type, (styp);
3) script repeat rate parameter (sr) (if styp = 0, sr is the repeat rate per minute; if styp = 1, sr is the number of
minutes until script repeats);
4) command set ID parameter (csid);
5) directed offset parameter (do) (commands directed rate operations if set to 0, or otherwise gives an offset to
directed slots); and
6) parameters which specify the number of octets in each of the following blocks.
4.7.1.2 The destination block contains either:
1) a list of zero or more destinations, with, for each destination, the slot offset (parameter ido) from the current
slot to the start of the script, or;
2) a defined geographic region (regional multicast).
Zero octets in the destination block (parameter destination count dc = 0) implies a channel management parameter
broadcast to all stations.
4.7.1.3 The destination block may be transmitted in the form of a regional multicast command, defining a
specific region of operation. An aircraft which receives the channel management parameter, and is within the defined
region, will operate according to the channel management parameter, unless it is already operating in directed slot
mode (or according to a directed request). The content of the regional multicast command is illustrated in Table I-4-7.
Table I-4-7. Regional multicast block
Description Octet Description

Vertex count (vc) 1 Specifies the number of vertices
Centre latitude 2 Latitude coordinate marking the centre of the defined region
3
Centre longitude 4
5 Longitude coordinate marking the centre of the defined region
Lower altitude 6 Specifies the lower boundary of the altitude

Upper altitude 7 Specifies the upper boundary of the altitude
Radial 1 8 Provides an angle measured from due North for vertex 1
Vertex 1
Distance 1 9 Provides the distance of vertex 1 from the centre of the region
Vertex 2 (if Radial 2 10 Provides an angle measured from due North for vertex 2
required)
Distance 2 11 Provides the distance of vertex 2 from the centre of the region
4.7.1.4 The transmission definition block contains 0 to 15 user-defined transmission definitions in an ordered list.
Each transmission definition describes a particular customized burst type (e.g. a basic synchronization burst) and all
relevant options. The use of a particular transmission block in this list can be defined by an implicit pointer (parameter
txd) in the script block, thereby specifying a particular burst type.
4.7.1.5 The frequency block contains 1 to 7 frequencies in an ordered list and optional sleep parameters to be
used on each frequency. The use of a particular frequency block in this list is defined by an implicit pointer (parameter
frq) used in the script block, thereby specifying a particular frequency.
4.7.1.6 The parameter block defines the QoS and other transmission parameters that must be used to transmit all
of the bursts identified in the script.
4.7.1.7 The script block contains a repeat rate and 1 to N script elements in an ordered list. Each script element
consists of:
1) a pointer (parameter frq) to a specific element in the frequency block;
2) a pointer (parameter txd) to a specific element in the transmission block (or alternatively to a transmission
definition that has been pre-defined in the this manual); and
3) an optional repeat count (parameter rpt) for repeating a particular definition.
4.7.2 Each aircraft processes each channel management parameter as it is received. Upon receiving a channel
management parameter for which:
a) the receiving aircraft determines that it is outside all of the defined regions, or
b) none of the destination addresses listed matches that of the receiving aircraft,
the aircraft ignores the remainder of the channel management parameter and continues with its default synchronization
burst operations. Upon receiving a channel management parameter for which:
a) the defined region applies to that in which the aircraft is currently flying, or
b) one of the destination addresses listed matches that of the receiving aircraft, or
c) the command applies to all stations (i.e. it is broadcast with dc = 0),
then the aircraft will begin operations in accordance with the dictates of the received channel management parameter.
4.7.3 Each channel management parameter contains a directed offset parameter (do) and a destination count
parameter (dc) in the header block. Each aircraft destination address has an individual offset parameter (ido) associated
with it.
4.7.3.1 If an aircraft receives a channel management parameter in which
— dc is set to zero (dc = 0), or
— with dc at any value, do is set to zero (do = 0), or
— with dc non-zero (dc 0), its associated ido is set to zero (ido = 0),
then it will operate in directed rate mode. It will then allocate slots to its transmitted bursts autonomously, keeping to a
nominal periodic repeat rate.
4.7.3.2 However, if an aircraft receives a channel management parameter in which
— dc is non-zero (dc 0), and
— do is non-zero (do 0), and
— its associated ido is non-zero (ido 0),
then the aircraft will operate in directed rate mode. It will then use specific slots with the first burst transmitted in the
slot that is do + ido slots after the first slot of the received channel management parameter.
4.7.4 Each channel management parameter contains a time out parameter (dt). If the command is not refreshed or
explicitly cancelled, the receiving aircraft will continue operations in accordance with the command for dt minutes.
After this time ends, it will terminate the commanded operations and resume its default synchronization burst.
4.7.5 If the aircraft receives a channel management parameter with csid = 0, the aircraft will terminate its default
synchronization burst operations and replace them with the commanded operations. If the aircraft receives another
channel management parameter with the same csid, it will terminate the first set of commanded operations and begin
operation in accordance with the new channel management parameter.
4.7.6 The ground-based service provider can define a transition region, outside its uniquely managed airspace, in
which the operations commanded by the channel management parameter are identical to the en route default
synchronization burst operations. This will force aircraft flying out of the region to revert to default synchronization
burst operation along a well-defined boundary (i.e. instead of waiting for the channel management parameter time out
after dt minutes).
4.7.7 If more precise control of the aircraft behaviour is needed near airspace boundaries, the ground-based
service provider can issue addressed channel management parameters to specific aircraft. If these commands impose
directed slot behaviour, they must be implemented immediately (in the commanded slot) and they cannot be overridden
by subsequent regional commands. However, they will time out as any channel management parameter, and they can
also be cancelled by the ground station at anytime by sending a channel management parameter with csid = 15.
— — — — — — — — —
Appendix A to Chapter 4
FAILURE MODES
1. INTRODUCTION
The failure modes associated with the scenarios discussed in Chapter 4 have been identified as follows:
• loss of an aircraft transmitter in the terminal area
• loss of an aircraft receiver in the terminal area
• loss of all aircraft receivers in the terminal area
• failure of the aircraft to act on instructions from a ground station
• failure of the ground station to instruct the aircraft
• failure of the ground station
• failure of Global Navigation Satellite System (GNSS) receiver on one aircraft
• widespread failure of GNSS in a region
These failure modes are briefly addressed in sections 2 to 6. Work is ongoing to analyze these and other failure modes
in detail. As in the scenarios in Chapter 4, it is assumed that a ground station is present and manages the traffic on the
Global Signalling Channels (GSC) and Local Signalling Channels (LSC).
2. AIRCRAFT LOSES THE TRANSMITTER IN THE TERMINAL AREA
If a user loses a transmitter and has no spare transmitter on-board, that user can still “hear” its peers but cannot transmit,
cannot degrade the channel, and is effectively a non-participant from the standpoint of Automatic Dependent
Surveillance — Broadcast (ADS-B). Airspace procedures must be available to accommodate this user as well as other
users without equipage.
Step 1.— The aircrew is alerted about the condition. If available, switch to back-up or redundant transmitter.
Step 2.— If a ground station is present, then the station will be able to detect that transmissions from the aircraft
have ceased and provide an alert to Air Traffic Services (ATS). Implementation of a Cockpit Display of Traffic
Information (CDTI) alert might also be considered in order to make other aircrew aware of the lost target.
Step 3.— Use pre-defined Very High Frequency (VHF) voice emergency procedures.
I-4A-1
3. LOSS OF ONE AIRCRAFT RECEIVER IN THE TERMINAL AREA
If a user loses a receiver, it will not respond to autotuning commands issued on the associated frequency and this will
be a syndrome detectable on the ground. The user may still transmit on this frequency (i.e. if it fails to detect the
receiver failure) and can potentially share slots in an undisciplined way. However, the low duty cycle on any given
frequency implies that overall subnetwork impact is small. If undisciplined sharing occurs in a slot, the likelihood is
that nearby users will still achieve reliable receive performance. The ground infrastructure may also rely on the
diversity of the location of the ground sites (and possibly directional antennas) in order to achieve a more reliable
reception of messages transmitted in shared slots1.
3.1 Two receivers remain operational in airspace

where three receivers are required
Step 1.— If available, switch to back-up or redundant receiver used possibly for other services.
Step 2.— When instructed to activate operations on an LSC, then use channel assigned for GSC2 (i.e. transmit on
GSC1 and LSC1).
Step 3.— The ground station will be able to detect that transmissions from the aircraft have ceased on GSC2 and
provide an alert to ATS. Implementation of a CDTI alert might also be considered in order to make other aircrew aware
of the condition. However, uninterrupted ADS-B reports on GSC1 would still be received by other aircraft.
Step 4.— If required, use pre-defined Air Traffic Control (ATC) procedures.
`
Note.— This failure mode will have only marginal impact on operations as long as dual equipment is available.
3.2 A single receiver remains operational
Step 1.— If available, switch to back-up or redundant receivers used for other services.
Step 2.— If possible, switch the remaining receiver to GSC1.
Step 3.— The ground station will be able to detect that transmissions from the aircraft have ceased on individual
channels and send an alert to ATS. Implementation of a CDTI alert might also be considered in order to make other
aircrew aware of the condition.
Step 4.— If available, activate Traffic Information Services — Broadcast (TIS-B) uplink for the failing aircraft.
Step 5.— If required, use pre-defined ATS procedures.
Note.— This failure mode will have only marginal impact on operations as long as dual equipment is available.
3.3 Loss of all receivers in the terminal area
Step 1.— Stop transmitting on all channels.
Step 2.— The ground station will be able to detect that transmissions from the aircraft have ceased and send an
alert to ATS. Implementation of a CDTI alert might also be considered in order to make other aircrew aware of the
condition.
___________________
1. If the mobile detects that the receiver has failed, then it will halt operations on the frequency which it cannot monitor.
Step 3.— If available, activate TIS-B uplink for the failing aircraft.
Step 4.— Use pre-defined VHF voice emergency procedures.
4. AIRCRAFT FAILS TO ACT ON SWITCHING INSTRUCTION

FROM THE GROUND STATION OR GROUND STATION
FAILS TO INSTRUCT AIRCRAFT
Step 1.— The ground station monitors actions taken in response to its instruction and, if necessary, repeats the
instruction.
Step 2a.— For an inbound aircraft, the failed action means that the reporting/reception on the LSCs would not be
activated while the reporting/reception on the GSCs would be maintained. The aircraft would still be visible to other
aircraft and to the ATS, but the update rate would be lower. The inbound aircraft would receive ADS-B reports from
other aircraft in the air and on the ground on the GSCs, but again, the update rate would be lower.
Step 2b.— For an outbound aircraft, the failed action means that the reporting on one or both LSC channels would
not be deactivated. However, time out would occur after a maximum of 15 minutes, and the aircraft would then revert
to default reporting on both GSCs.
Step 3.— Use pre-defined ATS and airport procedures as required.
5. FAILURE OF THE GROUND STATION
Step 1.— The aircraft detects that no ground station is present since its position reports time out, including the
Directory of Service (DoS) report.
Step 2.— ATS is informed about the failure of the ground station from the monitoring system.
Step 3.— Aircrews are informed that only Aircraft in the Future ATM System (AFAS) services are available.
Step 4.— Use pre-defined ATS and airport procedures as required.
6. GLOBAL NAVIGATION SATELLITE SYSTEM (GNSS) FAILURE MODES
6.1 In the event of the loss of GNSS receive capability by a single aircraft, that aircraft can maintain secondary
time by monitoring the transmissions of other stations. If the affected aircraft was also using Global Positioning System
(GPS) as the source of navigation, it could potentially perform secondary navigation based on the transmissions of local
ground stations2, revert to other on-board means of navigation, or declare itself to be lost3.
___________________
2. Secondary navigation is not a required capability in SARPs, but it is an option that may be supported by service providers. The timing
accuracy for ground uplink transmissions required to support secondary navigation would be accommodated by the primary timing state
when the certified flag is expected to be supported by these stations.
3. The VDL Mode 4 radio may be lost even if an alternative means of navigation exists (e.g. if the alternative means of navigation is not
connected to the VDL Mode 4 radio).
6.2 If the airborne station declares itself to be lost, the ground can potentially determine its position by
triangulation (e.g. to support surveillance with a degraded level of accuracy). The triangulated position could be
communicated to other mobile stations via TIS-B, if available. The ground may also autotune the mobile to a lower
reporting rate that is consistent with its surveillance requirements (i.e. since high reporting rate is useless if the ADS-B
reports contain no information). As with any ADS-B scheme, appropriate airspace procedures will have to be in place
to allow for the safe management of traffic, given the navigation failure of the mobile.
6.3 In the event of a widespread GPS failure (e.g. jamming), aircraft can maintain secondary time by monitoring
the transmissions of local ground stations. Secondary navigation would also be feasible, as would alternative means of
navigation.
— — — — — — — — —
Appendix B to Chapter 4
ADS-B REQUIREMENTS AIR-TO-AIR
Requirements outlined in Table I-4B-1 are an extract of the Radio Technical Commission for Aeronautics (RTCA)
Automatic Dependent Surveillance — Broadcast (ADS-B) Minimum Aviation System Performance Standard (MASPS)
dated 19 February 1998. Note that RTCA has not defined all requirements and there is a To be Defined (TBD) in
Note 10.
Table I-4B-1. ADS-B report accuracy, update period and acquisition range requirements
Conflict
avoidance and Separation Flight path
Aid to visual collision assistance and deconfliction Simultaneous Airport surface
acquisition avoidance sequencing planning Approach (Note 4)
State vector 10 NM 20 NM 40 NM 90 NM (Note 3) 10 NM 5 NM
acquisition range (120 NM desired)
Mode-status 10 NM 20 NM 40 NM 90 NM (Note 3) 10 NM 5 NM
(Note 7)
On condition n/a n/a n/a 90 NM (Note 3) 10 NM TBD
(Note 7)
Nominal update 3 sec 3 sec 7 sec 12 sec 1.5 sec 1.5 sec
period (95th (3 NM) (3 NM) (20 NM) (1 000 ft runway
percentile) (1 sec desired, separation)
(Note 5) Note 2)
(Note 6)
5 sec 7 sec 12 sec 3 sec (1 sec
(10 NM) (20 NM) (40 NM) desired)
(2 500 ft runway
separation)
99th percentile 6 sec 6 sec 14 sec 24 sec 3 sec (1 000 ft 3 sec
state vector report (3 NM) (3 NM) (20 NM) runway
separation)
(1 sec desired,
Note 2)
Received update 10 sec 14 sec 24 sec 24 sec 7 sec 3 sec
period (Coast (10 NM) (20 NM) (40 NM) (2 500 ft runway
interval) separation)
(Notes 6, 7)
Permitted total σhp = 200 m σhp = 20/50 m σhp = 20/50 m σhp = 200 m σhp = 20 m σhp = 2.5 m
state vector errors σhv = n/a (Note 1) (Note 1) σhv = 5 m/sec σhv = 0.3 m/sec (Note 8)
required to support σvp = 32 ft σhv = 0.6/0.75 m/sec σhv = 0.3/0.75 m/ σvp = 32 ft σvp = 32 ft σhv = 0.3 m/sec
application σvv = 1 fps (Note 1) sec σvv = 1 fps σvv = 1 fps σvp = n/a
(1 sigma, 1D) σvp = 32 ft (Note 1) σvv = n/a
σvv = 1 fps σvp = 32 ft
σvv = 1 fps
I-4B-1
State vector errors σhp = 20 m σhp = 2.5 m

budgeted for σhv = 0.25 m/sec (Note 8)
ADS-B σvp = 30 ft σhv = 0.25 m/sec
(1 sigma, 1D) σvv = 1 fps σvp = n/a
(Note 9) (Note 10) σvv = n/a
Definitions:
hp: Standard deviation of horizontal position error.

hv: Standard deviation of horizontal velocity error.
vp: Standard deviation of vertical position error.
vv: Standard deviation of vertical velocity error.
Note 1.— The lower number represents the desired accuracy for best operational performance and maximum
advantage of ADS-B. The higher number, representative of Global Positioning System (GPS) standard positioning
service, represents an acceptable level of ADS-B performance, when combined with barometric altimeter.
Note 2.— The analysis in Appendix J of RTCA ADS-B MASPS Do-242 indicates that a 3-second report received
update period for the full state vector will yield improvements in both safety and alert rate relative to Airborne
Collision Avoidance System (ACAS) II, which does not measure velocity. Further improvement in these measures can
be achieved by providing a 1-second report received update rate. Further definition of ADS-B based separation and
conflict avoidance system(s) may result in refinements to the values in this table.
Note 3.— The 90-NM range requirement applies in the forward direction. The required range aft is 30 NM (40 NM
desired). The required range 90 degrees to port and starboard is 45 NM (60 NM desired) (see Appendix H of RTCA
ADS-B MASPS Do-242).
Note 4.— Requirements apply to both aircraft and vehicles.
Note 5.— Supporting analyses for update period and update probability are provided in Appendices J and L of
RTCA ADS-B MASPS Do-242.
Note 6.— Acceptable combinations of report update period (T) and update probability (P) are given by the
formula (1-P)TC/T < 0.01 where TC is the 99th percentile report update period given in the table. For example, for
conflict avoidance, TC = 6 sec.; a report update period of T = 3 would require P= 0.9 or greater. As a second example,
for conflict avoidance, if P = 0.5, then T must be 0.9 seconds or less.
Note 7.— The delay for MS or OC report updates after a MS or OC state change should be no more than the coast
interval associated with the state vector report (with 95 per cent confidence).
Note 8.— The position accuracy requirement for aircraft on the airport surface is stated with respect to the
certified navigation centre of the aircraft.
Note 9.— This row represents the allowable contribution to total state vector error from ADS-B.
Note 10.— The horizontal velocity error requirements to aircraft speeds of up to 600 knots. Accuracies required
for velocities above 600 knots are TBD.
Note 11.— Specific system parameter requirements in Table 3.3-3 from RTCA ADS-B MASPS Do-242 as approved
in Working Group Meeting 1 (WGM1) can be waived provided that the system designer shows that the application
design goals stated in Appendix J of RTCA ADS-B MASPS Do-242 as approved in WGM1 or equivalent system level
performance can be achieved.
Note 12.— Update periods for the SV have been emphasized in determining link related performance requirements
in this table. Lower rates of MS and OC are under development. These reports should be made available to support the
operational capabilities using considerations equivalent to the SV. The requirement should be optimized to ensure that
the refresh/update of reports is appropriate for the equipment classes and the operations being supported. Refer to the
analysis presented in Appendix L of RTCA ADS-B MASPS Do-242 as approved in WGM1 for further details.
___________________
Chapter 5
POTENTIAL FUTURE APPLICATIONS FOR VDL MODE 4
5.1 INTRODUCTION
This chapter describes the potential future applications of VDL Mode 4 which might result from future development
and standardization activities. ICAO validation of VDL Mode 4 only applies to services and applications related to
surveillance. Navigation and communications services and applications, such as Ground-based Regional Augmentation
Service (GRAS) and Controller-Pilot Data Link Communication (CPDLC), are included in this section only to illustrate
possible future capabilities.
5.2 OVERVIEW OF VDL MODE 4 SERVICES
VDL Mode 4 provides a range of digital communications services that could support many Communications,
Navigation, and Surveillance (CNS) and Air Traffic Management (ATM) applications, in addition to the surveillance
services described in 5.1. The full range of potential services are illustrated in Figure I-5-1. VDL Mode 4 therefore
provides a platform for developing new yet not fully defined applications. Such applications operate in a wide range of
operational scenarios, from worldwide civil aviation to the local airport environment.
Cockpit Display of Traffic

Information (CDTI)
Flight Information Airborne separation
Controller-Pilot Data Air-air Service-Broadcast assurance (ASAS)
Link Communication communications (FIS-B) Precision Runway
(CPDLC) Non-ATN Air-air Traffic Information Monitoring (PRM)
User ADS-Contract ground-air trajectory Precision Service-Broadcast
function and navigation Surface movement
(ADS-C) communication negotiation (TIS-B) surveillance (SMS)
applications Non Precision
Approach Secondary navigation
Core functions ground-air

ATN GRAS data broadcast ADS-B
supported by
VDL Mode 4
ground-air ground-air air-air ground-air air-air ground-air air-air

VDL Mode 4
services End-to-end End-to-end Data Position
communications communications broadcast broadcast
ATN services VDL Mode 4 Specific Services
Figure I-5-1. VDL Mode 4 communications services and sample applications
I-5-1
5.3 FUNCTIONS AND APPLICATIONS
This section expands on the potential future functions and applications of VDL Mode 4 in CNS and ATM as identified
in Figure I-5-1. It should be noted that the boundaries between Communications, Navigation and Surveillance are
somewhat blurred, as all functions and applications essentially are based on (data link) communications. In this section,
an individual application is classified according to its intended use.
5.3.1 Potential communications applications
5.3.1.1 Controller-Pilot Data Link Communications (CPDLC)
Controller-Pilot Data Link Communication (CPDLC), illustrated in Figure I-5-2, is an Aeronautical

Telecommunication Network (ATN) function providing point-to-point communications of time-critical data between
pilots and controllers. CPDLC enables a whole host of control-related applications, including delivery of Air Traffic
Control (ATC) Clearances (ACL), ATC Communications Management (ACM), Flight Plan Consistency Checking
(FLIPCY), and Dynamic Route Availability Notification (DYNAV).
5.3.1.2 Pre-departure clearance (PDC)
Pre-departure clearance (PDC) could be described as a variant of CPDLC for semi-automated data link exchange of
messages between an aircraft and the control tower (TWR) prior to commencement of taxiing for take-off.
5.3.1.3 Flight Information Services (FIS)
5.3.1.3.1 Flight Information Services (FIS) is a ground-generated communication function that provides time-
sensitive weather and supporting information to the aircraft. The information could be carried via the point-to-point
services provided by the ATN services of VDL Mode 4 or via the broadcast services of VDL Mode 4. Flight
Information Services Broadcast (FIS-B) is illustrated in Figure I-5-3.
ATC Network
Figure I-5-2. Controller-pilot data link communications (CPDLC)

Chapter 5. Potential future application for VDL Mode 4 I-5-3
5.3.1.3.2 FIS-B is expected to support applications such as uplink of weather graphics, Automatic Terminal
Information Service (ATIS) and VOLMET. The coverage of the FIS-B service can be extended through a ground
network that would allow, for instance, the ATIS of the destination airport to be received early during the flight.
5.3.1.3.3 Transmission of information from the ground can also be initiated by an aircraft request. This is a point-
to-point application that is supported by VDL Mode 4 ATN or by non-ATN communication services.
5.3.1.4 Airline operational communications (AOC)
The airline companies communicate internal information which is important for their operations. Some information is
essential for flight safety, especially in emergency situations. Most information is not time-critical and often large
packages of data are exchanged. The competitive situation between different airline companies requires protection of
information. VDL Mode 4 can support AOC either through its ATN capability or by supporting communication via a
custom network.
Note.— ICAO does not provide standardization services for AOC.
5.3.2 Potential navigation applications
5.3.2.1 Global Navigation Satellite System (GNSS) augmentation
Global Navigation Satellite System (GNSS) augmentation using VDL Mode 4 is under study. (See Figure I-5-4.)
5.3.2.1.1 When using GNSS data for navigation or surveillance, a GNSS augmentation system is required to
ensure the quality of the position data. The augmentation signals may be derived by a ground-based monitor that
monitors the quality of the GNSS signals and transmits quality (integrity) reports as well as correction data to overcome
• ATIS
• VOLMET
• OPMET
Information system
Network
ATC
Figure I-5-3. Flight information service — Broadcast (FIS-B)

errors in the signals from the satellites. Combined with a GNSS reference receiver for computing differential
corrections and integrity data for satellites in view of the ground station, VDL Mode 4 can be used to create a local
GNSS augmentation system. When a VDL Mode 4 ground station is within line-of-sight, GNSS augmentation signals
can be received by air and ground users. In the VDL Mode 4 concept, GNSS augmentation is broadcast on a VHF
channel in the protected aeronautical band (108 to MHz). The concept is illustrated in Figure I-5-4.
5.3.2.1.2 Local GNSS augmentation through VDL Mode 4 can be extended to create a GNSS GRAS. GRAS is
proposed as a complement to the satellite-based augmentation system (SBAS) in order to provide GNSS augmentation
service over a wide geographical area through a network of ground stations. GRAS coverage would be created by
connecting, through a ground network, the single ground station in Figure I-5-4 to other ground stations, typically
located at airports. The network would be used for monitoring of the operation and possibly for exchange of
information between individual stations in order to further enhance the integrity of the broadcast augmentation data. A
GRAS network could be expanded indefinitely.
5.3.2.1.3 GRAS is also proposed to support navigation in all phases of flight, down to and including non-
precision approach with vertical guidance (NPV) and Advanced Surface Movement Guidance and Control System
(A-SMGCS). NPV is also a non-precision approach operation in which GNSS information is used to provide vertical as
well as horizontal guidance. GRAS service may be provided on a dedicated channel or by allocating some of the data
link capacity to GNSS augmentation on Automatic Dependent Surveillance Broadcast (ADS-B) channels. Channel
allocation depends on the complexity of the environment in which GRAS operates.
Differential corrections
Integrity information
DGNSS
Figure I-5-4. Global Navigation Satellite System (GNSS) augmentation

Chapter 5. Potential future application for VDL Mode 4 I-5-5
5.3.2.1.4 An airborne user will likely receive augmentation signals from multiple GRAS stations. All ground
stations transmit their identity and location. This data can be used to distinguish between transmissions, but there are
also several other possibilities:
a) a scheme is used to select the proper station stored in the airborne data base;
b) a selection based on the distance between the user and the ground stations (the nearest station is routinely
selected);
c) a combination of a) and b) allowing a timely switch to the destination ground station; and
d) pilot selection.
5.3.2.1.5 If data from the primary station is lost, the next adjacent station is automatically selected. A secondary
station may not, however, be suitable for supporting approach operations due to coverage limitations at low altitude.
The pilot should be informed about the current selection of ground station and any limitations for its use for the
ongoing operation.
5.3.2.2 Secondary navigation capability
In case the navigation (and hence time) input to a VDL Mode 4 transponder should fail, VDL Mode 4 operation can
devolve to a lower performance navigation capability by measuring the range (ranging) from the VDL Mode 4 ground
stations or from nearby users using their received position and time. The position is less precise than that offered by
GNSS, but it will still have sufficient accuracy to support en route operations and to act as a backup mode. The concept
is illustrated in Figure I-5-5 and Figure I-5-6. The VDL Mode 4 standards do not require a secondary navigation
capability, but do accommodate a possibility for its implementation.
t = time delay
t1 t3
t2
Figure I-5-5. Secondary navigation capability

t = time delay
t1 t3
t2
Figure I-5-6. Secondary navigation based on ADS-B reports from others users
5.4 SUMMARY OF POTENTIAL FUTURE VDL MODE 4 CAPABILITIES
Table I-5-1 outlines how the requirements for data link capabilities in the future could be accommodated by VDL
Mode 4 as a result of further development and standardization activities.
Table I-5-1. Potential future VDL Mode 4 capabilities
Scenario feature in Chapter 5 Comments
Communications
FIS-B Broadcast services such as ATIS, VOLMET, PIREP, SIGMET and

graphical weather are supported.
D-FIS (such as D-OTIS and D-RVR) Addressed service. Supported. D-OTIS and D-RVR may use broadcast
uplink after establishment of service.
Pre-departure Clearance (PDC) Addressed service. Supported.
Requested data, such as MET report Addressed service. Supported.
AOC communications Can be supported through ATN or via a custom network.

Transparent communications including Addressed or broadcast service. Supported.
Estimated Time Arrival negotiations Transparency provided by the ground infrastructure
Navigation
Secondary Navigation The current standard provides a facility to support secondary navigation
but does not require support for this function
END
PART II
DETAILED TECHNICAL SPECIFICATION

LIST OF ILLUSTRATIONS
List of Tables
Chapter 1. LINK LAYER PROTOCOLS AND SERVICES
Table II-1-1 Parameters, timers and counters for link layer protocols and services. . . . . . . . . . . . . . . . . II-1-2
Table II-1-2 Symbols and variables for link layer protocols and services .............................................. II-1-4
Table II-1-3 Media Access Control (MAC) service system parameters ................................................. II-1-8
Table II-1-4 Operating modes and time synchronization........................................................................ II-1-9
Table II-1-5 Burst format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-13
Table II-1-6 Message ID (mi) assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-14
Table II-1-7 Extended reservation ID (erid) field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-15
Table II-1-8 Autonomous/directed flag (a/d) encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-16
Table II-1-9 VDL Mode 4 specific services (VSS) sub-layer parameters . . . . . . . . . . . . . . . . . . . . . . . . . II-1-16
Table II-1-10 VSS quality of service (QoS) system parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-17
Table II-1-11 Priority levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-18
Table II-1-12 Slot selection criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-21
Table II-1-13 Action in the event of reservation conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-25
Table II-1-14 Random access VSS system parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-26
Table II-1-15 Null reservation bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-28
Table II-1-16 Periodic broadcast reservation bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-29
Table II-1-17 Periodic broadcast reservation field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-29
Table II-1-18 Periodic broadcast VSS system parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-30
Table II-1-19 Action on receipt of periodic broadcast reservation burst . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-31
Table II-1-20 Incremental broadcast reservation bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-35
Table II-1-21 Incremental broadcast reservation field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-35
Table II-1-22 Incremental broadcast VSS system parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-35
Table II-1-23 Combined periodic/incremental broadcast reservation bit encoding . . . . . . . . . . . . . . . . . . II-1-37
Table II-1-24 BND broadcast reservation bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-38
Table II-1-25 BND broadcast reservation parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-38
Table II-1-26 Unicast request reservation bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-39
Table II-1-27 Unicast request reservation field encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-39
Table II-1-28 Unicast request VSS system parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-40
Table II-1-29 Information transfer request reservation bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-42
Table II-1-30 Information transfer reservation field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-43
Table II-1-31 Information transfer request VSS system parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-43
Table II-1-32 Directed request reservation bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-46
Table II-1-33 Nominal update rate (nr) encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-46
Table II-1-34 Encoding of additional data in autotune reservation burst . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-47
Table II-1-35 Directed request reservation field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-47
Table II-1-36 Encoding of additional data with nominal update rate (nr) ≠ special. . . . . . . . . . . . . . . . . . II-1-49
Table II-1-37 Encoding of additional data for nominal update rate (nr) = special . . . . . . . . . . . . . . . . . . . II-1-49
Table II-1-38 Directed request VSS system parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-50
Table II-1-39 Action on receipt of an autotune reservation burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-50
II-(i)
II-(ii) Manual on VHF Digital Link (VDL) Mode 4
Table II-1-40 Superframe block reservation bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-55

Table II-1-41 Superframe reservation field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-55
Table II-1-42 Second frame block reservation bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-56
Table II-1-43 Second frame block reservation field encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-56
Table II-1-44 Superframe block reservation VSS system parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-56
Table II-1-45 Actions on receipt of a superframe block reservation burst. . . . . . . . . . . . . . . . . . . . . . . . . . II-1-57
Table II-1-46 Further actions on receipt of a superframe block reservation burst . . . . . . . . . . . . . . . . . . . II-1-58
Table II-1-47 Action on receipt of a superframe block reservation burst if roff bs. . . . . . . . . . . . . . . . . II-1-58
Table II-1-48 Second frame block reservation parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-59
Table II-1-49 Response burst reservation bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-62
Table II-1-50 General request bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-62
Table II-1-51 General request field encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-63
Table II-1-52 General response bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-64
Table II-1-53 General response field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-64
Table II-1-54 Error type (err) definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-65
Table II-1-55 Address type field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-69
Table II-1-56 Broadcast and multicast address encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-70
Table II-1-57 Normal unicast DLS burst format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-71
Table II-1-57a DATA DLPDU encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-71
Table II-1-57b RTS DLPDU encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-72
Table II-1-57c Single octet DLPDUs encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-72
Table II-1-57d Interpretation of negotiation (neg) subfield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-74
Table II-1-57e One-byte UDATA burst format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-74
Table II-1-57f Two-byte UDATA burst format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-74
Table II-1-57g Three-byte UDATA burst format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-75
Table II-1-57h Encoding of the UDATA ID (udid) value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-75
Table II-1-57i UINFO ID (uinf) assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-75
Table II-1-57j Compressed combined RTS/INFO (type 1) burst format. . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-76
Table II-1-57k Compressed combined RTS/INFO (type 2) burst format. . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-76
Table II-1-58 DLS system parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-77
Table II-1-59 Re-transmission parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-79
Table II-1-60 Short transmission INFO DLPDU parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-82
Table II-1-61 Long transmission Request to Send (RTS) DLPDU parameters . . . . . . . . . . . . . . . . . . . . . II-1-84
Table II-1-62 General response to Request to Send (RTS) parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-84
Table II-1-63 Clear to Send (CTS) DLPDU parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-85
Table II-1-64 Synchronization burst format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-93
Table II-1-65 Synchronization burst field encoding (fixed data field) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-94
Table II-1-66 Encoding of navigational integrity category (nic). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-95
Table II-1-67 Base altitude encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-95
Table II-1-68 Report latency encoding and decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-96
Table II-1-69 CTRL DLPDU format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-97
Table II-1-70 UCTRL DLPDU format for broadcast of link management information . . . . . . . . . . . . . . II-1-97
Table II-1-71 VDL Mode 4 parameter identifier purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-98
Table II-1-72 Parameter set identifier encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-99
Table II-1-73 Connection management parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-99
Table II-1-74 Connection management parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-99
Table II-1-75 Abbreviated Control (CTRL) names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-100
Table II-1-76 Control (CTRL) sequencing parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-100
Table II-1-77 Protocol options parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-100
Table II-1-78 Protocol options parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-101
Table II-1-79 Link Connection Rejection (LCR) cause parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-101
Table II-1-80 Cause code table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-102
Part II. Detailed Technical Specifications
List of Illustrations II-(iii)
Table II-1-81 UCTRL_DM parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-103

Table II-1-82 Modulation support list encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-103
Table II-1-83 Modulation encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-103
Table II-1-84 Acceptable alternative ground station parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-104
Table II-1-85 Destination airport parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-104
Table II-1-86 Data link service (DLS) parameter encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-105
Table II-1-87 VSS sub-layer parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-105
Table II-1-88 Quality of service (QoS) parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-106
Table II-1-89 m2 filter parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-106
Table II-1-90 CG1 filter parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-107
Table II-1-91 Autotune parameter encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-107
Table II-1-92 L1 parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-108
Table II-1-93 Management entity system parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-108
Table II-1-94 Replacement ground station list parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-109
Table II-1-95 Random access parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-109
Table II-1-96 Re-transmission parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-109
Table II-1-97 Timer TL1 parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-110
Table II-1-98 Ground station address filter parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-110
Table II-1-99 Broadcast connection parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-111
Table II-1-100 Airport coverage indication parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-111
Table II-1-101 Nearest airport parameter encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-112
Table II-1-102 ATN router NETs parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-112
Table II-1-103 Ground-based system mask parameter encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-112
Table II-1-104 Frequency support list encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-113
Table II-1-105 Directory of Service (DoS) message encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-113
Table II-1-106 Directory of Service (DoS) message subfield encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-114
Table II-1-107 Allocation of application (a) fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-115
Table II-1-108 Allocation of service information type (sit) fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-115
Table II-1-109 Synchronization burst parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-117
Table II-1-110 Synchronization burst parameters for conflict resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-119
Table II-1-111 Plea parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-120
Table II-1-112 Asynchronous events affecting value of management filter CG1. . . . . . . . . . . . . . . . . . . . . II-1-121
Table II-1-113 Conditions for network entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-122
Table II-1-114 Plea burst parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-123
Table II-1-115 Plea response parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-124
Table II-1-116a Control (CTRL) parameters (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-134
Table II-1-116b Control (CTRL) parameters (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-135
Table II-1-116c Control (CTRL) parameters (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-136
Chapter 2. VDL MODE 4 MOBILE SUBNETWORK DEPENDENT

CONVERGENCE FUNCTION (SNDCF)
No tables.
Chapter 3. ADDITIONAL MATERIAL FOR ADS-B APPLICATION
Table II-3-1 Summary of parameter symbols for ADS-B applications . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-1

Table II-3-2 ADS-B information fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-3
Table II-3-3 Information field 0 hex — Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-4
Table II-3-4 Information field 1 hex — High dynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-4
II-(iv) Manual on VHF Digital Link (VDL) Mode 4
Table II-3-5 Information field 2 hex — Full position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-5

Table II-3-6 Information field 3 hex — Basic ground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-5
Table II-3-7 Information field 4 hex — UTC time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-6
Table II-3-8a Information field 8 hex — Two-slot Trajectory Change Point (TCP)/
State Vector Quality (SVQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-6
Table II-3-8b Information field 9 hex — Single-slot TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-7
Table II-3-8c Information field 5 hex — Single-slot SVQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-8
Table II-3-9 Information field A1 hex — Aircraft data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-8
Table II-3-10 Information field AA0 hex — High resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-9
Table II-3-11 Information field encoding (variable data field) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-9
Table II-3-12 Baro/geo offset (bgo) encoding (variable data field) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-11
Table II-3-13 Ground speed (gs) encoding (variable data field) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-12
Table II-3-14 Altitude rate (altr) magnitude encoding and decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-12
Table II-3-15 Aircraft category (ac) encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-13
Table II-3-16 Aircraft status (st) (emergency/priority status) encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-14
Table II-3-17 Time to go (ttg) subfield encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-14
Table II-3-18 ADS-B request bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-14
Table II-3-19 ADS-B request bit encoding for autonomous monitoring (sleep) mode
parameters when sleep bit = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-15
Table II-3-20 ADS-B request bit encoding for autonomous information (auto) parameters
when auto bit = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-15
Table II-3-21 ADS-B request field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-16
Table II-3-22 Example of ADS-B request bit encoding for sleep mode with request for
high precision variable part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-17
Table II-3-22a Trajectory Change Point (TCP) update rate parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-18
Table II-3-22b State Vector Quality (SVQ) update rate parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-19
Table II-3-23 Encoding of application fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-19
Table II-3-24 Encoding of service information (si)field for sit = hex 00. . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-20
Table II-3-25 Component blocks of channel management parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-20
Table II-3-26 Header block bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-21
Table II-3-27 Header block field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-21
Table II-3-28 Addressed destination block bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-23
Table II-3-29 Addressed destination block field encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-23
Table II-3-30 Regional multicast block bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-24
Table II-3-31 Regional multicast block field encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-25
Table II-3-32 Vertex distance encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-25
Table II-3-33 Action on receipt of a channel management parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-26
Table II-3-34 Pre-defined transmission block definition encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-28
Table II-3-35 User-defined synchronization burst transmission block bit encoding . . . . . . . . . . . . . . . . . II-3-29
Table II-3-36 User-defined synchronization burst transmission block field encoding . . . . . . . . . . . . . . . II-3-29
Table II-3-37 Non-synchronization burst transmission block bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . II-3-29
Table II-3-38 Non-synchronization burst transmission block field encoding . . . . . . . . . . . . . . . . . . . . . . . II-3-29
Table II-3-39 Frequency block bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-30
Table II-3-40 Frequency block field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-30
Table II-3-41 Parameter block bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-31
Table II-3-42 Script block bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-31
Table II-3-43 Script block field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-3-31
Chapter 4 DEFINITIONS FOR COMPACT POSITION REPORTING (CPR)
Table II-4-1 Summary of parameter symbols for CPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-1

List of Illustrations II-(v)
Table II-4-2 Constants used in CPR calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-1

Table II-4-3 Variables used in CPR calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-2
Table II-4-4 Input parameters and return values for functions used in CPR calculations . . . . . . . . . . . . II-4-3
Table II-4-5 Transition table for lookup function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-4
Table II-4-6 Position report processing parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-17
Table II-4-7 State transitions for CPR processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-4-18
Table II-4-8 State transitions for CPR processing (transition level straddling) . . . . . . . . . . . . . . . . . . . . II-4-20
___________________
ACRONYMS, ABBREVIATIONS AND SYMBOLS
A/A Air/Air
ACK Acknowledgment DLPDU
ADM Administration identifier
ADS-B Automatic Dependent Surveillance — Broadcast
A/G Air/Ground
AGL Above ground level
ARS Administration region selector
ATN Aeronautical Telecommunications Network
ATS Air Traffic Services
BND Big negative dither
CCI Co-channel interference

CMD Command
CPR Compact Position Reporting
CRC Cyclic Redundancy Check
CSC Common Signalling Channel
CTRL Control (DLPDU)
CTS Clear to Send (DLPDU)
dB Decibel
DLE Data Link Entity
DLPDU Data Link Protocol Data Unit
DLS Data link service
DM/DISC Disconnect mode (for connected links)
DM/FRMR Disconnect mode (for disconnected links)
DME Distance measuring equipment
DoS Directory of Service
DTE Data terminal equipment
fpm feet per minute

fps feet per second
FIS-B Flight Information Service — Broadcast
FRMR Frame reject (DLPDU)
GBAS Ground-based Augmentation System

GFSK Gaussian-filtered Frequency Shift Keying
GNSS Global Navigation Satellite System
GPS Global Positioning System
GSC Global Signalling Channel
GSIF Ground station information frame
hex Hexadecimal
HO Handoff
II-(vii)
II-(viii) Manual on VHF Digital Link (VDL) Mode 4
HPL Horizontal Protection Limit
IA5 The character set defined in ISO 646 Table 5

ICAO International Civil Aviation Organization
INFO Information (DLPDU)
IS-SME Intermediate System — System Management Entity
ISO International Standardization Organization
LCR Link Connection Rejection/Refused

LE Link Establishment
LME Link Management Entity
LSC Local Signalling Channel
MAC Media Access Control

MASPs Minimum Aviation System Performance Standards
msec milliseconds
N/A Not applicable

NAC Navigational accuracy category
NACK Negative acknowledgment
ND Negative dither
NES Number of elements in the script
NET Network entity titles
NIC Navigational integrity category
NM nautical mile
NPA Non-precision approach
ns nanosecond
NSCOP Network Set-up Connection Oriented Protocol
NTM Number of transmissions per minute
PECT Peer Entity Contact Table
QoS Quality of Service
RNP Required Navigation Performance

RSP Required Surveillance Performance
RTCA Radio Technical Commission for Aeronautics
RTS Request to Send (DLPDU)
SARPS Standards and Recommended Practices

SBAS Spaced-based Augmentation System
SIL Surveillance Integrity Level
SNDCF Subnetwork Dependent Convergence Function
SPS Standard Positioning Service
SVQ State Vector Quality metrics (NIC/NAC/SIL)
SZOM Start Zero Overhead Mode (DLPDU)
TCP Trajectory Change Point

TDMA Time Division Multiple Access
Tfom Time figure of merit
TIS-B Traffic Information Service — Broadcast
Acronyms, abbreviations and symbols II-(ix)
µs microsecond
UDATA broadcast equivalent of DATA and embraces all broadcast-type DLPDUs.
UTC Universal Time Coordinated
VDL VHF (Very High Frequency) Digital Link

VLMC Virtual Link Management Channel
VME VDL Mode 4 management entity
VSS VDL Mode 4 specific services
WGS World Geodetic System
ZOCOP Zero Overhead Connection-Oriented Protocol
___________________
!"
! " #$$ #%
" $ !! $ & !
$ ! " $ #' %
$ " $ $ $ $ ((
%
!" # # ! $ $ )
# $ %
" " " $ $ $ ( )
" $ * $ $ $ $ ( )
& ' %( ")%( ** $ % + ) %")* !%
) $ +" ! ! , ,+ *
$ !! $ $ " $ $ $ $ - ! )
$ !%) ! $ * $ ! )
!
! " # " #
"! !
! " #
$%& '
# $ %! &' (%) ! & * + &

! &
"* &
(
"
" !' , - !. ) )
* ! '
/ !
!
( # + , --
) ) # + --&+&+
# "! &
#.+ #.+ --&+&++$
#.+/ #.+ --&+&+++
#.+/ ! --&+&+++
0
#.+/ 0 --&+&+++
1( 2
#.+/ ! --&+&+++
Part II. Detailed technical specifications
Chapter 1. Link layer protocol and services II-1-3
Parameter Name Section or table defined in

CG1_range Range limit used in digital filter for “exposure” determination Table II-1-111
CG1_reach Maximum unreachability time Table II-1-111
L1 Maximum number of missed reservations 1.2.4.3, 1.5.4.1
M1 Number of slots per superframe Table II-1-3, 1.2.2.1
M2_inc Filter increment for receiver blocking check Table II-1-3, 1.2.2.2
M2_limit Filter threshold for receive blocking check (network entry) Table II-1-3, 1.2.2.2
ND1 Maximum number of octets in any user data packet Table II-1-58, 1.4.3.3
ND2 Maximum length of data link service (DLS) transmission Table II-1-58, 1.4.3.4
ND3 Maximum length of fragment Table II-1-58, 1.4.3.5
ND4 Maximum size of a UDATA burst Table II-1-58
P Persistence 1.3.7.1.2
PI Parameter identifier Table II-1-71
Q1 Priority Table II-1-5, 1.3.4.1
Q2a to Q2 d Slot selection range constraint for level n Table II-1-5, 1.3.4.2
Q3 Replace queued data Table II-1-5, 1.3.4.3
Q4 Number of available slots Table II-1-5, 1.3.4.4
Q5 VSS re-transmission parameters Table II-1-5, 1.3.4.5
Q5min VSS re-transmission parameters — minimum Table II-1-5, 1.3.4.5
Q5max VSS re-transmission parameters — maximum Table II-1-5, 1.3.4.5
Q5mult VSS re-transmission parameters — multiplier Table II-1-5, 1.3.4.5
Q5exp VSS re-transmission parameters — exponent Table II-1-5, 1.3.4.5
Q5num VSS re-transmission parameters — number of attempts Table II-1-5, 1.3.4.5
Q5wait VSS re-transmission parameters — maximum number to wait for a Table II-1-5, 1.3.4.5
reply
TD1 ZOCOP link transmit reset timer Table II-1-58, 1.4.3.1
TD2 ZOCOP link receive reset timer Table II-1-58, 1.4.3.2
TL1 Maximum link overlap time Table II-1-93
TL2 Link initialization time Table II-1-93
TL3 Inter-miss timer Table II-1-93
TL5 Maximum delay for plea response Table II-1-111
TL6 Minimum time delay for CG1 filter Table II-1-111
TM2 Channel busy timer 1.3.7.1.1
TV11 Reservation hold time 1.3.10.2.1
TV11min Reservation hold timer minimum value 1.3.10.3.1
TV11max Reservation hold timer maximum value 1.3.10.3.1
TV61 Second frame block reservation time out 1.3.17.5.1
V11 Nominal periodic rate 1.3.10.3.2
V12 Periodic dither range 1.3.10.3.3
V21 Nominal incremental period Table II-1-22, 1.3.11.2.1
II-1-4 Manual on VHF Digital Link (VDL) Mode 4

V22 Maximum incremental dither range Table II-1-22, 1.3.11.2.2
V32 Minimum response delay Table II-1-28, 1.3.14.2.1
V33 Maximum response delay Table II-1-28, 1.3.14.2.2
V34 Source/destination control Table II-1-28, 1.3.14.2.3
V35 Broadcast control Table II-1-28, 1.3.14.2.4
V36 Length of reserved block Table II-1-28, 1.3.14.2.5
V42 Length of information transfer Table II-1-31, 1.3.15.2.1
V43 Minimum information transfer delay Table II-1-31, 1.3.15.2.2
V44 Maximum information transfer delay Table II-1-31, 1.3.15.2.3
V46 Maximum response delay Table II-1-31, 1.3.15.2.5
V61 Superframe block start offset Table II-1-44, 1.3.17.3.1
V62 Superframe block length Table II-1-44, 1.3.17.3.2
V63 Superframe block repeat rate Table II-1-44, 1.3.17.3.3
V64 Superframe block rebroadcast request Table II-1-44, 1.3.17.3.4
V65 Superframe block rebroadcast offset Table II-1-44, 1.3.17.3.5
V66 Second frame block size 1.3.17.5.2
V67 Second frame block repeat rate 1.3.17.5.3
VS1 Number of ground quarantined slots Table II-1-9, 1.3.3.1
VS2 Minimum co-channel interference (CCI) performance Table II-1-9, 1.3.3.2
VS3 Maximum number of access attempts 1.3.7.1.3
VS4 Quarantine slot reuse range Table II-1-9, 1.3.3.3
VS5 Maximum burst length Table II-1-9, 1.3.3.4
1.1.3.4 Subfields and variables
The symbols for subfields and variables used in Chapter 1 are in Table II-1-2.
Table II-1-2. Symbols and variables for link layer protocols and services

a application Table II-1-106
A bits Mobile ID subfield 1.5.3.5.13
ai additional service information Table II-1-106
aj Additional slot j Table II-1-35
a/d Autonomous/directed flag 1.3.2.6, 1.5.5.1, Table II-1-8
anum application number Table II-1-106
ao Acknowledgement offset Table II-1-30

A_slot Acknowledgement slot 1.3.15.4.3
balt Base altitude Table II-1-65
bd Backoff delay Table II-1-53
b/g Baro/geo altitude Table II-1-65
bl Burst length 1.3.5
blg Block length Table II-1-41
bo Block offset Table II-1-41
br Block repeat rate Table II-1-41
bs Block start Table II-1-41
bt Block time out Table II-1-41
C bits Rejection cause code
c/r Command/response status bit Table II-1-75
cprf CPR format even/odd Table II-1-65
ct_slot Current transmission slot 1.3.10.5.2
d Destination address Table II-1-27
D bits Backoff delay time
da Data age Table II-1-65
do Directed offset Table II-1-35
dt Directed time out Table II-1-35
ent Entry number Table II-1-106
eo Easterly offset parameter 1.5.3.6.5
erid Extended reservation ID Table II-1-7
err Error type Table II-1-53
f Frequency Table II-1-30
ft_slot Future transmission slot 1.3.10.5.6
GSC Global Signalling Channel (GSC) flag Table II-1-106
ho handoff 1.5.3.3.2
IB Initialize bit 1.4.2.3.7
Id Information field identity Table II-1-65
id1, id2, id3… ID extension Table II-1-65
idn ID extension
in Information field 1.3.2.4, 1.4.2.2.1, Table II-1-65
io Incremental offset Table II-1-21
lat Latitude Table II-1-65
lg Length Table II-1-27
lon Longitude Table II-1-65
M More bit 1.4.2.3.4
M bits Modulation subfield
m2 Measure of the uncertainty of the reservation data 1.2.2.2

mi Message ID 1.3.2.3
nd Negative dither Table II-1-25
neg Negotiation subfield 1.4.2.3.8
no Northerly offset parameter 1.5.3.6.5, Table II-1-104
nr Nominal update rate Table II-1-33
N_slot Nominal slot 1.3.10.5.1
nic Navigational integrity category Table II-1-65
off Offset to first reserved slot Table II-1-35
ok Confirm/failure flag Table II-1-53
or Override flag Table II-1-35
po Periodic offset 1.3.6.4.2, Table II-1-17
pr Priority Table II-1-26
Pr_flag Plea response flag 1.3.16.1
prm VSS user specific parameter Table II-1-51
pt Periodic time out Table II-1-17, 1.3.6.4.2
rcvr Receiver control Table II-1-35
rd Reservation data Table II-1-5
re Response expected Table II-1-75
res Reserved bit Table II-1-53
rid Reservation ID 1.3.2.5
r-id Requested information field 1.5.5.1.1
r-mi Requested message ID Table II-1-6, Table II-1-51
ro Response offset Table II-1-27
roff Rebroadcast offset Table II-1-41
rrr CTRL re-transmission number 1.5.3.3.3
R_slot Reserved slot 1.3.11.4.2
retrans Number of times that a burst has been transmitted 1.3.21
S Source address 1.3.2.2
sss CTRL sequence number 1.5.3.3.3
s_avail Slot availability 1.3.10.5.3
sdf Source/destination flag Table II-1-27
si Service information Table II-1-106
sit Service information type Table II-1-106
sz Size Table II-1-43
T Toggle bit 1.4.2.3.3
Tt Value of Toggle bit for (current) transmitted DLPDUs 1.4.2.1
Tr Value of Toggle bit for last received DLPDU 1.4.2.1
tqc TCP change flag/SVQ Table II-1-65
tfom Time figure of merit Table II-1-65

trmt Transmit control Table II-1-35
t_slot Transmission slot 1.3.11.4.1
ucid UCTRL ID 3.7.2.1.2
udid UDATA ID Table II-1-57h
uinf UINFO ID Table II-1-57i
vc Vertex count Table II-1-31
Ver Version number 1.3.2.1
vt Time out Table II-1-43
Note 1.— Unless otherwise stated, all division operations shall be integer divisions. An implied truncation shall
occur after the division.
Note 2.— In the tables included in this document to illustrate the format of bursts, the following order is implied:
a) Bit order in each burst subfield shall be indicated by subscript numbers. Bit 1 shall indicate the least
significant bit; and
b) Bits shall be transmitted octet by octet, starting with the first octet in each table, and within each octet, the
rightmost bit (as shown in the tables) shall be transmitted first.
1.2 MEDIA ACCESS CONTROL (MAC) SUB-LAYER
The MAC sub-layer shall acquire the shared communication path in order to provide the services defined in 1.2.1.
Note.— The functions performed by the MAC sub-layer should be “transparent” to higher functional layers.
1.2.1 MAC sub-layer services
1.2.1.1 The MAC sub-layer provides
a) TDMA media access;
b) time synchronization of the start of each time slot in the channel (1.2.3);
c) transmission processing (1.2.5); and
d ) received transmission processing (1.2.6).
1.2.1.2 The MAC sub-layer receives from the physical layer a continuous indication of slot idle/busy status and
signal level (see 1.2.4). It then receives from the VSS sub-layer a burst for transmission, accompanied by the time to
transmit the burst. The MAC sub-layer provides the VSS sub-layer the received burst data, slot busy/idle status, slot
occupancy status, signal level, and the status of the bursts sent for transmission.
1.2.2 MAC sub-layer parameters
The MAC service system parameters are described in Table II-1-3.
Table II-1-3. Media Access Control (MAC) service system parameters
Symbol Parameter Name Minimum Maximum Default Increment

M1 Number of slots per n/a n/a 4 500 slots n/a
superframe
M2_inc Filter increment for 1 slot 256 slots 2 slots 1 slot
receiver blocking check
M2_limit Filter threshold for 1 slot 65 536 slots 160 slots 1 slot
receiver blocking check
(network entry)
1.2.2.1 Parameter M1 (number of slots per superframe)
The parameter M1 is the number of available slots per superframe. A superframe spans a period of 60 seconds or 1
minute.
Note.— M1/60 slot spans a time interval of one second. The M1 increment forces M1/60 to be an integer. This
simplifies the protocol since a slot counter (or equivalent) can be started at the boundary between any two consecutive
UTC seconds.
1.2.2.2 Parameter M2_inc and M2_limit (MAC layer control parameters for network entry)
Note.— For a station that is able to make reservations on a channel as defined in 1.3.6.1, the m2 filter (measure of
the uncertainty of the reservation data) controls the need to execute a network entry procedure because of the
temporary loss of receiving function on the channel due to known co-site transmissions.
1.2.2.2.1 An m2 filter shall be maintained by a station for each active channel as a measure of the uncertainty of
the reservation data. Each m2 filter is controlled by parameters M2_inc and M2_limit, which, in turn, define the
parameters of the following algorithm in which m2 is updated after every slot:
m2k+1 = m2k + M2_inc if receiver function on the channel is blocked by the transmission
of the same station on the same channel (e.g. through a common
antenna)
m2k+1 = max[(m2k − 1), 0] if receiver function is not blocked
1.2.2.2.2 If m2 M2_limit, m2 shall be reset to zero (m2 = 0) and the station shall execute a network entry
procedure.
Note.— The objective of parameters M2_inc and M2_limit is to force re-entry when the reservation table may have
been corrupted by a lack of recent reservation data, but not requiring re-entry due to minor gaps in reception that may
have been caused by limited and isolated transmissions on other channels. Parameters M2_limit and M2_inc can be
reset by ground station command on a per channel basis.
1.2.3 Time synchronization
Time synchronization is described in Table II-1-4.
Table II-1-4. Operating modes and time synchronization
Operating mode Synchronization mode Data quality level Synchronization

Normal Primary Certified UTC
Primary Non-certified UTC
Failure Secondary Non-certified UTC
Tertiary Non-certified Non-UTC
1.2.3.1 Primary synchronization mode
Under normal operating conditions, a station shall maintain time synchronization such that the start of each successive
group of M1/60 slots is synchronized with the start of any UTC second to within a 2-sigma value of 400 ns. This is also
defined as the primary time source.
1.2.3.2 Secondary synchronization mode
A station shall be capable of maintaining time synchronization such that the start of each successive group of M1/60
slots is synchronized with the start of any UTC second to within a 2-sigma value of 15 µs. This is also defined as the
secondary time source.
Note 1.— One method of obtaining secondary synchronization mode is to synchronize to the slot boundaries that
are defined by a station declaring primary time.
Note 2. —Secondary time is used only when the primary source has failed. A station using secondary time shall
however revert to primary time whenever primary time is available.
Note 3.— Secondary time is regarded as a failure mode.
1.2.3.3 Alignment to UTC second
For stations maintaining primary or secondary time, the start of each successive group of M1/60 slots shall be aligned
with a UTC second.
1.2.3.4 Tertiary synchronization mode
1.2.3.4.1 A station shall be capable of maintaining time synchronization to an estimate of the mean slot start
times of a set of stations to within a 2-sigma value of 20 µs. This is defined as the tertiary time source.
1.2.3.4.2 When a mixture of secondary and tertiary time sources is available, the station shall derive time from
the secondary time source(s) and exclude the tertiary time source(s).
Note 1. — Tertiary time is used only when both the primary and secondary sources have failed.
Note 2. — A station using tertiary time shall:
a) revert to primary time whenever primary time is available, or
b) revert to secondary time whenever secondary time is available and primary time is not available.
Note 3.— Tertiary time is regarded as a failure mode.
1.2.3.5 Data quality level
1.2.3.5.1 The certified data quality level shall indicate that timing and position information provided by the
station declaring primary time can be used by other stations as a means of deriving their own position information.
1.2.3.5.2 When a station is deriving position information from the transmissions of other stations, it shall only
use data from stations that have declared the certified data quality level.
1.2.3.5.3 There is no need to indicate the certified data quality for secondary and tertiary timing levels.
Note.— The certification of stations for use as “pseudolites” in order to support secondary navigation will be
under the control of an authority, such as the civil aviation administration.
1.2.4 Slot idle/busy notification
1.2.4.1 Slot idle detection
A station shall consider a slot to be idle if the slot idle/busy status is idle at the start of the slot. (See Annex 10 —
Aeronautical Telecommunications, Volume 3, Part I — Digital Data Communication Systems, Chapter 6)
1.2.4.2 Slot busy detection
A station shall consider a slot to be busy if the slot idle/busy status is busy at the start of the slot. (See Annex 10 —
Aeronautical Telecommunications, Volume 3, Part I — Digital Data Communication Systems, Chapter 6)
1.2.4.3 Slot occupied detection
A slot shall be considered to be occupied if the slot is continuously busy for a period of at least 5 milliseconds during
the slot.
Note.— The slot occupied detection is used to monitor the operations of peer stations and to provide an indication
that there might be transmissions in a slot even if those transmissions cannot be decoded by the MAC layer. This is
different from the slot idle/busy state, which affects in part the station’s ability to make a random transmission.
1.2.4.4 Signal level indication
The MAC sub-layer shall accept from the physical layer an indication of the signal strength.
Note.— The signal level indication is used in the periodic broadcast protocol as defined in 1.3.10.5.2. The
measurement is for relative purposes only and need not be calibrated to any standard.
1.2.5 Transmission processing
1.2.5.1 Bursts received from the MAC sub-layer shall be forwarded to the physical layer, along with the time for
transmission.
1.2.5.2 With the exception of certain delayed bursts, a station shall begin transmissions only at the beginning of
the slot boundary as determined by its local clock. Delayed bursts shall begin 4 milliseconds after the start of the slot
boundary, if the slot is idle at that point.
Note.— The delay allows time for other stations to begin transmitter ramp up, for the signal to travel the
propagation distance, and for the slot busy detector to determine the appearance of a signal. A delayed burst can fit in
a single slot and thus preserve nominal propagation guard time, even if transmission begins late. The delay may be
somewhat shorter but not longer; the 4 millisecond-value is selected to ease design and ensure robustness of the slot
busy detector.
1.2.6 Received transmission processing
Bursts with an invalid cyclic redundancy code (CRC) shall be discarded. Bursts with valid CRCs shall be forwarded to
the VSS sub-layer, along with the received time of transmission and the signal quality parameters.
1.3 VDL MODE 4 SPECIFIC SERVICES (VSS) SUB-LAYER
Note 1.— There is one VSS sub-layer entity for each VDL Mode 4 channel that is accessed by the station. The VSS
sub-layer provides service to the VDL Mode 4 management entity (VME) as well as to the LME associated with other
VDL Mode 4 peer systems, their associated Data Link Entities (DLEs) and the DLS. The VSS is served by the MAC that
is associated with its particular VDL Mode 4 channel.
Note 2.— This section describes the services provided by bursts as well as some sample protocols and procedures
which may be amended, extended, or ignored by any specific burst application.
Note 3.— Other protocols may be defined for unique applications; however, it is expected that most bursts will use
one of the protocols in 1.3.1.1. It should be noted that the various reservation fields cannot be redefined for the
protocols in 1.3.1.1.
1.3.1 Services
1.3.1.1 Multiple access
The VSS sub-layer implements protocols that enable all stations to transmit while at the same time maintaining high
system throughput, low transit delays and low probability of collisions. These protocols include:
a) reserved access (see 1.3.6):
1) null reservation (see 1.3.9);

2) periodic broadcast (see 1.3.10);
3) incremental broadcast (see 1.3.11);
4) combined periodic broadcast and incremental broadcast (see 1.3.12);
5) big negative dither (BND) broadcast (see 1.3.13);
6) unicast request (see 1.3.14);
7) information transfer request (see 1.3.15);
8) directed request (see 1.3.16);
9) block reservation (see 1.3.17);
10) response (see 1.3.18).
b) random access (see 1.3.7); and
c) fixed access (see 1.3.8).
Note.— The designation of “reserved access”, “random access” and “fixed access” apply to the protocols in the
transmitting station, but not to any message indicator or flag in the transmitted frame or burst.
1.3.1.2 Error detection
The VSS sub-layer shall compute a 16-bit CRC according to ISO (International Standardization Organization) 3309 to
facilitate detection by the MAC sub-layer of other peer stations of data corruption during transmission (see 1.2.6).
1.3.1.3 Channel congestion
The VSS sub-layer shall notify the LME sub-layer whenever channel congestion is detected (see 1.3.7.1.1).
1.3.2 Burst format
VSS bursts shall conform to ISO 3309 frame structure except as specified in Table II-1-5.
Note 1.— The maximum burst length is defined in 1.3.3.4.
Note 2.— A burst occupying a single slot has 24 octets (n) of data. Thus, in assigning 8 bits (1 octet) for bit stuffing
and 2 octets for the flags, a maximum single-slot burst has a remaining value of n = 21. Note that a burst can take a
maximum burst length of up to VS5 (maximum burst length) as specified in Table II-1-9. Bursts can consist of a single
block of data between two flags (as illustrated in Table II-1-5) or they can consist of a number of blocks of data, with
each block separated from the next by a flag. Bit stuffing is the addition of a small number of non-information bits to a
transmission packet in order to help synchronize signalling rates between receiving and transmitting ends of a network.
When the data stream sent contains several adjacent 0’s or adjacent 1’s, there is no transition of the signal and the
receiver cannot adjust its clock to maintain proper synchronized reception. To avoid this situation, when a pre-set
number of transitionless bits have been transmitted, the transmitter uses an algorithm to insert (or “stuff”) a non-
information bit. The receiver follows the same algorithm to remove this stuffed bit and returns the bit streams to their
original form.
Note 3.— Aeronautical Telecommunications Network (ATN) applications are supported by DLS bursts (see
1.4.2.3).
Note 4.— The lengths of the message ID (mi) and information (in) fields depend on the message type being used.
Note 5.— The lengths of the extended reservation ID (erid) and reservation data (rd) fields depend on the
reservation protocol being used. The rd field may also be subdivided into further fields, depending on the reservation
protocol.
1.3.2.1 Version number (ver)
The version number (ver) subfield shall indicate the version of VDL Mode 4 that is being supported by the station. It
shall be set to 000binary on TRANSMIT. (See Table II-1-5.) If the station receives a burst in which the version number
is non-zero (ver 0), it shall inform the VSS user that a non-zero version number has been received and ignore the rest
of the burst.
Note.— The three zeros in “000binary” represents the three bits of the version field. See Table II-1-5.
Table II-1-5. Burst format
Bit number
Flag — 0 1 1 1 1 1 1 0
Autonomous/directed flag (a/d), 1 s27 s26 s25 ver3 ver2 ver1 rid a/d
reservation ID (rid), version number
(ver)
Source address (s) 2 s24 s23 s22 s21 s20 s19 s18 s17
3 s16 s15 s14 s13 s12 s11 s10 s9
4 s8 s7 s6 s5 s4 s3 s2 s1
Message ID (mi) 5 mik ...... mi4 mi3 mi2 mi1
Information (in) 6 ink
7 to n − 5 ........
n−4
Reservation data (rd) n−3 in1 rdk ......
Extended reservation ID (erid) n−2 eridk ..... erid1 rd1
CRC (c) n−1 c9 c10 c11 c12 c13 c14 c15 c16
n c1 c2 c3 c4 c5 c6 c7 c8
Flag — 0 1 1 1 1 1 1 0
Note 1.— “n” is the burst length expressed in octets. See also Note 2 in 1.3.2.
Note 2.— . . . . . . . . denotes variable length field.

1.3.2.2 Source address (s)
The source address (s) of the transmitting station shall be encoded in the 27-bit field as described in Table II-1-5. The
address format is described in 1.4.2.2.
1.3.2.3 Message ID (mi)
1.3.2.3.1 The message ID (mi) of the burst shall be encoded in the variable length field as defined in Table II-1-5.
The first 4 bits of the burst mi field shall be as defined in Table II-1-6.
Table II-1-6. Message ID (mi) assignment
Message ID (mi) field Assigned burst type VSS user

mi8 mi7 mi6 mi5 mi4 mi3 mi2 mi1
x x x x x x x 0 Synchronization burst (see 1.5.2) LME
x x x x 1 1 0 1 DLS bursts (see 1.4.2.3) DLS
x x x x x 0 1 1
x x x x x 1 1 1
1 0 0 1 0 1 0 1
x x 1 0 0 1 0 1
x x x x x 0 0 1 General request burst Defined by
requested message
ID field (r-mi)
x 0 0 0 0 1 0 1 No operation VSS
x 0 1 1 0 1 0 1 Reserved for future use
x 1 0 1 0 1 0 1 Reserved for future use
x 1 1 1 0 1 0 1 General response burst Defined by r-mi
0 0 0 1 0 1 0 1 Message ID extension to next four bits
x 1 0 0 0 1 0 1 Network entry burst VSS
Note.— Bits denoted as" x" are available for use within the information field. “r-mi” is requested message ID field.
1.3.2.3.2 The message ID (mi) shall define the VSS user which is responsible for handling the message,
following completion of processing required within the VSS.
1.3.2.4 Information (in) field
The optional information (in) field shall contain VSS user-defined data.
Note.— The content of the information (in) field is generally a matter for definition by the applications using VDL
Mode 4. General request and general response message formats are specified in 1.3.19 and 1.3.20, respectively.
1.3.2.5 Reservation ID (rid) fields
The reservation ID (rid) of the burst shall be encoded in the 1-bit field as defined in Table II-1-5. If the rid = 1, this
shall indicate that the reservation type is either a null reservation (see 1.3.9), a periodic broadcast reservation
(see 1.3.10), or a combined periodic broadcast and incremental broadcast reservation (see 1.3.12) and that there is no
extended reservation ID (erid). Otherwise, the erid field shall indicate other reservation types as defined in Table II-1-7.
Note 1.— The rid (and erid, if present) subfield defines the interpretation of the reservation data (rd) field.
Note 2.— Bits denoted “x” are available for use within the reservation data (rd) field.
Table II-1-7. Extended reservation ID (erid) field
Extended reservation ID field

(erid)
Octet n − 2
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Reservation type
0 0 0 0 0 Response burst (no reservation)

0 0 0 0 1 Big negative dither (BND) reservation
0 0 0 1 0 Superframe block reservation
0 0 0 1 1 Second frame block reservation
0 0 1 0 x Unicast request reservation
0 0 1 1 0
To Reserved for future allocation
0 1 0 0 1
0 1 0 1 0 Information transfer request reservation
0 1 0 1 1 Reserved for future allocation
0 1 1 0 0 Directed request reservation
0 1 1 0 1
0 1 1 1 1
1 0 x x x Incremental broadcast reservation
1 1 0 0 0
1 1 1 1 1
Note 1.— The rid (and erid, if present) subfield defines the interpretation of the reservation data (rd) field.
Note 2.— Bits denoted “x” are available for use within the reservation data (rd) field.
1.3.2.6 Autonomous/directed flag (a/d)
1.3.2.6.1 The autonomous/directed (a/d) flag shall be encoded as defined in Table II-1-8.
1.3.2.6.2 The autonomous/directed (a/d) flag indicates if a station reserved the slot for itself, or if a peer made the
reservation for the station. The a/d bit shall be set to zero if a station is transmitting randomly in a slot reserved by
itself, or one if the station is transmitting a delayed burst or in a slot reserved for it by a peer.
Note.— A station transmitting a burst with an a/d bit set to zero implies that it has a valid reservation table. A
transmission by a mobile station that contains a periodic reservation and whose a/d bit is set to one will invoke the
quarantining procedures described in 1.3.6.4.
Table II-1-8. Autonomous/directed flag (a/d) encoding
Subfield Range Encoding Notes

Autonomous/dire Boolean 0 = random transmission or reserved transmission Identifies whether the station is
cted (a/d) in a slot selected by this station, transmitting based on its internal
1 = delayed burst transmission or reserved reservation table or if it is being
transmission in a slot selected by a peer station directed by a peer.
1.3.3 VSS sub-layer parameters
VSS service system parameters are described in Table II-1-9.
Table II-1-9. VDL Mode 4 specific services (VSS) sub-layer parameters
Symbol Parameter name Minimum Maximum GFSK default Increment

Number of ground
VS1 quarantined slots 0 slot 15 slots 4 slots 1 slot
Minimum co-channel
Interference (CCI)
VS2 performance P2 dB 60 dB 12 dB 1 dB
VS4 Quarantine slot reuse range 0 1 000 NM 300 NM 10 NM
VS5 Maximum burst length 1 slot 16 slots 10 slots 1 slot
Note.— P2 is defined in Annex 10 — Aeronautical Telecommunications, Volume III, Part I — Digital Data Communication
Systems, Chapter 6; GFSK refers to Gaussian-filtered Frequency Shift Keying.
1.3.3.1 Parameter VS1 (number of ground quarantined slots)
The parameter VS1 shall define the number of ground quarantined slots (see 1.3.6.4).
1.3.3.2 Parameter VS2 (minimum Co-channel Interference (CCI) performance)
The parameter VS2 is used to control the CCI conditions under which a station, Y, may transmit, given that another
station, X, has reserved the same slot. In the case where stations X and Y transmit in the same slot and station X's
transmission is directed to another station Z, CCI conditions shall be fulfilled (a transmission from station X will not
interfere with the transmissions from stations Y and Z) if the following inequality condition is true:
2
dist Y Z
10 log > VS 2
2
dist X Z
where “dist (Y/Z” is the distance between station Y and station Z and “dist (X/Z)” is the distance between station X and
station Z.
Note.— This condition is applied twice to establish that the transmission between aircraft A and C will not
interfere with the transmission between aircraft B and D (as described in Table II-1-12).
1.3.3.3 Parameter VS4 (quarantine slot reuse range)
The parameter VS4 is used to control the range in which a quarantined slot may be reused by a distant station (see
1.3.6.4).
1.3.3.4 Parameter VS5 (maximum burst length)
The parameter VS5 defines the maximum burst length in slots, including flags and zero bits that are inserted for
transparency.
1.3.4 VSS quality of service (QoS) parameters
Every burst processed by the VSS sub-layer for transmission is associated with the parameters defined in Table II-1-10.
Table II-1-10. VSS quality of service (QoS) system parameters

Q1 Priority 0 15 11 1
Q2a Slot selection range constraint for level 1 0 1 000 NM 150 NM 1 NM
Q2b Slot selection range constraint for level 2 0 1 000 NM 150 NM 1 NM
Q2c Slot selection range constraint for level 3 0 1 000 NM 0 NM 1 NM
Q2d Slot selection range constraint for level 4 0 1 000 NM 300 NM 1 NM
Q3 Replace queued data FALSE TRUE FALSE —
Q4 Number of available slots 1 20 3 1
Q5min minimum 0 sec 20 sec 0 sec 13.33
milliseconds
Q5max maximum 1 sec 20 sec 5 sec 13.33
milliseconds
Q5mult VSS re-transmission multiplier 1 sec 2.5 sec 1 sec 0.01 sec
Q5exp parameters exponent 1 2.5 1.5 0.01
Q5num number of 1 15 4 1
attempts
Q5wait maximum time to 1 sec 120 sec 60 sec 1 sec
wait for a reply
1.3.4.1 Parameter Q1 (priority)
The parameter Q1 shall be the priority of the transmission and is defined in Table II-1-11.
Table II-1-11. Priority levels
Message categories Q1
Network/systems management 14
Distress communications 13
Urgent communications 12
High priority flight safety messages 11
Normal priority flight safety messages 10
Meteorological communications 9
Flight regularity communications 8
Aeronautical information service messages 7
Network/systems administration 6
Aeronautical administrative messages 5
Unassigned 4
Urgent priority administrative and UN charter communications 3
High priority administrative and state/government communications 2
Normal priority administrative 1
Low priority administrative 0
Note.— This duplicates the ATN network priority numbering scheme. Q1 = 15 is reserved for future use.
1.3.4.2 Parameters Q2a to Q2d (slot selection range constraint for level n)
The parameters Q2a to Q2d is used to impose range constraints on the slot selection process for levels 1 to 4 as defined
by Table II-1-12.
1.3.4.3 Parameter Q3 (replace queued data)
The parameter Q3 shall be a Boolean switch that is used to control queuing of repeated bursts on a congested channel.
If Q3 = TRUE, then a new data field shall replace a queued data field of the same type. Otherwise, both the old and
new data fields shall be transmitted.
Note.— If a channel is busy and a synchronization burst containing ADS-B data cannot be transmitted, then a
second synchronization burst (although with potentially different data) will overwrite the first burst.
1.3.4.4 Parameter Q4 (number of available slots)
The parameter Q4 shall be used to control the number of slots added to the available slot list during the slot selection
process (see 1.3.6.2).
1.3.4.5 Parameters Q5 (VSS re-transmission parameters)
The parameters Q5min, Q5max, Q5mult, Q5exp, Q5num and Q5wait shall control the re-transmission of bursts for which an
expected response has not been received (see 1.3.21).
1.3.5 Received transmission processing
1.3.5.1 A station shall be capable of recognizing and processing all possible reservation types as defined in 1.3.9
through 1.3.18. When a station receives a burst with an unrecognized reservation type, it shall discard the burst without
updating the reservation table.
1.3.5.2 When a station receives a known reservation type with an invalid subfield or a known reservation type
with valid subfields but an invalid combination, it shall reserve the slots indicated by the valid subfields and not
transmit a response nor pass the burst to a VSS user.
1.3.5.3 When a station receives a burst with a known reservation type and a non-zero reserved subfield, it shall
ignore the data in the reserved subfield.
1.3.5.4 The current slot for a burst shall be the slot in which the received transmission begins. The burst length
(bl) shall be the number of slots across which the burst is transmitted.
Note.— Current slot and burst length (bl) are used throughout the text according to protocol definitions. In the
text, unless otherwise stated, references to particular slot numbers (e.g. for calculating the position of new
reservations) are relative to the current slot which is taken to be slot 0. If a transmission extends across a slot
boundary, it is considered to occupy the slots on both sides of the boundary for reservation purposes.
1.3.5.5 Valid bursts shall be forwarded to the appropriate VSS user, along with the time of receipt of the
transmission. The received signal quality (see Annex 10 — Aeronautical Telecommunications, Volume III, Part I —
Digital Data Communication System, Chapter 6, 6.9.5.1.5.1) and the time of receipt of the bursts shall be passed on to
the VME. If the appropriate VSS user cannot be identified (i.e. the message ID (mi) is reserved or that functionality is
not implemented) and the burst contains only one or more reservations for the receiving station, then the station shall
transmit a GENERAL FAILURE (see 1.3.20) with an error type (err) of 00 hex or 80 hex (i.e. unsupported function) in
the first slot of each of the reservations.
1.3.6 Reserved access protocol specification
Note.— Procedures for processing bursts that contain specific reservation types are described in 1.3.9 through
1.3.18.
1.3.6.1 Reservation table
1.3.6.1.1 A station shall maintain a table of all reservations in the next [4 • M1 + 128] slots. For each reserved
slot, the reservation table entry shall consist of the 27-bit address of the intended transmitter, the 27-bit address of the
destination (if any) and the type of reservation made. For periodic broadcast reservations (see 1.3.10) and directed
request reservations (see 1.3.16), the reservation table shall also include pointers to all other reserved slots associated
with the same reservation stream.
1.3.6.1.2 For the periodic broadcast protocol (see 1.3.10), the reservation table shall also record potential
reservations, defined as the M1, 2 • M1, 3 • M1 and 4 • M1 slots after a slot for which no transmission has been decoded
by the MAC layer. For each potential reservation, the reservation table shall include the signal level (see 1.2.4.4)
associated with the slot and the occupancy status as defined in 1.2.4.3. Slots containing both potential reservations and
reservations resulting from decoded transmissions shall be treated as if containing reservations from the decoded
transmissions only.
Note.— Since the slot is treated as though only containing a decoded transmission, any potential reservations in
subsequent superframes are effectively erased.
1.3.6.1.3 The reservation table shall be updated before the end of the first slot after the end of the burst.
1.3.6.1.4 With the exception of delayed bursts (see 1.1.3, 1.2.5, 1.5.5.3.3.1.1 and 1.5.5.3.4.1), and in cases where
station A has been directed to transmit by station B, station A shall listen to a channel for at least M1+128 slots before
starting to transmit or to reserve slots.
Note 1.— This listening period allows for sufficient time to build up the reservation table data.
Note 2.— A reservation table is for specification purposes only and the implementer is free to choose the method
used to store and process reservation information. A station is required to record all reservations for a slot for possible
use in slot selection algorithms because several stations may intentionally share a slot.
Note 3.— There may be more than one reservation associated with a particular slot.
Note 4.— Potential reservations are associated with any slot for which the MAC has failed to decode a received
transmission. Although this implies that such slots may contain a reservation that was not decoded, the slot occupancy
algorithm(see 1.2.4.3) will mark some of these slots as “likely occupied” and others as “likely unoccupied”. The
periodic reservation protocol (see 1.3.10) deals differently with these two classes giving initial priority to potential
reservations associated with unoccupied slots.
1.3.6.2 Selecting slots for transmission or reservation
A station shall select slots for transmission or reserve them for later transmissions by using the algorithm specified in
1.3.6.2.1 to 1.3.6.2.6.
Note.— When the channel is lightly to moderately loaded, the station will be able to select unreserved slots for
transmission (level 0 in Table II-1-12). When the channel is congested, the station is able to use slots that have been
reserved by other stations by applying rules defined in levels 1 to 4 in Table II-1-12.
1.3.6.2.1 Specification of candidate slots
The VSS user shall specify one or more ranges of candidate slots for slot selection. To achieve this, it shall specify one
or more groups of QoS parameters (i.e. Q1, Q2a, Q2b, Q2c, Q2d and Q4) for slot selection. The station shall then
attempt to select slots by using the first group of QoS parameters. If slot selection is unsuccessful, the station shall use
the next group and continue with successive groups until a slot has been selected. If no slot is selected after having used
up all groups of QoS parameters, the VSS user shall be informed that slot selection has been unsuccessful.
Note 1.— The method for specifying candidate slots is protocol dependent (see 1.3.9 to 1.3.18).
Note 2.— In addition to slots excluded because of ground quarantine (see 1.3.6.4.1), the VSS user can also specify
other slots that should be excluded for the purposes of slot selection. Such slots might be slots that are potentially
reserved (see 1.2.4.3) or which the VSS user does not wish to be used at all for slot selection.
1.3.6.2.2 Derivation of a list of available slots
1.3.6.2.2.1 Slot selection criteria
A list of available slots shall be chosen from the candidate slots by applying the following rules:
a) all unreserved slots shall be added to the list of available slots (shown as level 0 in Table II-1-12).
b) if, having completed stage a), the number of available slots is still less than Q4, further available slots shall be
selected from slots that have been previously reserved by other stations.
c) The station shall initially select from slots which conform to conditions specified as level 1 in Table II-1-12
until Q4 available slots have been chosen.
d) If, having applied level 1 conditions, the number of available slots is still less than Q4, slot selection shall
continue by applying level 2 conditions.
e) The process shall continue by applying subsequent levels until Q4 slots have been selected or until all levels
have been applied.
f) At each level, selection shall start with slots reserved by the most distant station and proceed in decreasing
range order.
Table II-1-12. Slot selection criteria
Selection conditions
Selection Planned transmission Previously reserved transmission Minimum distance between

priority by station A by station B station A and station B
Level 0 Any Unreserved Not applicable
Level 1 Broadcast or CCI-protected CCI-protected communication with Q2a
communication with station C station D
Level 2 Broadcast or CCI-protected Broadcast Q2b
communication with station C
Level 3 Broadcast or CCI-protected Broadcast or CCI-protected Q2c
communication with station C communication with station D
Level 4 Broadcast or CCI-protected Any transmission Q2d
communication with station C
Note 1.— In Table II-1-12, the following definitions and specifications shall apply:
Station A The station attempting to select a slot.

Station B A station that has previously reserved a slot.
Station C A station to which station A wishes to address a point-to-point communication.
Station D A station for which station B has reserved a slot for point-to-point communication.
CCI-protected A point-to-point communication between two stations which fulfils the CCI conditions as
communication defined in 1.3.3.2 and is therefore protected (its transmission can be heard by the intended
recipient) if a third station simultaneously transmits in the same slot.
Note 2.— The decision criterion in Table II-1-12 is the distance between station A and station B. However, the
requirement to check for CCI-protected communications at any given priority level requires station A to also examine
the distance relationship between station B and station C, between station A and station C, between station B and
station D, and between station A and station D, as appropriate. It is possible to disable the selection process at any of
the levels in Table II-1-12 by setting the appropriate range constraint (Q2a to Q2d) to the largest possible value of
1 000 NM (see Table II-1-10).
Note 3.— For certain applications, Q2d could be set to zero (Q2d = 0) so that a slot can always be chosen even if
this is at the expense of another application.
1.3.6.2.2.2 Recommendations
1.3.6.2.2.2.1 In selecting the list of available slots put on the desired transmit channel at level 0, priority should
be given to candidate slots which are not reserved for transmission on any channel monitored by the station, and which
also do not violate the quarantine constraints (see 1.3.6.4) on the desired transmit channel.
1.3.6.2.2.2.2 A mobile station should exclude from consideration any slots which have been previously reserved
for a point-to-point transmission, on any channel.
1.3.6.2.2.3 Additional considerations for slot selection for transmission
When selecting the list of available slots for transmission in a channel for mobile station A or for another mobile station
B, station A shall exclude from consideration the specific slots which it knows are reserved for transmission for the
intended station (either A or B) on other channels monitored by station A.
Note 1.— It is assumed that ground stations will have the capability to transmit on all the active channels in the
region they serve. However, mobile stations, especially with a single transmitter, will not be able to transmit in the
same slot on different channels.
Note 2.— If the selecting station is a ground station, then the station can select a conflicting slot if the ground
station expects to override the existing reservation. Procedures to resolve transmission conflict for mobile stations are
described in 1.3.6.6
1.3.6.2.3 Additional constraints applying to Global Signalling Channels (GSCs)
On channels designated as GSCs (see Annex 10 — Aeronautical Telecommunications, Volume III, Part I - Digital
Data Communication System, Chapter 6, 6.9.2.2.1), mobile stations maintaining primary or secondary time shall
exclude the first V66 (see 1.3.17.5.2) slots of every UTC second. The first V66 slots after every UTC second shall
comprise the Virtual Link Management Channel (VLMC) and shall be allocated for ground station use only.
1.3.6.2.4 Selection of slots from available slots
If, having completed the derivation of a list of available slots, the number of available slots is zero, no slot shall be
selected and the VSS user shall be informed that slot selection was unsuccessful. If the number of available slots is
greater than or equal to one, a slot shall be chosen from the list of available slots such that the probability of choosing a
given slot is the same as the probability of choosing any other slot.
1.3.6.2.5 Selection of slots for burst lengths (bl) greater than one (bl > 1)
For burst lengths (bl) greater than one (bl > 1), the process specified in 1.3.6.2.2 shall be applied to continuous blocks
of slots of length equal to the burst length. A block of slots shall be regarded as available at a particular level number
(see Table II-1-12) if all slots within the block are available at the same or lower level number. The procedure
described in 1.3.6.2.4 shall then be used to select one of the available blocks.
1.3.6.2.6 Limits on selection of reserved slots
A station which has selected a slot that was reserved by another station shall not select another slot reserved by that
station within [M1 − 1] slots after the selected slot.
1.3.6.3 Reserved transmissions
When a station has a burst to transmit for which it has a reservation, it shall transmit the scheduled data in the reserved
slots, except as noted in 1.3.6.3.1 and 1.3.6.3.2.
1.3.6.3.1 Unavailable data
If the data for a burst for which a slot was reserved is unavailable when it is time to transmit, then the station shall send
a GENERAL FAILURE (see 1.3.20).
1.3.6.3.2 Reservation no longer valid
A station shall check that a reservation is valid according to the procedures outlined in 1.3.6.5 before making a
transmission.
1.3.6.4 Ground quarantine
1.3.6.4.1 Establishment of ground quarantine
With the exception of a delayed burst (see 1.2.5), mobile station A shall not reserve a slot or transmit on the slot
boundary of the VS1 slots that follows a slot which has been reserved by ground station B using a periodic broadcast
reservation (see 1.3.10) or which has been reserved by mobile station C using a burst with the autonomous/directed (a/d)
bit set to one (a/d = 1) (see 1.3.2.6) and a periodic broadcast reservation field, unless the station (B or C) that has
reserved the slot is at a range greater than VS4 from station A. In the case that station (B or C) that has reserved the slot
is at a range greater than VS4 from station A, then station A should consider the slot to be unreserved.
Note 1.— The periodic broadcast reservation will be used to place a reservation for subsequent transmissions by
the ground station. The directed request reservation will be used to reserve slots for broadcast by mobile stations and
these mobile stations will subsequently use periodic broadcast reservations and directed bursts to maintain the directed
reservation (see 1.3.16.5).
Note 2.— Quarantine as defined in 1.3.6.4.1 does not apply to a delayed burst. If no normal transmission is
detected (i.e. no transmission starting on the slot boundary), the slot may be used for a delayed burst regardless of its
perceived quarantine status. This is to allow the ground system to provide opportunities for network entry unimpeded
by other traffic. However, it should be noted that delayed bursts must not be made when ground quarantine is
established by using a block message (see 1.3.6.4.3).
1.3.6.4.2 Maintenance of ground quarantine after cancellation of a directed request broadcast
If a station receives a periodic broadcast burst with the periodic offset (po) subfield set to zero (po = 0) and the periodic
time out (pt) subfield set to zero (pt = 0) (see 1.3.10.5.9), then the station shall maintain ground quarantine as described
in 1.3.6.4.1 for the current slot and for M1 slots after the current slot, on condition that the station has previously had a
reservation associated with the same stream (see 1.3.10.4). Ground quarantine behaviour for any other slots associated
with the same stream shall be cancelled.
Note.— This procedure applies to the cancellation of a stream that was set up using a directed request and also to
the cancellation of the periodic broadcast stream of a ground station.
1.3.6.4.3 Ground quarantine established by block message
A mobile station, A, shall not reserve a slot or transmit in slots which have been reserved by a ground station, B, or by
another mobile station, C, that uses a block reservation (see 1.3.17), unless the station (B or C) that has reserved the slot
is at a range greater than VS4 from station A. In this case, mobile station A shall consider the slot to be unreserved.
Note.— It is not possible to transmit a delayed burst in a reserved block.
1.3.6.5 Reservation conflicts
Note.— The following rules determine the action that a station takes in the event that a reservation conflict is
detected. This is a normal event which is expected to occur as a result of slot reuse under CCI protection. In the event
of a conflict, the slot selection criteria are generally reapplied to determine whether the slot could still have been
selected in the knowledge of the new conflicting reservation. Generally, a station required to transmit in a slot that was
reserved for it by another station will always transmit, since it cannot be assumed to have possession of the necessary
information to determine the optimum action.
If a station, A, receives a burst containing a reservation from another station, B, for a slot which has already been
reserved for station A to transmit, then station A shall take the following action:
a) if the conflicting reservation from station B also requires station A to transmit, then station A shall transmit
(i) the response with the higher priority (as determined by Q1), or
(ii) the first requested transmission in the case of equal priority, or else;
b) if station A no longer needs to transmit in the existing reservation or does not have the necessary information
to transfer, then it shall not transmit in the slot;
c) if the existing reservation for station A to transmit was made by a station other than station A (i.e. by a unicast
request where source/destination flag = 0, by information transfer, or by directed request reservation), then
station A shall transmit in the slot in accordance with the existing reservation;
d) if the existing reservation for station A to transmit was made by station A itself, then station A shall apply the
procedure described in 1.3.6.2.2 to determine whether, knowing of the reservation made by station B and
using the same values of Q2 and other parameters as originally used to select the slot, the slot is available at
any level 1, 2, 3 or 4. If the slot is determined to be available by this process, then station A shall transmit
according to its existing reservation. If the slot is no longer available, the actions specified in Table II-1-13
shall be performed.
Table II-1-13. Action in the event of reservation conflict
Protocol for station A’s existing Protocol for station B’s

reservation (made by station A) conflicting reservation Action by station A
Slots reserved by station A using Any protocol Transmit according to existing reservation.
ground quarantine (see 1.3.6.4)
Periodic broadcast Incremental broadcast, BND Transmit according to existing reservation.
unicast request, or information
transfer
Periodic broadcast Periodic broadcast If the conflict occurs later than station A’s next
(autonomous/directed), directed transmission in the stream, then select a new
request, and slots reserved by transmission slot and reduce the value of TV11
ground quarantine (see 1.3.6.4) (reservation hold time) so as to cause the stream to
dither to the new slot prior to the conflict.
Otherwise, set TV11 equal to 1 (TV11=1) so that
A’s next transmission causes the stream to dither to
a different slot in the next superframe after the
superframe in which the conflict first occurs
Incremental broadcast or BND Any protocol Do not transmit in the existing reservation. Make
the transmission in an alternative slot by random
access (1.3.7).
Unicast request (sdf = 1), or Any protocol Do not transmit in the existing reservation. Apply
information transfer the re-transmission procedures (1.3.21).
1.3.6.6 Transmission conflicts for mobile stations
Note.— The following rules describe the action that a mobile station will take when it detects a request for it to
transmit simultaneously in the same slot on different channels.
If a mobile station is requested to transmit in the same slot on different channels, then the station shall take the
following action:
a) If there is only one transmission with the highest priority among the required transmissions, then the station
shall transmit this highest priority transmission.
b) If there is only one ground-initiated transmission among the transmissions with the same highest priority, then
the station shall transmit this ground-initiated transmission.
c) If there is more than one ground-initiated transmission among the transmissions with the same highest priority,
then the station shall transmit the last requested of these ground-initiated transmissions.
d) If there are no ground-initiated transmissions among the transmissions with the same highest priority, then the
station shall transmit the first requested transmission.
1.3.7 Random access protocol specification
The station shall implement a non-adaptive p-persistent algorithm to allow all stations equal opportunity to transmit
while maximizing system throughput, minimizing transit delays, and minimizing collisions.
Note.— Transmissions which use the random access procedures may be used to place reservations for future
transmissions that also use the reserved access procedures (1.3.6) or they may be “one-off” transmissions which place
no reservations and which will conform to either the null reservation burst format (1.3.9.1) or the response protocol
burst format (1.3.18.1)
1.3.7.1 Random access parameters
The random access protocol shall implement the system parameters defined in Table II-1-14.
Table II-1-14. Random access VSS system parameters
Symbol Parameter name Minimum Maximum Recommended default Increment

TM2 Channel busy timer 25 slots 9 000 slots 1 500 slots 20 slots
p Persistence 1/256 1 64/256 1/256
VS3 Maximum number of 1 65 535 24 1
access attempts
1.3.7.1.1 Timer TM2 (channel busy timer)
Timer TM2 indicates the number of slots (TM2) that a sub-layer has to wait for after receiving a request to transmit.
This timer shall be started (if it is not already running) when the VSS sub-layer receives a request for random
transmission. After a successful random transmission access attempt, the timer shall be cleared if the random transmit
queue is empty and reset if it is not empty. When the timer expires, the VSS user shall be informed that the channel is
congested.
1.3.7.1.2 Parameter p (persistence)
Parameter p (persistence) shall be the probability that the station will transmit any random access attempt.
1.3.7.1.3 Counter VS3 (maximum number of access attempts)
Counter VS3 shall be used to limit the maximum number of random access attempts (VS3) that a station will make for
any transmission request. This counter shall be cleared upon system initialization, expiration of timer TM2, or a
successful access attempt. The counter shall be incremented after every unsuccessful random access attempt. When the
counter reaches the maximum number of random access attempts, authorization to transmit shall be granted as soon as
the channel is available.
1.3.7.2 Random access procedures
1.3.7.2.1 Random access procedures for transmissions starting on a slot boundary
1.3.7.2.1.1 When the station has one or more bursts to transmit for which it does not have a reservation, it shall
use the p-persistent algorithm as defined as follows:
a) access attempts shall only be made and transmission shall only begin on a slot boundary of available slots. A
station shall regard a slot or block of slots as available for a random transmission if the slot or block of slots
conforms to the criteria of any of levels 0 through 2 in Table II-1-12, using default or VSS user-supplied QoS
parameters; and
b) transmission shall not begin if the station has not previously made or received a reservation for the prior slot,
and the slot is busy as defined in 1.2.4 at the slot boundary.
1.3.7.2.1.2 If the station is unable to select a slot, this shall be regarded as an unsuccessful random access
attempt.
1.3.7.2.1.3 If the station is able to select a slot, then the station shall transmit on the slot boundary with
probability p (as defined in 1.3.7.1.2).
Note.— Consider the case where a station intends to apply a p-persistent algorithm for random transmission at the
start of slot k. If the prior slot [k−1] is reserved and slot k is unreserved or effectively unreserved, the station may be
confident that the transmission in slot [k−1] will terminate and garble will not occur. However, if slot [k−1] is
unreserved (according to the reservation table of the station) but nonetheless busy, the station has no way of knowing
whether the transmission will terminate or continue. So in this case, a physical layer measurement is necessary to
ensure that the transmission has terminated. Since the measurement process takes finite time, an apparently unreserved
transmission which ends close to the end of slot [k−1] may forestall a random transmission in slot k. This is
unavoidable.
1.3.7.2.2 Random access procedures for delayed transmissions
1.3.7.2.2.1 Delayed transmissions shall use a p-persistent algorithm defined as follows:
a) transmissions shall be delayed relative to the slot boundary in accordance with 1.2.5; and
b) a station shall not start a transmission if the channel idle/busy status (see Annex 10 — Aeronautical
Telecommunications, Volume III, Part I — Digital Data Communication System, Chapter 6, 6.9.5.3) is busy at
the intended (delayed) start time.
1.3.7.2.2.2 If the station is unable to select a slot, this shall be regarded as an unsuccessful random access
attempt.
1.3.7.2.2.3 If the station is able to select a slot, then the station shall transmit on the slot boundary with
probability p (as defined in 1.3.7.1.2).
1.3.7.2.3 Recommendations
1.3.7.2.3.1 Whenever possible, a station should use the reserved access protocols described in 1.3.6 to reserve
slots for new transmissions by adding reservation fields to transmissions for which slots have already been reserved.
The random access protocol should be used only if there is no suitable opportunity to reserve a slot.
1.3.7.2.3.2 Whenever possible and if there has been no previous reservation, a ground station should use ground
quarantined slots (see 1.3.6.4) for transmission. The random access protocol should be used only if there is no suitable
opportunity to use ground quarantined slots.
1.3.7.2.4 Transmit queue management
There shall be a single queue for all random transmissions which do not have reserved slots for transmission. This
queue shall be sorted in order of priority, with a higher value of Q1 being transmitted before a lower value of Q1. If Q3
is TRUE, then the queue shall be searched to determine if a burst of the same type has been queued.
1.3.8 Fixed access protocol specification
It should be possible to pre-programme a ground station so that it can either not transmit in certain slots with times
expressed in UTC or it can transmit specific transmissions in specific slots with starting times expressed in UTC
(without necessarily announcing a reservation).
1.3.8.1 Recommendation
The user should specify the use of an appropriate reservation protocol in order to protect future fixed transmissions.
Note 1.— The user will be able to specify a time or slot for a particular transmission and can also specify a
reservation protocol to protect the next fixed transmission. For example, the user could specify a certain ground
transmission at a certain time and then specify the use of the periodic reservation block to reserve the same slot in the
next minute.
Note 2.— The ground infrastructure service provider is able to use this fixed access protocol and the superframe
block reservation protocol (see 1.3.17.7.1) in order to organize a series of coordinated reserved slots for ground
transmissions.
1.3.9 Null reservation protocol specification
1.3.9.1 Null reservation burst format
A reservation ID (rid) = 1 and a reservation data (rd) field in accordance with Table II-1-15 shall indicate a null
reservation. In this case, the information (in) field shall be extended up to the last 10 bits prior to the CRC.
Table II-1-15. Null reservation bit encoding
Bit number
reservation data (rd) field n−3 x x x x x x 0 0
n−2 0 0 0 0 0 0 0 0
Note.— Bits denoted “x” are available for use within the information (in) field.
1.3.10 Periodic broadcast protocol specification
Note.— The periodic broadcast protocol is intended for those VSS users which transmit one or more times per
superframe for a number of superframes. A sequence of reserved slots linked by a periodic broadcast reservation is
known as a “stream”. A periodic broadcast reservation burst reserves a slot in the next superframe for its own stream
(i.e. a VSS user transmitting 3 times a minute has 3 streams).
1.3.10.1 Periodic broadcast reservation burst format
1.3.10.1.1 A reservation ID (rid) = 1 and a reservation data (rd) field in accordance with Table II-1-16 shall
indicate a periodic broadcast reservation. In this case, the information (in) field shall be extended up to the last 10 bits
prior to the CRC.
Table II-1-16. Periodic broadcast reservation bit encoding
Bit number
periodic time out (pt) n−3 x x x x x x pt2 pt1
periodic offset (po) n−2 po8 po7 po6 po5 po4 po3 po2 po1
Note 1.— Bits denoted “x” are available for use within the information (in) field.
Note 2.— If the reservation field is all zeros, then a null reservation is being made (see 1.3.9). In the case of pt = 3, a
combined periodic broadcast and incremental broadcast is indicated, in which case the periodic offset (po) subfield is replaced by
the incremental offset (io) subfield, as described in 1.3.12. When io = 0 binary, only a periodic reservation is made.
1.3.10.1.2 The subfields are defined in Table II-1-17.
Table II-1-17. Periodic broadcast reservation field encoding
Subfield Range Encoding Definitions

periodic offset (po) −127 to two’s complement math po identifies a slot relative to the first slot of the
+127 po = −128 is invalid transmission in a future superframe
periodic time out (pt) 0 to 3 pt is the number of superframes in the future for which
a reservation is being made
Note.— The two’s complement form is one method of representing signed binary numbers with the aim to reduce the amount
of binary states required to code a range of values that contain a shift in sign. In this case, it is –127 to +127. In two’s
complement, a positive number is represented as simple unsigned binary number, and negative number is represented as binary
number that is added to a positive number of the same magnitude to get to zero. In practice this is done by changing all 0’s to 1’s
and 1’s to 0’s and then by adding 1 to the result.
1.3.10.2 Periodic broadcast timers
1.3.10.2.1 Timer TV11 (reservation hold timer)
The timer TV11 shall control the number of successive superframes which will use the same slot for transmission (see
1.3.10.5) before moving to a new slot. There shall be one TV11 timer for each slot that is used for periodic broadcasts.
1.3.10.3 Periodic broadcast parameters
The periodic broadcast protocol shall implement the system parameters defined in Table II-1-18.
Table II-1-18. Periodic broadcast VSS system parameters
Recommended
Symbol Parameter name Minimum Maximum default Increment
TV11min Reservation hold 0 superframes 15 superframes 4 superframes 1 superframe
timer — minimum
value
TV11max Reservation hold 1 superframe 16 superframes 8 superframes 1 superframe
timer — maximum
value
V11 Nominal periodic rate 1 per superframe 60 per superframe 1 per superframe 1 per superframe
V12 Periodic dither range (2/M1) • V11 1.00 0.10 0.01
Note 1.— TV11min shall be less than or equal to TV11max (TV11min TV11max).
Note 2.— The VSS user shall provide any of the parameters, i.e. TV11min, TV11max, V11 and V12, as well as the
QoS parameters (Q2a to Q2d and Q4) for which the default values are not desired.
1.3.10.3.1 Parameters TV11min (reservation hold timer — minimum value) and TV11max
(reservation hold timer — maximum values)
The parameters TV11min and TV11max shall be used to determine the start value for the TV11 timer in line with the
procedure defined in 1.3.10.5.4.
1.3.10.3.2 Parameter V11 (nominal periodic rate)
The parameter V11 shall be the number of times per superframe that a VSS user will transmit a burst.
1.3.10.3.3 Parameter V12 (periodic dither range)
The parameter V12 shall define the range for candidate slots on either side of the nominal slot (see 1.3.10.5.1). The
station shall choose from the candidate slots a slot or group of slots to be reserved for transmission once the TV11 timer
expires. V12 shall be specified as a fraction of the nominal periodic rate.
Note.— The selected slot may be chosen from a range between the nominal slot {− truncate[(V12/2) • (M1/V11)]}
and the nominal slot {+ truncate[(V12/2) • (M1/V11)]}. If this range is greater than ± 127, then the selected slot may
be chosen from a range between nominal slot −127 and the nominal slot +127.
1.3.10.4 Periodic broadcast reception procedures
1.3.10.4.1 Upon receipt of a burst containing a periodic broadcast reservation, the station shall update its
reservation table and carry out the actions as specified in Table II-1-19. All reservations associated with a single
periodic broadcast reservation burst shall be known as a stream.
1.3.10.4.2 The actions defined in Table II-1-19 shall cancel any previous reservations for the same stream.
1.3.10.4.3 If a station was expecting to receive a transmission from a peer station containing a periodic broadcast
reservation, but instead it receives a transmission from the peer station containing an incremental broadcast reservation
(see 1.3.11) or a unicast request with the source/destination flag (sdf) set equal to one (sdf = 1) (see 1.3.14), the station
shall cancel the periodic broadcast reservation stream from the peer station.
Table II-1-19. Action on receipt of periodic broadcast reservation burst
Periodic Periodic time

offset (po) out (pt) Action
0 0 No reservation
Note 1.— Reservation format is the same as null reservation (see 1.3.9).
Any except 0 0, 1 or 2 Reserve the following slots for the source to broadcast:
if pt = 1 or 2, then for j = [1 to pt],

the slots = [j • M1[ through [bl − 1 + (j • M1)] after the first slot of the received
burst
AND
for j = [pt + 1 to 4],
the slots = [po + (j • M1)] through {bl − 1 + [po + (j • M1)]} slots after the first slot
of the received burst.
0 1 or 2 Reserve the following slots for the source to broadcast:
for j = [1 to pt], the slots = [j • M1] through [bl − 1 + (j • M1)] after the first slot of the
received burst.
Any 3 Reserve the following slots for the source to broadcast:
for j = [1 to 4], the slots = [j • M1] through [bl − 1 + (j • M1)] after the first slot of the
received burst.
Note 2.— When pt = 3 and po 0 binary (as described in 1.3.12), a combined

periodic/incremental reservation is made. In this case, the interpretation of the po is as if it
were an incremental offset (io) as described in 1.3.12 and 1.3.12.1.
1.3.10.5 Periodic broadcast transmission procedures
1.3.10.5.1 Selection of nominal slots (n_slots)
1.3.10.5.1.1 When operating without any directed slot reservations (see 1.3.16.1.1) for a given VSS user-
application which requires periodic broadcast transmissions, a station shall select nominal slots (n_slot) which form a
periodic sequence in time. It shall consider all the frequencies used, with a variation of no more than ± 1 slot as
required in order to accommodate the constraints imposed by the nominal update rate (nr) for the application and the
slot rate on the channel.
1.3.10.5.1.2 When operating with a mixture of directed slot reservations (see 1.3.16.1.1), autonomous and
directed rate reservations (see 1.3.16.1.1) for a given VSS user-application which requires periodic broadcast
transmissions, a station shall select nominal slots (n_slot) for the autonomous or directed rate which form a periodic
sequence in time. It shall consider all the frequencies used, with a variation of no more than ± 1 slot as required in order
to accommodate the constraints imposed by the nominal update rate (nr) for the application and the slot rate on the
channel.
Note 1.— For an application that requires periodic broadcast transmissions on multiple frequency channels and
for which no directed slot reservations have been received, the aggregate of all required transmissions should be used
when calculating the nominal update rate (nr). Example 1: Two frequencies have a required nr of once per 10 seconds
on each frequency. In this case, the nominal slots (n_slots) should be interleaved and equally spaced to achieve an
aggregate nr of once per 5 seconds (i.e. considering the two channels together). Example 2: Two frequencies have a
required nr of once per 15 seconds on frequency F1 and once per 5 seconds on frequency F2. In this case, the
aggregate nr should be once per 3.75 seconds, with three successive n_slots on F2 spaced 3.75 seconds apart, followed
by a 7.5-second gap centred on a n_slot for F1, followed by another three successive n_slots on F2 etc.
Note 2.— A station may shift all the nominal slots (n_slots) associated with an application' s autonomous or
directed rate reservations forward or backward in time without changing their relative positions in order to enhance
the likelihood of finding appropriate transmission slots for the application as a whole (i.e. within the dither bands
surrounding each n_slot).
Note 3.— A station may shift individual slots or sets of slots as required in order to satisfy the needs in the
selection of nominal slots (n_slots). This may be required, for example, if the application adds a new frequency or if the
nominal update rate (nr) on one of the existing frequencies is changed in real time (i.e. with a directed rate request).
Note 4.— Paragraph 1.3.10.5.1 is relevant for transmissions using periodic reservations. It does not apply to
transmissions using other reservation types or random transmissions. For example, transmissions made using random
and incremental protocols are excluded.
1.3.10.5.2 Selection of slots for a periodic broadcast transmission
If there is no existing periodic reservation for the VSS user, the station shall select a current transmission slot (ct_slot)
corresponding to each nominal slot (n_slot) by inspecting the reservation table data and using the following procedure:
a) The station shall apply the slot selection procedure specified in 1.3.6.2 by using all slots that are within
{truncate[(V12/2)•(M1/V11)]} of n_slot and within 127 slots of n_slot as candidate slots and the default or
other VSS user supplied quality of service parameters
b) When applying the slot selection procedure specified in 1.3.6.2, the station shall first select available slots at
levels zero, one and two excluding slots containing potential reservations associated with occupied slots as
defined in 1.2.4.3. Selections at level zero shall select from slots containing potential reservations associated
with unoccupied slots in increasing order of signal level as defined in 1.2.4.4.
c) If, on completion of the selection of available slots at level two, less than Q4 slots have been chosen, the
station shall select from slots containing potential reservations associated with occupied slots in increasing
order of signal level as defined in 1.2.4.4.
d) If at the end of this process, less than Q4 slots have been chosen, the station shall then continue the slot
selection process at level three.
Note.— The station tries to find unreserved slots in the range of [(V12 • M1)/V11] on either side of the nominal
slot (n_slot), ignoring slots that are four superframes after a slot in which a station detects the presence of a
transmission but is unable to decode the transmission. The ignored slots are assumed to contain potential reservations
since the undecoded transmission is most likely to contain a periodic reservation protocol for subsequent superframes.
If slot selection is unsuccessful by the end of level two, the potential reservations are then added back into the
candidate range and selected in order of increasing signal level.
1.3.10.5.3 Calculation of slot availability (s_avail)
After selection of a new current transmission slot (ct_slot), the station shall compute the slot availability (s_avail) by
indicating how many consecutive superframes are available until the equivalent slot is reserved by another user. The
value of s_avail shall indicate the slot [ct_slot + s_avail • M1] which is reserved by another user, and range from 1 (for
a slot that is reserved in the next superframe) to 4 (for slots that currently have no reservation for at least 3 superframes).
The calculation of s_avail shall use the following rules:
a) if the current transmission slot (ct_slot) has not been previously reserved, s_avail shall be the number of
superframes that are left before the equivalent slot is reserved.
b) if the current transmission slot (ct_slot) has been previously reserved by a station, s_avail shall be the number
of superframes that are left before the equivalent slot is reserved by a different user.
1.3.10.5.4 Transmission in a new slot
If there is no prior reservation or if the station is using for the first time a slot for which there has been a prior
reservation, the station shall start the timer TV11 at a value equal to s_avail (TV11 = s_avail) (provided that
s_avail = 1, 2 or 3) or equal to a random value uniformly chosen between TV11min and TV11max.
Note.— The reservation for the new slot is maintained for TV11 superframes unless slot availability (s_avail)
indicates that only 1, 2 or 3 superframes are available before another station has placed a reservation.
1.3.10.5.5 Transmission for TV11 greater than three (TV11 > 3)
If the TV11 timer is greater than three (TV11 > 3) and there is no requirement to associate the current transmission with
an incremental reservation, the station shall transmit a burst containing a periodic broadcast reservation in the current
transmission slot with incremental offset (io) = 0 and periodic time out (pt) = 3. After transmission, the timer TV11
shall be decremented by one (TV11 − 1) and the current transmission slot (ct_slot) shall be incremented by M1 (number
of slots per superframe) (ct_slot + M1).
1.3.10.5.6 Reservation of a new slot for TV11 equal to one, two or three (TV = 1, 2 or 3)
If the TV11 timer is equal to one, two or three (TV11 = 1, 2 or 3) and if the VSS user requires that periodic broadcast
reservations are maintained after the current transmission slot (ct_slot) reservation expires, the station shall reserve a
future transmission slot (ft_slot) for subsequent transmissions. If a ft_ slot has already been selected, there shall be no
further slot selection. Otherwise, selection of ft_slot shall be carried out by using the procedure set out in 1.3.10.5.2
which uses as candidate slots all slots that are:
— within {truncate[(V12/2) • (M1/V11)]} of n_slot;
— within 127 slots of n_slot; and
— within 127 slots of ct_slot, except slot (ct_slot + TV11 • M1).
Note.— This process selects a new slot to which the periodic broadcast transmission will move in the TV11
superframes after the current transmission slot (ct_slot). This new slot will occupy a different position in the
superframe to the ct_slot.
1.3.10.5.7 Transmission for TV11 equal to one, two or three (TV11 = 1, 2, or 3)
1.3.10.5.7.1 If the TV11 timer is equal to one, two or three (TV11 = 1, 2 or 3), the station shall transmit a burst
containing a periodic broadcast reservation in the current transmission slot (ct_slot) with periodic offset (po) = (ft_slot
− ct_slot) and periodic time out (pt) = TV11 − 1.
1.3.10.5.7.2 If a future transmission slot (ft_slot) has not been selected and the VSS user does not require the
reservation to be maintained, the value of the periodic offset (po) shall be set to zero (po = 0).
1.3.10.5.7.3 After transmission, the timer TV11 shall be decremented and the current transmission slot (ct_slot)
set equal to [ct_slot + M1].
1.3.10.5.8 TV11 equal to zero (TV11 = 0)
1.3.10.5.8.1 If the TV11 timer is equal to zero (TV11 = 0), and the VSS user requires that a reservation be
maintained, then if a new slot has not been selected for further periodic broadcasts, the station shall select a new current
transmission slot (ct_slot) by using the procedures set out in 1.3.10.5.2. If a new slot has been selected for further
periodic broadcasts, the station shall set the ct_ slot equal to the future transmission slot (ft_slot) (ct_slot = ft_slot).
1.3.10.5.8.2 The station shall start to transmit in the new current transmission slot (ct_slot) by carrying out the
procedures set out in 1.3.10.5.3 to 1.3.10.5.8.
1.3.10.5.8.3 If the VSS user does not require that a reservation be maintained, no further action shall be taken.
1.3.10.5.9 Cancellation of reservation
A station wishing to cancel a stream of reservations for its own transmissions shall, in the absence of a reservation
conflict, transmit a periodic broadcast reservation burst with periodic offset (po) = 0 and periodic time out (pt) = 0 in
the next reserved slot and the timer TV11 shall be cleared. A station receiving such a burst shall clear all reservations
known to be associated with the stream.
Note 1.— Because all existing reservations for a stream are cancelled on receipt of a periodic reservation burst
and are replaced according to the reservation information contained in the burst (see 1.3.10.4), this action has the
effect of cancelling the whole stream.
Note 2.— Reservation conflicts are mediated in accordance with 1.3.6.5, and the requirement to transmit a
reservation cancellation (i.e. po = 0 and pt = 0) does not apply if the transmission would be disallowed by the
considerations outlined in 1.3.6.5.
1.3.11 Incremental broadcast protocol specification
The incremental broadcast protocol is intended for those VSS users which are transmitting multiple times per minute,
but only for a minute or two. A burst reserves a number of slots for a time later in the same superframe. The number of
slots reserved is equal to the burst length (see 1.3.5) of the burst containing the reservation.
1.3.11.1 Incremental broadcast reservation burst format
1.3.11.1.1 A reservation ID (rid) = 0 with extended reservation ID (erid) and reservation fields set in accordance
with Table II-1-20 shall indicate an incremental broadcast reservation. In this case, the information (in) field shall be
extended up to the last 10 bits prior to the CRC.
1.3.11.1.2 The subfields shall be as defined in Table II-1-21.
Table II-1-20. Incremental broadcast reservation bit encoding
Bit Number
n−3 x x x x x x io8 io7
incremental offset (io) n−2 1 0 io6 io5 io4 io3 io2 io1
Note.— Bits denoted“ x” are available for use within the information field.
Table II-1-21. Incremental broadcast reservation field encoding

Incremental offset io identifies a slot relative to the first slot of the
(io) 0 to 255 See 1.3.11.4. transmission.
1.3.11.2 Incremental broadcast parameters
The incremental broadcast protocol shall implement the system parameters defined in Table II-1-22. The VSS user
shall provide any of the parameters (V21 and V22) as well as the QoS parameters (Q2a to Q2d and Q4) for which the
default values are not desired.
Table II-1-22. Incremental broadcast VSS system parameters

V21 Nominal 960/M1 sec 60 480/M1 sec 1.0 sec 0.1 sec
incremental
period
V22 Maximum 720/(V21 • M1) min[1.001−240/(V21•M1), min(0.75, maximum 0.001
incremental 61 200/(V21•M1) – 0.999] allowed value of V22)
dither range
Note.— The maximum value of V21 is set by the maximum allowed value of the incremental offset (io) subfield. The
minimum value of V21 and V22 is set to ensure that there are at least 5 candidate slots from which to choose a slot to
be reserved.
1.3.11.2.1 Parameter V21 (nominal incremental period)
The parameter V21 shall be the nominal time after the first slot of the incremental broadcast transmission when a VSS
user will be allowed to transmit a burst.
1.3.11.2.2 Parameter V22 (maximum incremental dither range)
The parameter V22 shall define the range of candidate slots on either side of the nominal slot from which the station
shall choose a slot or group of slots to be reserved for transmission. V22 shall be specified as a fraction of the nominal
incremental period.
Note.— The selected slot may be chosen from a time range between [V21 ± (V22 • V21)].
1.3.11.3 Incremental broadcast reception procedures
1.3.11.3.1 Upon receipt of a burst containing an incremental broadcast reservation, a station shall reserve the slot
equal to [4 • io] through [bl − 1 + (4 • io)] after the first slot of the received burst for the source to broadcast.
1.3.11.3.2 When a burst contains an incremental broadcast reservation with incremental offset (io) = 0, then no
incremental reservation shall be placed.
1.3.11.4 Incremental broadcast transmission procedures
1.3.11.4.1 Selection of the transmission slot for the incremental broadcast reservation
If no slot or group of consecutive slots has been reserved for transmission of an incremental reservation, and if the
incremental reservation is not to be combined with a periodic broadcast reservation (see 1.3.12), the station shall select
a slot or group of consecutive slots by using the random access procedures (see 1.3.7). The transmission slot (t_slot)
shall be the first slot of the incremental broadcast transmission.
1.3.11.4.2 Selection of the reserved slot for the incremental broadcast reservation
The station shall choose a slot or group of consecutive slots for reservation according to the slot selection procedure
specified in 1.3.6.2:
a) by using VSS user-supplied QoS parameters; and
b) by using candidate slots in the range from {(1 − V22) • [(V21 • M1)/60]} to {(1 + V22) • [(V21 • M1)/60] +
(bl − 1)}, such that the chosen slot or the first slot in the chosen group of slots is an exact modulo 4 difference
from the transmission slot (t_slot).
The reserved slot (r_slot) shall be the chosen slot or the first slot in the chosen group of slots.
1.3.11.4.3 Incremental broadcast burst transmission
The station shall transmit an incremental broadcast burst in the transmission slot with the value of the incremental
offset (io) set to:
io = [(r_slot − t_slot)/4]
where r_slot is the reserved slot and t-slot is the transmission slot.
1.3.12 Combined periodic broadcast and

incremental broadcast protocol specification
The periodic broadcast reservation (see 1.3.10) can be combined with an incremental broadcast reservation (see 1.3.11)
when the periodic broadcast timer (TV11) is greater than three (TV11 > 3), enabling the station to reserve a fourth slot
up to 1 020 slots in the future (as well as 3 slots in the subsequent superframes). In this regard, it should be noted that
the combined periodic-incremental protocol allows a station to reserve the equivalent slots in future superframes (as in
the periodic broadcast protocol), and one further slot in the current superframe — anywhere up to 1 020 slots from the
current slot (where the reservation is made). A station may therefore use the opportunity presented by a combined
periodic broadcast and incremental broadcast in order to reserve a slot for a different VSS user which happens to be in
the random access queue or to improve net entry performance by reserving slots, both in the next superframe (periodic
broadcast) and in the current superframe (incremental broadcast).
1.3.12.1 Combined periodic broadcast and incremental broadcast reservation burst
A reservation ID (rid) = 1 and a reservation data (rd) field in accordance with Table II-1-23 shall indicate a combined
periodic broadcast and incremental broadcast reservation. In this case, the information (in) field shall be extended up to
the last 10 bits prior to the CRC. The periodic time out (pt) subfield shall be set to three (pt = 3). The incremental offset
(io) subfield shall be as defined in 1.3.11.1. All other parameters and procedures shall be as specified in 1.3.10 and
1.3.11.
Table II-1-23. Combined periodic/incremental broadcast reservation bit encoding
Bit number
periodic time out (pt) = 3 n−3 x x x x x x 1 1
incremental offset (io) n−2 io8 io7 io6 io5 io4 io3 io2 io1
Note.— Bits denoted“ x” are available for use within the information field.
1.3.13 BND broadcast protocol specifications
The BND can be used by a VDL Mode 4 station intending to enter a VDL Mode 4 channel/network (i.e. begin
transmitting synchronization bursts on an autonomous basis) in cases where:
a) the station has listened to a channel for a few seconds but has not yet built a complete reservation table;
b) the station has either: i) fewer current reservations for synchronization bursts than required; or ii) a sufficient
number of reservations, but with one or more of them about to expire (periodic time out (pt) = 0); and
c) the station wishes to initiate or continue periodic streams by using the reservation opportunities presented by
these existing reservations.
The BND can be transmitted in a normal or delayed burst. The BND can also be used in the context of a normal stream
of synchronization bursts in order to meander a stream outside the existing maximum dither range (e.g. when the flow
channel must be adjusted).
1.3.13.1 BND reservation burst format
A reservation ID (rid) = 0, an extended reservation ID (erid) = 00001binary, and reservation data set in accordance
with Table II-1-24 shall indicate a BND. The subfields shall be as defined in Table II-1-25.
Table II-1-24. BND broadcast reservation bit encoding
Bit number
negative dither (nd) n−3 x x x x x x nd5 nd4
extended reservation ID (erid) n−2 0 0 0 0 1 nd3 nd2 nd1
Note.— Bits denoted “x” are not used by this reservation type and shall be available for use within the information
field.
Table II-1-25. BND broadcast reservation parameters

negative dither (nd) 0 to 31 nd identifies a slot in the next superframe that is offset by at least
128 slots before the current position (i.e. a slot earlier than M1 – 128
from the current slot).
1.3.13.2 BND broadcast parameters
There are no BND parameters.
1.3.13.3 BND broadcast reception procedures
Upon receipt of a burst containing a BND broadcast reservation, a station shall reserve the slots from [M1− 128 −
(4 • nd)] through [M1 − 128 − (4 • nd) + (bl − 1)] after the first slot of the received burst for the source to broadcast.
Note.— This reservation type allows a station to place a reservation for a future transmission in a slot which is
likely to be unreserved (see associated BDN broadcast transmission procedures in 1.3.13.4).
1.3.13.4 BND broadcast transmission procedures
A station shall not transmit a BND reservation until it has listened to a channel for at least 254 slots and can select a
slot for transmission from among those slots addressable by the BND reservation that uses the slot selection procedures
defined in 1.3.6.2 and the VSS user-supplied QoS parameters, namely Q2 and Q4.
1.3.14 Unicast request protocol specification
Note.— This protocol is intended for a VSS user which requires
a) a response from a peer VSS user in a reserved slot,
b) a slot to be reserved for a transmission to a peer, or
c) a slot to be reserved to make a broadcast transmission.
In the case of c), the protocol is a more flexible version of the incremental broadcast protocol, supporting
reservations of variable length on user defined channels.
1.3.14.1 Unicast request reservation burst format
1.3.14.1.1 A reservation ID (rid) = 0 with an extended reservation ID (erid) and reservation fields set in
accordance with Table II-1-26 shall indicate a unicast request reservation.
Table II-1-26. Unicast request reservation bit encoding
Bit number
destination address (d) n−8 d24 d23 d22 d21 d20 d19 d18 d17
n−7 d16 d15 d14 d13 d12 d11 d10 d9
n−6 d8 d7 d6 d5 d4 d3 d2 d1
source/destination flag (sdf) n−5 ro12 ro11 ro10 ro9 sdf d27 d26 d25
response offset (ro) n−4 ro8 ro7 ro6 ro5 ro4 ro3 ro2 ro1
length (lg) n−3 res res res res res lg3 lg2 lg1
priority (pr) n−2 0 0 1 0 pr4 pr3 pr2 pr1
Note.— “res” refers to bits available for the information field.
1.3.14.1.2 The subfields and associated actions shall be as defined in Table II-1-27. Bits 25, 26 and 27 of the
destination address subfield shall be the address type field (see 1.4.2.2.1). In the case that the address type field is equal
to seven, bits 1 through 24 of the destination subfield (d) shall be absent, so that the information field will be extended
up to the last 4 octets prior to the CRC. Otherwise, the burst shall include all of the destination subfield (d), so that the
information field will be extended up to the last seven octets prior to the CRC.
Table II-1-27. Unicast request reservation field encoding
Subfield Range Encoding / Actions Definitions

response offset (ro) 0 to 4 095 ro identifies a slot relative to the
first slot of the transmission.
destination address (d) 0 to 227−1 See 1.4.2.2. d is the 27-bit address of the
destination station.
source/destination flag Boolean If sdf = 0, reserve the response slot for the sdf indicates which station will
(sdf) destination station to transmit. respond in the reserved response
If sdf = 1, reserve the response slot for the slot. Note that the source station is
source station to transmit. the station placing the reservation.
length (lg) 0 to 15 lg is one less than the number of
slots that are reserved for the
response.
priority (pr) 0 to 15 See Table II-1-11.
1.3.14.2 Unicast request parameters
The unicast request protocol shall implement the system parameters as defined in Table II-1-28. The VSS user shall
provide the destination address and any of the parameters (V32, V33, V34, V35 and V36) as well as QoS parameters
(Q2a to Q2d, Q4 and Q5) for which the default values are not desired.
Table II-1-28. Unicast request VSS system parameters
Recommended
Symbol Parameter name Minimum Maximum default Increment
V32 Minimum response delay 2 slots 500 slots 20 slots 1 slot
V33 Maximum response delay 2 slots 4 095 slots 1 000 slots 1 slot
V34 Source/destination control 0 1 0 1
V35 Broadcast control 0 1 0 1
V36 Length of reserved block 1 slot 256 slots N/A 1 slot
1.3.14.2.1 Parameter V32 (minimum response delay)
Parameter V32 shall be the minimum delay, measured in slot intervals, that a station will provide to a responder in
order to ensure that the responder can generate the response before its reserved slot.
Note.— [(V32 • 60)/M1] is the maximum time that a station has to generate a response to the request.
1.3.14.2.2 Parameter V33 (maximum response delay)
Parameter V33 shall be the maximum delay, measured in slot intervals, that a station will provide to a responder in
order to ensure timely delivery in case a re-transmission is required.
1.3.14.2.3 Parameter V34 (source/destination control)
Parameter V34 shall control whether the unicast reservation protocol is used to reserve a slot for the destination station
to transmit a response to the source (V34 = 0) or for the source station to transmit a response to the destination
(V34 = 1). If the broadcast control parameter is V35 = 1, the value of V34 shall be ignored.
Note.— If the destination subfield is omitted (i.e. V35 = 1), then the reservation is for the source to broadcast and
the value of V34 has no meaning.
1.3.14.2.4 Parameter V35 (broadcast control)
Parameter V35 shall control whether the lowest 24 bits of the destination subfield are included in the reservation. If
V35 = 0, then the lowest 24 bits of the destination subfield shall be included and the reservation will be used by the
station to transmit to or receive from a peer station. Otherwise, the lowest 24 bits of the destination subfield shall be
omitted, the address type field shall be set to seven, and the reservation will be used by the station to make a broadcast
transmission.
1.3.14.2.5 Parameter V36 (length of reserved block)
Parameter V36 shall be the number of reserved slots (r_slots) required for the unicast reservation protocol response.
1.3.14.3 Unicast request reception procedures
Upon receipt of a burst containing a unicast request reservation, a station shall reserve all of the slots from [1 + ro]
through [1 + ro + lg] after the first slot of the received burst for:
a) the destination to transmit a response to the source (if source/destination flag sdf = 0 and address type
field ≠ 7);
b) the source to transmit a response to the destination (if sdf = 1 and address type field ≠ 7); and
c) the source to make a broadcast transmission (if address type field = 7).
1.3.14.4 Unicast request transmission procedures
1.3.14.4.1 Selection of the transmission slot (t_slot) for the unicast request reservation
If no slot has been reserved for transmission of a unicast reservation, the station shall select a slot using the random
access procedures (see 1.3.7). The transmission slot (t_slot) shall be the slot containing the unicast request reservation
transmission.
1.3.14.4.2 Selection of the reserved slot (r_slot) for the response
To reserve a block of slots of length V36 for response (address type field ≠ 7) or broadcast transmission (address type
field = 7), the slots shall be selected by using:
a) the slot selection procedure specified in 1.3.6.2;
b) VSS user-supplied QoS parameters; and
c) candidate slots in the range of V32 to V33 after the transmitted burst.
1.3.14.4.3 Unicast request burst transmission
1.3.14.4.3.1 A station sending a unicast request burst to its peer (V35 = 0) shall include the unicast request
reservation field. It shall set the parameters to the following values:
— destination (d) subfield to the destination of the burst;
— response offset (ro) subfield to a value of (r_slot − t_slot–1);
— length (lg) subfield equal to (V36 – 1);
— priority (pr) subfield equal to the priority (Q1) of the burst to be transmitted as defined by Q1; and
— source/destination flag (sdf) to V34.
1.3.14.4.3.2 A station sending a unicast request burst to reserve a slot for a subsequent broadcast (V35 = 1) shall
include the unicast request reservation field. It shall set the parameters to the following values:
— response offset (ro) subfield to a value of (r_slot - t_slot – 1);
— length (lg) subfield equal to (V36 – 1);
— priority (pr) subfield equal to the priority (Q1) of the burst to be transmitted as defined by Q1; and
— address type field equal to 7.
1.3.14.4.4 Re-transmission after no response
In the case of address type subfield ≠ 7 and source/destination flag subfield sdf = 0, if a response is not received by the
end of the reserved response slot(s), then the station shall re-transmit the unicast burst according to the procedures of
1.3.21.
1.3.14.4.5 Slot selection criteria for unicast request with source/destination flag subfield equal to one
By using the unicast request protocol with sdf = 1, a station applying the slot selection criteria of 1.3.6.2.2.1 shall
exclude any slot already reserved by another station.
Note.— The use of the unicast request protocol with sdf = 1 allows a station placing the reservation to transmit to
a different destination than the destination included in the reservation field. This ability allows a station completing a
data transfer with one station to simultaneously start a new data transfer to a different destination. However, since the
new destination address is not known by any other station, it is not possible to apply CCI criteria and the slot must be
excluded from slot selection.
1.3.15 Information transfer request protocol specification
Note.— This protocol is intended for a VSS user which requires a peer VSS user to send a response of length (lg).
The protocol also allows the requesting VSS user to place a reservation for an acknowledgement by the requesting VSS
user to the response field.
1.3.15.1 Information transfer request reservation burst format
A reservation ID (rid) = 0 with extended reservation ID (erid) = 01010binary and reservation fields set in accordance
with Table II-1-29 shall indicate an information transfer request reservation. In this case, the information field shall be
extended up to the last 9 octets prior to the CRC. The subfields shall be as defined in Table II-1-30.
Table II-1-29. Information transfer request reservation bit encoding
Bit number
acknowledgement offset (ao) n−10 res ao7 ao6 ao5 ao4 ao3 ao2 ao1
length (lg) n−9 res res res res lg4 lg3 lg2 lg1
response offset (ro) n−8 ro8 ro7 ro6 ro5 ro4 ro3 ro2 ro1
n−7 ro12 ro11 ro10 ro9 f12 f11 f10 f9
frequency (f) n−6 f8 f7 f6 f5 f4 f3 f2 f1
n−4 d16 d15 d14 d13 d12 d11 d10 d9
n−3 d8 d7 d6 d5 d4 d3 d2 d1
n−2 0 1 0 1 0 d27 d26 d25

Table II-1-30. Information transfer reservation field encoding
Subfield Range Encoding

length (lg) (See also Table II- 0 to 255 lg is one less than the number of slots that
1-27.) are reserved for the response.
acknowledgement offset (ao) 0 to 127 ao identifies a slot relative to the end of the
block of slots reserved by the response
offset and length subfields.
response offset (ro) (See also 0 to 4 095 ro identifies a slot relative to the first slot
Table II-1-27.) of the transmission.
destination address (d) 0 to 227−1 d is the 27-bit address of the destination
station for which the block of slots is being
reserved.
frequency (f) bit 12: frequency band indicator: The frequency subfield (f) identifies the
0: VHF band 108 — 136.975 MHz frequency on which the reservation is to be
1: reserved for future allocation made for the response. (See 1.3.15.4.4.)
bits 1 to 11: frequency allocation for bit 12 = 0:

1 to 1 160 per frequency band in 25kHz
increments.
1 161 to 2 047 reserved for future allocation.
1 indicates bottom of band.
f = 001 hex = 108.000 MHz;
f = 000 hex if the subfield is to be ignored.
1.3.15.2 Information transfer request parameters
The information transfer request protocol shall implement the system parameters defined in Table II-1-31. The VSS
user shall provide the destination address and any of the parameters (V42, V43, V44, V45, and V46) as well as the QoS
parameters (Q2a to Q2d and Q4) for which the default values are not desired.
Table II-1-31. Information transfer request VSS system parameters

V42 Length of information transfer 1 slot 256 slots N/A (depends on 1 slot
information to be
transmitted)
V43 Minimum information transfer 2 slots 500 slots 20 slots 1 slot
delay
V44 Maximum information transfer 2 slots 2 047 slots 1 000 slots 1 slot
delay
V45 Minimum response delay 2 slots 500 slots 20 slots 1 slot
V46 Maximum response delay 2 slots 2 047 slots 1 000 slots 1 slot
1.3.15.2.1 Parameter V42 (length of information transfer)
Parameter V42 shall be the number of slots required for information transfer.
1.3.15.2.2 Parameter V43 (minimum information transfer delay)
Parameter V43 shall be the minimum delay, measured in slot intervals, that a station will provide to a responder in
order to ensure that the responder can generate the required information for transfer before its reserved slots.
Note.— [(V43 • 60)/M1] is the maximum time that a station has to generate a response to the request.
1.3.15.2.3 Parameter V44 (maximum information transfer delay)
Parameter V44 shall be the maximum delay, measured in slot intervals, that a station will provide to a responder in
order to ensure timely delivery in case a re-transmission is required.
Parameter V45 shall be the minimum delay, measured in slot intervals, given for the requesting station, after
completion of the information transfer, to generate an acknowledgement to the information transfer in order to ensure
that the requesting station can generate the acknowledgement before its reserved slot.
Note.— [(V45 • 60)/M1] is the maximum time that a station has to generate an acknowledgement to the
information transfer.
1.3.15.2.5 Parameter V46 (maximum response delay)
Parameter V46 shall be the maximum delay, measured in slot intervals, given for the requesting station, after
completion of the information transfer, to general an acknowledgement. This ensures timely delivery of the
acknowledgement in case a re-transmission is required.
1.3.15.3 Information transfer request reception procedures
Upon receipt of a burst containing an information transfer request reservation, a station shall reserve on the specified
frequency all of the slots from [1 + ro] through [1 + ro + lg] after the first slot of the received burst for the destination
in order to transmit one or more information bursts to the source. In addition, the slot equal to [2 + ro + lg + ao] after
the first slot of the received burst shall be reserved for the source to transmit an acknowledgement to the destination, on
the same frequency as the burst containing the information transfer request reservation.
1.3.15.4 Information transfer request transmission procedures
1.3.15.4.1 Selection of the transmission slot (t_slot) for the information transfer request reservation
If no slot has been reserved for transmission of an information transfer request reservation, the station shall select a slot
using the random access procedures (see 1.3.7). The transmission slot (t_slot) shall be the slot containing the
information transfer request reservation transmission.
1.3.15.4.2 Selection of the reserved slots (r_slot) for the response
To reserve a block of slots of length V42 for the response transmission, the slots shall be selected by using:
a) the slot selection procedure specified in 1.3.6.2,

b) VSS user-supplied QoS parameters, and
c) candidate slots in the range V43 to V44 after the transmitted burst.
1.3.15.4.3 Selection of the reserved slot (r_slot) for the acknowledgement
The acknowledgement slot (a_slot) shall be selected by using:
a) the slot selection procedure specified in 1.3.6.2,
b) VSS user-supplied QoS parameters, and
c) candidate slots in the range V45 to V46 after the end of the slot or group of slots reserved for the response.
1.3.15.4.4 Information transfer request burst transmission
A station sending an information transfer request burst to its peer shall include the information transfer request
reservation field. It shall set the parameters to the following values:
— response offset (ro) subfield to a value of (r_slot − t_slot − 1);
— length (lg) subfield equal to (V42 − 1);
— frequency (f) subfield set to the channel on which information transfer is required; and
— acknowledgement offset (ao) subfield set to a value of (a_slot − r_slot − lg − 1).
1.3.15.4.5 Action after no response
If a response is not received by the reserved information transfer slots, then the station shall inform the VSS user that
no response has been received and shall then carry out the actions defined by the VSS user.
Note.— As an example, if the information transfer protocol is being used as part of DLS long transmission
procedure, the defined action is to send a NACK in the slot reserved for the acknowledgement.
1.3.15.5 Information transfer request acknowledgement procedures
The acknowledgement shall be on the same frequency as the information transfer reservation burst that was used to
reserve a slot for the acknowledgement.
1.3.16 Directed request protocol specification
Note.— This protocol is intended for a VSS user which is responding to a plea for slot reservations (rapid network
entry), or which requires periodic broadcast responses from a peer VSS user. Both of these scenarios involve
reservations calculated and declared for use by the peer station. In addition, this protocol allows a VSS user to request
that a peer VSS user autonomously transmit at a specified rate.
1.3.16.1 Directed request reservation burst format
A reservation ID (rid) = 0, an extended reservation ID (erid) = 01100binary, and reservation fields set in accordance
with Table II-1-32 shall indicate a directed request reservation. The length of the reservation field shall be determined
by the value of the plea response flag (pr_flag). In case pr_flag = 1, the information (in) field shall be extended up to
the last 14 octets prior to the CRC. In case pr_flag = 0, the information (in) field shall be extended up to the last 10
octets prior to the CRC. The nominal update rate (nr) field shall be encoded in accordance with Table II-1-33. The
27-bit destination address (d) shall be the 27-bit address of the destination station creating the reservations.
Note.— The directed request reservation burst may be used for a plea response, autotune, or other directed
request application.
Table II-1-32. Directed request reservation bit encoding
Bit number
Identification of additional n−15
reservation data n−14
n−13
n−12
n−11 per Tables II-1-34, II-1-36 through II-1-37
n−10
n−9
n−8
n−7
Nominal update rate (nr); n−6 pr_flag nr4 nr3 nr2 nr1
Plea response flag (pr_flag)
Destination address (d) n−5 d24 d23 d22 d21 d20 d19 d18 d17
n−4 d16 d15 d14 d13 d12 d11 d10 d9
n−3 d8 d7 d6 d5 d4 d3 d2 d1
Extended reservation ID (erid) n−2 0 1 1 0 0 d27 d26 d25
Table II-1-33. Nominal update rate (nr) encoding
Encoded data Nominal update rate (nr) (transmissions per minute)

nr4 nr3 nr2 nr1 nr
0 0 0 0 1
0 0 0 1 2
0 0 1 0 3
0 0 1 1 4
0 1 0 0 5
0 1 0 1 6
0 1 1 0 8
0 1 1 1 Invalid
1 0 0 0 10
Encoded data Nominal update rate (nr) (transmissions per minute)

1 0 0 1 12
1 0 1 0 15
1 0 1 1 20
1 1 0 0 30
1 1 0 1 60
1 1 1 0 0
1 1 1 1 Special
1.3.16.1.1 Autotune reservation burst format
A directed request reservation burst with plea response flag (pr_flag) = 0 shall indicate an autotune reservation.
Additional reservation data shall be set in accordance with Table II-1-34, with subfields defined in accordance with
Table II-1-35. A reservation with directed offset (do) = 0, receiver control (rcvr) = 00binary and frequency (f) ≠ current
frequency is invalid and shall be handled as per 1.3.5.
Table II-1-34. Encoding of additional data in autotune reservation burst
Bit number
Directed time out (dt) n−11 dt4 dt3 dt2 dt1 f12 f11 f10 f9
Frequency (f) n−10 f8 f7 f6 f5 f4 f3 f2 f1
Length (lg) n−9 res res res res lg4 lg3 lg2 lg1
Transmit control (trmt) n−8 res res trmt res do12 do11 do10 do9
Directed offset (do) n−7 do8 do7 do6 do5 do4 do3 do2 do1
Override flag (or); receiver n−6 or rcvr2 rcvr1 0 nr4 nr3 nr2 nr1
control (rcvr); nominal update
rate (nr); pr_flag = 0
Table II-1-35. Directed request reservation field encoding

length (lg) 0 to 15 See Table II-1-27. lg is one less than the number of slots that
are reserved.
Directed time out (dt) 0 to 15 A value of 15 cancels the dt = the number of planned future
reservation. transmissions reserved in slots spaced M1
slots apart.
Nominal update rate (nr) 0 to 60 See Table II-1-33. See Table II-1-33.
When pr_flag = 0, nr = special is
invalid.
Override flag (or) 0 to 1 See 1.3.16.3.1. or indicates whether the current directed
request reservation burst overrides all
previous directed request reservations
issued by the station on the indicated
frequency.

Receiver control (rcvr) 0 to 3 00 = Station must continue to Defines handling of receiver tuned to
monitor the current frequency; frequency used to receive this burst.
01 = Station must monitor the
indicated frequency;
10 = Autonomous decision;
11 = Station must continue to
monitor the current frequency
and also the indicated frequency
Transmit control (trmt) 0 to 1 0 = cancel transmissions on the
current frequency (see
1.3.10.5.9)
1 = continue transmission on the
current frequency (see
1.3.16.5.3)
Directed offset (do) 0 or 2 to 212 – 1 do = 1: invalid do = 0 implies directed rate reservation.
do >1 implies directed slot reservation. For
do > 1, do = the first slot in which to
transmit.
offset to first reserved 2 to 29 − 1 off = 0, 1: invalid off = the first slot in which to transmit (for
slot (off) plea response)
Additional slots (aj) 1 to 2k − 1 aj = 20 hex and nr special: For nr special, aj is encoded as two’s
(k = 6, 12) invalid complement offset about a nominal slot
defined by the offset to the first slot and the
Note: k is the number of bits in nominal update rate.
each aj. k=6 for nr special, For nr = special, a is encoded as a binary
and k=12 for nr = special. j is increment from the previously reserved
the number of additional slots slot. aj refers to the additional slot
Frequency (f) See Table II-1-30. See Table II-1-30. Defines new frequency for transmissions of
required data.
plea response flag See 1.3.16.1.
(pr_flag)
1.3.16.1.2 Plea response burst format
A directed request reservation with plea response flag (pr_flag) = 1 shall indicate a network entry plea response. In this
case, the reservation data not previously defined shall be encoded as indicated in Tables II-1-36 and II-1-37 (with
subfields set in accordance with Table II-1-35) and consisting of:
a) the offset to a first reserved slot; and
b) offsets to an additional n reserved slots as appropriate.
Additional reserved slots shall be encoded as follows:
— slots 1 to n shall be encoded in additional slots a1 to an;
— additional slots an+1 to aN (where N is the maximum number of additional slots that can be accommodated in
the formats defined by Tables II-1-36 and II-1-37) shall be set to zero (an+1 to aN = 0).
Note 1.— In the format defined by Table II-1-36, up to 11 additional slots can be accommodated with offsets
encoded using 6 bits. In the format defined by Table II-1-37, up to 5 additional slots can be accommodated with offsets
encoded using 12 bits.
Note 2.— This protocol is intended as a response for a VSS user which has no knowledge of the reservation table
and must be given a large number of reservations in a single transmission. It is primarily intended as a response to a
plea for help during rapid network entry (e.g. when a peer station asks for help in setting up a sequence of streams for
synchronization bursts). However, it may be transmitted by the destination station to give itself a large number of
reservations quickly.
Table II-1-36. Encoding of additional data with nominal update rate (nr) ≠ special
Bit number
additional slots (aj) n−15 a11,6 a11,5 a8,6 a8,5 a8,4 a8,3 a8,2 a8,1
n−14 a11,4 a11,3 a7,6 a7,5 a7,4 a7,3 a7,2 a7,1
n−13 a11,2 a11,1 a6,6 a6,5 a6,4 a6,3 a6,2 a6,1
n−12 a10,6 a10,5 a5,6 a5,5 a5,4 a5,3 a5,2 a5,1
n−11 a10,4 a10,3 a4,6 a4,5 a4,4 a4,3 a4,2 a4,1
n−10 a10,2 a10,1 a3,6 a3,5 a3,4 a3,3 a3,2 a3,1
n−9 a9,6 a9,5 a2,6 a2,5 a2,4 a2,3 a2,2 a2,1
n−8 a9,4 a9,3 a1,6 a1,5 a1,4 a1,3 a1,2 a1,1
offset to first reserved slot (off) n−7 a9,2 a9,1 off9 off8 off7 off6 off5 off4
nominal update rate (nr); plea response n−6 off3 off2 off1 1 nr4 nr3 nr2 nr1
flag (pr_flag) = 1
Table II-1-37. Encoding of additional data for nominal update rate (nr) = special
Bit number
additional slots (aj) n−15 res res res res a5,12 a5,11 a5,10 a5,9
n−14 a5,8 a5,7 a5,6 a5,5 a5,4 a5,3 a5,2 a5,1
n−13 a4,8 a4,7 a4,6 a4,5 a4,4 a4,3 a4,2 a4,1
n−12 a4,12 a4,11 a4,10 a4,9 a3,12 a3,11 a3,10 a3,9
n−11 a3,8 a3,7 a3,6 a3,5 a3,4 a3,3 a3,2 a3,1
n−10 a2,8 a2,7 a2,6 a2,5 a2,4 a2,3 a2,2 a2,1
n−9 a2,12 a2,11 a2,10 a2,9 a1,12 a1,11 a1,10 a1,9
n−8 a1,8 a1,7 a1,6 a1,5 a1,4 a1,3 a1,2 a1,1
offset to first reserved slot (off) n−7 res res off9 off8 off7 off6 off5 off4
nominal update rate (nr); plea n−6 off3 off2 off1 1 1 1 1 1
response flag (pr_flag) = 1
1.3.16.2 Directed request parameters
The directed request protocol shall implement the system parameters defined in Table II-1-38. The VSS user shall
provide the destination address and any of the parameters (e.g. V52) as well as QoS parameters (Q2a to Q2d, Q4 and
Q5) for which the default values are not desired.
Table II-1-38. Directed request VSS system parameters
Recommended
Symbol Parameter Name Minimum Maximum default Increment
V52 Minimum response delay 1 slot 500 slots 20 slots 1 slot
Parameter V52 shall be the minimum time that a station will provide to a responder in order to ensure timely delivery in
case a re-transmission is required.
1.3.16.3 Directed request reception procedures
1.3.16.3.1 Autotune reception procedures
1.3.16.3.1.1 Upon receipt of a burst containing an autotune reservation (plea response flag pr_flag = 0), the
station shall update its reservation table and carry out the actions as specified in Table II-1-39.
Table II-1-39. Action on receipt of an autotune reservation burst
Directed offset Directed time out

(do) (dt) Action
0 any See 1.3.16.5.2.
1 any Invalid
1 < do < M1 dt < 15 Reserve the following slots for the destination to broadcast:
for j = (0 to 3) and k = [0 to (nr − 1)],

the slots = {truncate [do + (k • M1/nr) + j • M1]} through {lg + truncate [do + (k •
M1/nr) + j • M1]} after the first slot of the received burst.
1 < do < M1 dt = 15 Reserve the following slots for the destination to broadcast:
for k = [0 to (nr − 1)],

the slots = {truncate [do + (k • M1/nr)]} through {lg + truncate [do + (k • M1/nr)]}
after the first slot of the received burst.
do > M1−1 any Invalid
1.3.16.3.1.2 If the override (or) flag is set to one (or = 1), the destination station shall cancel all previously
placed autotune reservations made by the source station on frequency (f) (see 1.3.10.5.9); otherwise it shall retain the
previous reservations.
Note 1.— In the case of directed time out (dt) = 15, slots are reserved in the current superframe for the destination
to transmit periodic broadcast reservation bursts with periodic offset (po) = 0 and periodic time out (pt) = 0. These
bursts have the effect of cancelling the directed reservations for each slot (see 1.3.16.4.4 and 1.3.16.5.4).
Note 2.— Only the destination station cancels previously placed reservations (e.g. due to a directed request with
the override bit set). Other stations wait until the destination station announces its intent before updating their
reservation table.
1.3.16.3.1.3 The burst is invalid and shall be handled as per 1.3.5, if the frequency (f) subfield reflects the
following:
a) f = 000 hex;
b) f fails to map to a known frequency; or
c) f indicates a frequency on which the transmitter cannot transmit.
1.3.16.3.2 Plea response reception procedures
1.3.16.3.2.1 Upon receipt of a burst containing a plea response reservation (pr_flag = 1), a station shall reserve
the slots equal to “off” after the first slot of the received burst and the series of slots rj for the destination to broadcast.
1.3.16.3.2.2 If the nominal update rate (nr) ≠ special, then rj shall be:
rj = [off + truncate (j • M1/nr) + aj] for j = (1 to N),
where N is the maximum number of additional slots defined in the additional slots (aj) subfield (see 1.3.16.1.2),
1.3.16.3.2.3 If nr = special, then rj shall be defined as:
rj =(off + Σm=1j am) for j = (1 to N)
Note.— Burst length is not included in the plea response, so these reservations are for single slots only.
1.3.16.4 Directed request transmission procedures
1.3.16.4.1 Recommendations
Note.— For the selection of slots for directed request transmission, the general procedures set out in 1.3.6.2 or the
fixed transmission procedures (1.3.8) can be used. Since it is expected that the autotune reservation protocol will be
used only by ground stations, the fixed transmission procedures are recommended and should be implemented in a
manner that takes advantage of ground quarantining (see 1.3.6.4) and causes the formation of contiguous groups of
ground directed slots.
1.3.16.4.1.1 The directed request protocol with plea response flag (pr_flag) = 0 (autotune reservation) should
only be used by ground stations. Stations should use fixed transmission procedures to select slots for transmission of
the autotune reservation burst and to form contiguous blocks of directed reservations.
1.3.16.4.1.2 The transmitting station should ensure that if two users are allocated the same slots, they are
sufficiently separated and on divergent paths so that the possible loss of communications between them is not
significant.
1.3.16.4.2 Autotune transmission procedures
A station sending an autotune reservation (plea response flag pr_flag = 0) to its peer shall set the parameters to the
following values:
— frequency (f) subfield to the frequency on which the responder is to transmit;
— directed offset (do) subfield to either zero (do = 0) (for a directed rate reservation) or the offset from the
first slot of the autotune reservation burst to the first slot in which to transmit (for a directed slot
reservation);
— nominal update rate (nr) subfield to the number of times per M1 (number of slots per superframe) slots that
a response is requested by using the encoding defined in Table II-1-33; and
— directed time out (dt) subfield to the span of (dt • M1) slots over which the destination is to transmit.
The value of the do subfield shall be greater than V52 (do > V52).
1.3.16.4.3 Re-transmission after no response
There shall be no automatic re-transmission of plea response bursts (plea response flag pr_flag = 1). For autotune
reservation bursts (pr_flag = 0), if a response is not received in the first directed slot after the autotune burst was
transmitted, then the station shall re-transmit the autotune reservation burst according to the procedures of 1.3.21.
1.3.16.4.4 Cancellation of autotune reservation
A station shall cancel an autotune reservation (plea response flag pr_flag = 0) by transmitting an autotune reservation
field with the directed time out (dt) subfield set to 15 (dt = 15). It is to set the parameters to the following values:
— frequency (f) subfield to the frequency on which the responder has previously been directed to broadcast;
— directed offset (do) subfield to the offset from the first slot of the autotune reservation burst to the first slot
for which a reservation is to be cancelled; and
— nominal update rate (nr) subfield to the number of slots per M1 slots for which a reservation shall be
cancelled.
Note.— The settings of the directed offset (do) and nominal update rate (nr) subfields are the same as the original
settings used to place the reservations. Hence, this form of autotune reservation can be used to cancel a previous
reservation. This protocol can also be used to cancel a subset of the reports established by the original autotune
command. For example, if the directed reporting rate is 12 reports per minute, a cancellation with nr subfield set to 6
reports per minute would leave a net reporting rate of 6 reports per minute.
1.3.16.4.5 Plea response transmission procedures
1.3.16.4.5.1 A station transmitting a plea response (pr_flag = 1) shall set the parameters to the following values:
— destination (d) to the destination of the burst;
— offset (off) subfield to the offset from the first slot of the reservation burst to the first slot in which to
transmit; and
— nominal update rate (nr) subfield to the nominal number of times per M1 slots that a synchronization burst is
to be sent on the frequency used for transmission.
The value of the offset (off) subfield shall be greater than V52 (off > V52).
1.3.16.4.5.2 A station shall ensure that the slots selected in the transmission satisfy the nominal update rate (nr)
requirements and all of the requirements of 1.3.6.2.
1.3.16.4.5.3 A station shall check to determine if a previous plea response had been sent to the mobile station
making the plea (i.e. the destination ID for this plea response). If a previous plea response had been sent to the mobile
making the plea, the station shall begin the list of reserved slots with the remaining (future) reservations from the
earlier plea response.
Note.— When the plea response can not encode sufficient reservations for a full 60 seconds, the destination station
may issue a subsequent plea as the initial set of reservations is consumed.
1.3.16.5 Directed request response procedures
1.3.16.5.1 Response to an autotune reservation with directed offset (do) greater than one (do > 1)
On receiving an autotune reservation transmission (plea response flag pr_flag = 0) with the directed offset (do) subfield
greater than one (do > 1), the responder station as indicated by the destination address shall set the TV11 (reservation
hold timer) timer (see 1.3.10.2.1) equal to the value of the directed time out (dt) subfield for each of the slots indicated
in the autotune reservation transmission. The responder station shall transmit in each of the reserved slots. Each
response burst shall contain the periodic broadcast reservation field, with periodic offset (po) = 0 and the periodic time
out (pt) = [min(3, TV11 − 1)]. After transmission, the timer TV11 shall be decremented. When TV11 reaches zero
(TV11 = 0), the responder shall not transmit a response to the directed request. Upon cessation of directed
transmissions, the responder shall resume default autonomous behaviour on the GSCs, reserving new slots as required.
Note 1.— As an example, when a station completes its series of directed synchronization burst transmissions on a
local channel, it will resume autonomous synchronization bursts on the GSCs. This behaviour allows a ground station
to implicitly hand off a mobile as the mobile departs a defined airspace, and it also ensures appropriate behaviour if
the mobile unexpectedly flies out-of-coverage or the ground station fails.
Note 2.— When a station is no longer required to transmit a response to the directed request, it will revert to the
autonomous mode.
1.3.16.5.1.1 Recommendation
To simplify and ease the transition from directed slot operations on local channels to directed rate or autonomous mode
operations on another channel, ground stations should attempt to autotune mobile stations (using a directed slot
reservation) to the new channel, for a period of at least 60 seconds, prior to release. The mobile station should then use
the BND reservation to continue the stream while it is building the reservation table and operating under ground control.
1.3.16.5.2 Response to an autotune reservation with directed offset equal to zero
If the directed offset (do) subfield is equal to zero (do = 0), the responder station shall operate autonomously by using
the periodic broadcast procedures with the nominal periodic rate (V11) set to the nominal update rate (nr) in the
autotune reservation transmission for the next (dt • M1) slots, with the first two bits of the message ID (mi) field set to
“00”. Upon cessation of directed transmissions, the responder shall resume default autonomous behaviour on the GSCs,
reserving new slots as required.
Note 1.— As an example, when a station completes its series of directed synchronization burst transmissions on a
local channel, it will resume autonomous synchronization bursts on the GSCs. This behaviour allows a ground station
to implicitly hand off a mobile as the mobile departs a defined airspace, and it also ensures appropriate behaviour if
the mobile unexpectedly flies out-of-coverage or the ground station fails.
Note 2.— When a station is no longer required to transmit a response to the directed request, it will revert to the
autonomous mode.
1.3.16.5.3 Cancellation of autonomous periodic broadcasts
1.3.16.5.3.1 If transmit control (trmt) = 0 and if the responder was transmitting autonomously the VSS user data
for which a directed request reservation has been received, then the responder shall cancel its existing reservations in
accordance with 1.3.10.5.9, and operate in accordance with the parameters of the directed request.
1.3.16.5.3.2 If transmit control (trmt) = 1 and if the responder was transmitting autonomously on the channel on
which a directed request reservation was received, then the responder shall maintain its autonomous transmissions on
the channel.
1.3.16.5.4 Cancellation of directed request broadcasts
If the responder receives a directed request reservation burst with the directed time out (dt) subfield set to 15 (dt = 15),
then it shall cancel its existing reservations in accordance with 1.3.10.5.9.
1.3.16.5.5 Response if unable to support directed request
If the responder is unable to support the directed request, it shall transmit a GENERAL FAILURE (see 1.3.20.1) with
error type (err) = 05 hex. If there are insufficient receiver resources to meet the request, it shall set bit 1 of the
parameter subfield to one. All other bits in the parameter subfield shall be set to zero.
1.3.16.5.6 Recommendation
If possible, a responder sending a GENERAL FAILURE should use slots reserved by the ground station on the channel
as indicated in the directed request. Otherwise, the station should use the combined periodic/incremental reservation
protocol to place the transmission on the channel on which the directed request was received.
1.3.17 Block reservation protocol specification
Note.— These block reservation protocols are intended for a VSS ground station which has to reserve a block of
slots for its own ground station use. The superframe block reservation protocol establishes a series of blocks of slots in
which no other station is allowed to place a reservation or to transmit. The second frame block reservation protocol
establishes a block at the beginning of each UTC second. Network entry transmissions are also prohibited (see
1.3.6.4.3) in both types of blocks. The superframe block reservation protocol provides a facility for rebroadcasting of
the block reservation by a mobile.
1.3.17.1 Superframe block reservation burst format
A reservation ID (rid) = 0, an extended reservation ID (erid) = 110, and reservation fields set in accordance with
Table II-1-40 (with subfields defined in accordance with Table II-1-41) shall indicate a superframe block reservation.
The information (in) field shall be extended up to the last 9 octets prior to the CRC. A burst containing a superframe
block reservation shall not exceed 21 octets (not including the CRC).
Table II-1-40. Superframe block reservation bit encoding
Bit number
n−9 d16 d15 d14 d13 d12 d11 d10 d9
n−8 d8 d7 d6 d5 d4 d3 d2 d1
block length (blg) n−7 blg5 blg4 blg3 blg2 blg1 d27 d26 d25
rebroadcast offset (roff) n−6 roff8 roff7 roff6 roff5 roff4 roff3 roff2 roff1
block repeat rate (br) n−5 res res res res br4 br3 br2 br1
block start (bs) n−4 bs8 bs7 bs6 bs5 bs4 bs3 bs2 bs1
block offset (bo) n−3 bo8 bo7 bo6 bo5 bo4 bo3 bo2 bo1
extended reservation ID (erid), block n−2 0 0 0 1 0 res bt2 bt1
time out (bt)
Table II-1-41. Superframe reservation field encoding

block time out (bt) 0 to 3 (bt • M1) = the number of slots for
which the block reservation should be
maintained.
block repeat rate (br) 1 to 60 See Table II-1-33. Codes Defines the number of blocks per
0111, 1110 and 1111 are minute.
invalid.
rebroadcast offset 2 to 255 bs = 0, 1 invalid roff indicates the slot in which the
(roff) rebroadcast transmission should be
made.
block start (bs) 2 to 255 bs = 0, 1 invalid bs identifies a slot relative to the
transmission slot which is the first slot
of the first reserved block.
block offset (bo) –127 to +127 Two’s complement math bo identifies an offset of each reserved
block at a future time defined by [bt •
M1].
block length (blg) 0 to 31 blg is one less than the number of slots
reserved for the block.
destination address See Table II-1-27. Ignored if ro = bs and octets d is the 27-bit address of the destination
(d) (n–10) through (n–8) station which is required to rebroadcast
available for use within the the blocking message.
information field.
1.3.17.2 Second frame block reservation burst format
A reservation ID (rid) = 0, an extended reservation ID (erid) = 00011, and reservation fields set in accordance with
Table II-1-42 (with subfields defined in accordance with Table II-1-43) shall indicate a second frame block reservation.
The information (in) field shall be extended up to the last 2 octets prior to the CRC.
Table II-1-42. Second frame block reservation bit encoding
Bit number
time out (vt) n–3 vt6 vt5 vt4 vt3 vt2 vt1 sz5 sz4
size (sz) n–2 0 0 0 1 1 sz3 sz2 sz1
Table II-1-43. Second frame block reservation field encoding
Subfield Range Definitions

size (sz) 0 to 31 Number of slots to block after the start
of each UTC second
time out (vt) 1 to 60 Value of TV61 (second frame block
reservation time out)
1.3.17.3 Superframe block reservation parameters
The superframe block reservation protocol shall implement the system parameters defined in Table II-1-44. For each
superframe block reservation, the VSS user shall provide one or more sets of parameters consisting of:
a) the time of the required superframe block ground transmission;
b) the parameters V61 and V65 for which the default values are not desired; and
c) QoS parameters (Q2a to Q2d, Q4 and Q5) for which the default values are not desired.
The station shall use the first set of parameters to calculate the position and subfield settings for the first ground station
transmission as specified in 1.3.17.7.1 and then use each of the following set to move the position of the reserved
blocks. Where possible, the station shall announce in advance that a block is to move by using the block offset (bo)
subfield as defined in 1.3.17.7.1.
Table II-1-44. Superframe block reservation VSS system parameters
Symbol Parameter name Minimum Maximum Default Increment

V61 Superframe block start 2 255 20 1
offset
V62 Superframe block length 1 32 3 1
V63 Superframe block repeat 1 60 5 See Table II-1-33 for
rate allowed values.
V64 Superframe block No Yes No —
rebroadcast request
V65 Superframe block 2 255 10 1
rebroadcast offset
1.3.17.3.1 Parameter V61 (superframe block start offset)
Parameter V61 shall be the offset to the start of the first reserved block from the slot containing the ground transmission.
1.3.17.3.2 Parameter V62 (superframe block length)
Parameter V62 shall be the length in slots of each reserved block.
1.3.17.3.3 Parameter V63 (superframe block repeat rate)
Parameter V63 shall be the number of reserved slots per M1 (number of slots per superframe) slots that are encoded as
defined in Table II-1-33.
1.3.17.3.4 Parameter V64 (superframe block rebroadcast request)
Parameter V64 shall determine whether the superframe block reservation request is to be rebroadcast by a mobile using
the procedures defined in 1.3.17.7.2.
1.3.17.3.5 Parameter V65 (superframe block rebroadcast offset)
Parameter V65 shall be the offset to the slot containing the rebroadcast from the slot containing the ground transmission.
1.3.17.4 Superframe block reservation reception procedures
1.3.17.4.1 Upon receipt of a burst containing a superframe block reservation, the station shall update its
reservation table and carry out the actions as specified in Tables II-1-45 and II-1-46.
Table II-1-45. Actions on receipt of a superframe block reservation burst
Block start Block offset Block time out

(bs) (bo) (bt) Action
bs < 2 Any Any Invalid
bs ≥ 2 Any except 0 0, 1, 2 Reserve the following slots for the source or for a mobile directed by
the source to broadcast:
if bt = 1 or 2, then for j = [0 to bt] and k = (0 to br – 1), the slots =

{truncate [bs + (k • M1/br) + j • M1]} through {blg + truncate [bs + (k •
M1 / br) + j • M1]} after the first slot of the received burst
AND
for j = [(bt + 1) to 3] and k = [0 to (br – 1)], the slots = {truncate [bs +

bo + (k • M1/br) + j • M1]} through {blg + truncate [bs + bo + (k • M1 /
br) + j • M1]} after the first slot of the received burst.
bs ≥ 2 0 0, 1 or 2 Reserve the following slots for the source or for a mobile directed by
Block start Block offset Block time out

(bs) (bo) (bt) Action
for j = 0 to bt and k = 0 to (br – 1), the slots = {truncate [bs + (k •
M1/br) + j • M1]} through {blg + truncate [bs + (k • M1/br) + j • M1]}
Thereafter, terminate the reservations.

bs ≥ 2 Any 3 Reserve the following slots for the source or for a mobile directed by
for j = [0 to bt] and k =[ 0 to (br − 1)], the slots = {truncate [bs + (k •

M1/br) + j • M1]} through {blg + truncate [bs + (k • M1/br) + j • M1]}
Table II-1-46. Further actions on receipt of a superframe block reservation burst
Block offset Block time out

(bo) (bt) Action
Any except 0 0, 1, 2 Reserve the following slots for the source to broadcast:
if bt = 1 or 2, then for j = [1 to bt[, the slot = (j • M1) after the first slot of the received
burst
AND
for j = (bt + 1 to 3), the slot = (bo + j • M1) after the first slot of the received burst.
0 0, 1 or 2 Reserve the following slots for the source to broadcast:
for j = (1 to bt), the slot = (j • M1) after the first slot of the received burst

Any 3 Reserve the following slots for the destination to broadcast:
for j = (1 to bt), the slot = (j • M1) after the first slot of the received burst.
Note 1.— The actions defined in Table II-1-45 establish a series of reserved blocks of slots.
Note 2.— The actions in Table II-1-46 reserve the slot used by the station to provide a superframe block
reservation in subsequent superframes.
1.3.17.4.2 If the rebroadcast offset (roff) is not equal to the block start (bs) (roff bs), the station shall carry out
the actions specified in Table II-1-47.
Table II-1-47. Action on receipt of a superframe block reservation burst if roff bs
Rebroadcast Block offset Block time out

offset (roff) (bo) (bt) Action
roff < 2 Any Any Invalid
roff ≥ 2 Any except 0 0, 1, 2 Reserve the following slots for the destination to broadcast:
if bt = 1 or 2, then for j = (0 to bt), the slot = (roff + j • M1)

after the first slot of the received burst
Rebroadcast Block offset Block time out

offset (roff) (bo) (bt) Action
AND
for j = (bt + 1 to 3), the slot = (roff + bo + j • M1) after the first slot of the
received burst.
roff ≥ 2 0 0, 1 or 2 Reserve the following slots for the destination to broadcast:
for j = 0 to bt, the slot = (roff + j • M1) after the first slot of the
received burst.

roff ≥ 2 Any 3 Reserve the following slots for the destination to broadcast:
for j = 0 to bt, the slot = (roff + j • M1) after the first slot of the received
burst.
Note.— The actions in Table II-1-47 are carried out if a ground station wishes to rebroadcast the block message
via a mobile.
1.3.17.5 Second frame block reservation parameters
The VSS user shall provide a value for the parameter TV61 (defined in Table II-1-48) for which the default values are
not desired. For each second frame block reservation, the VSS user shall provide one or more sets of parameters
consisting of the parameters V66 and V67 for which the default values are not desired and QoS parameters (Q2a to
Q2d, Q4 and Q5) for which the default values are not desired.
1.3.17.5.1 Timer TV61 (second frame block reservation time out)
The timer TV61 shall control the time in which a second frame block reservation is valid. When timer TV61 times out,
the mobile station shall return to the initial state defined in Table II-1-48.
Table II-1-48. Second frame block reservation parameters

TV61 Second frame block 1 superframe 60 superframes 4 superframes 1 superframe
reservation time out
V66 Second frame block size 0 31 8 1
V67 Second frame block repeat 0 60 3 See Table II-1-33
rate for allowed values.
1.3.17.5.2 Parameter V66 (second frame block size)
Parameter V66 shall be the size of the second frame block.
1.3.17.5.3 Parameter V67 (second frame block repeat rate)
Parameter V67 shall be the number of times per M1 (number of slots per superframe) slots that a second frame
reservation transmission is repeatedly encoded as defined in Table II-1-33.
1.3.17.6 Second frame block reservation reception procedures
Upon receipt of a burst containing a second frame block reservation, the station shall update its reservation table by
reserving the first size (sz) slots of every UTC second and set the timer TV61.
1.3.17.7 Superframe block reservation transmission procedures
Note.— For the selection of slots for superframe block transmission, the general procedures set out in 1.3.6.2 or
the fixed transmission procedures (see 1.3.8) can be used. Since it is expected that the superframe block reservation
protocol will be used only by ground stations, the fixed transmission procedures are recommended.
The superframe block reservation protocol should only be used by ground stations and fixed transmission procedures
used to select slots for transmitting the superframe block reservation bursts. The superframe block reservation protocol
should only be used by a mobile that is under the direction of a ground station that has already issued a superframe
block reservation burst, where the rebroadcast offset (roff) subfield is not equal to the block start (bs) subfield
(roff bs).
1.3.17.7.2 Procedures for establishment of reserved blocks of slots
A station shall establish reserved blocks of slots by broadcasting a superframe block reservation. The station shall set
the parameters to the following values:
— block start (bs) subfield to the offset from the first slot of the transmitted burst to the first slot of the first
reserved block of slots as defined by parameter V61;
— block repeat rate (br) subfield to the number of blocks per M1 slots as defined by V63 by using the encoding
defined in Table II-1-33;
— block length (blg) equal to one less than V62; and
— block time out (bt) subfield to the span of (bt • M1) slots over which the reservations defined by block start
(bs) and block repeat rate (br) are to be maintained.
If the value of block time out (bt) is equal to zero, one or two (bt = 0, 1, or 2), the value of the block offset (bo)
subfield shall be set to zero (bo = 0) if it is intended that the superframe block reservation will terminate after [bt • M1]
slots. Otherwise, the value of the bo subfield shall be set to the offset from the first slot of the first reserved block if it is
intended that the block reservation will move after [bt • M1] slots. The value of bt shall not be set to –128.
1.3.17.7.3 Cancellation of reserved blocks of slots
A station shall cancel a superframe block reservation by transmitting a superframe block reservation field with block
time out (bt) equal to zero, one or two (bt = 0, 1, or 2) and block offset (bo) equal to zero (bo = 0). In such a case, the
superframe block reservation will be cancelled after [M1 • bt + bs] slots. The station shall set the parameters to the
following values:
— block start (bs) to the offset from the first slot of the transmitted burst to the first slot of the first block for
which a reservation is to be cancelled as defined by parameter V61;
— block length (blg) equal to one less than V62; and

— block repeat rate (br) subfield to the number of blocks per M1 slots as defined by parameter V63 by using
the encoding defined in Table II-1-33.
Note.— The settings of the block start (bs) and block repeat rate (br) subfields are the same as the original settings
used to place the reservations.
1.3.17.7.4 Procedures to request rebroadcasting of a superframe block reservation
1.3.17.7.4.1 To request that mobile station B rebroadcast a superframe block message, ground station A shall
transmit a superframe block reservation. Station A shall set the destination (d) to the address of station B and set the
rebroadcast offset (roff) subfield to the offset from the first slot of the reservation burst to the first slot in which B
should transmit. The value of the roff subfield shall be less than the value of the block start (bs) subfield (roff < bs).
1.3.17.7.4.2 If no rebroadcast of the superframe block message is required, the ground station A shall set the
rebroadcast offset (roff) subfield equal to the block start (bs) subfield (roff = bs) and shall not include a destination
subfield.
Note.— The ground station A establishes a reservation for mobile station B to respond with the rebroadcasted
superframe block message.
1.3.17.8 Procedures for responding to a rebroadcast request for superframe block reservation
On receiving a superframe block reservation, mobile station B shall transmit a superframe block reservation in the
directed slot. The mobile station B shall set the block repeat rate (br), block offset (bo) and block time out (bt) subfields
to the values contained in the received burst. The mobile station B shall then set the block start (bs) to indicate the same
first slot of the first block as was directed in the received superframe block reservation, calculated relative to the first
slot of the transmission. The mobile station B shall also set the rebroadcast offset (roff) subfield equal to the bs subfield
(roff = bs) and shall not include a destination subfield.
1.3.17.9 Second frame block reservation transmission procedures
A ground station infrastructure which needs to maintain a VLMC should not set the size (sz) subfield to zero.
Note.— The second frame block reservation protocol is used to extend or reduce the VLMC.
1.3.17.9.2 Procedures for establishment of reserved blocks of slots
When a ground station wishes to modify the length of the reserved blocks of slots in each second, it shall broadcast a
second frame block reservation, V67 times per M1 slots. The station shall set the block size (sz) subfield to the desired
number of slots after the start of each UTC second as defined by parameter V66.
1.3.18 Response protocol specification
1.3.18.1 Response burst format
A reservation ID (rid) = 0 with extended reservation ID (erid) = 00000binary and reservation fields set in accordance
with Table II-1-49 shall indicate a response burst. In case the address type field (see 1.3.14.1) is equal to seven, bits 1
through 24 of the destination subfield shall be absent and the information field shall be extended up to the last 1 octet
prior to the CRC. Otherwise, the information field shall be extended up to the last 4 octets prior to the CRC and the
destination subfield shall be the 27-bit address of the destination station (for which the response is addressed). No
reservation shall be made after a response burst is received. The VSS user shall provide the destination address.
Table II-1-49. Response burst reservation bit encoding
Bit Number
n−4 d16 d15 d14 d13 d12 d11 d10 d9
n−3 d8 d7 d6 d5 d4 d3 d2 d1
reservation ID (rid) n−2 0 0 0 0 0 d27 d26 d25
Note 1.— In the typical application, the response will be broadcast; however, some applications might require a
unicast response.
Note 2.— The response burst with the address type field set equal to seven is intended as an alternative to the null
reservation type defined in 1.3.9.
1.3.19 General request protocol specification
1.3.19.1 General request burst format
1.3.19.1.1 To request a peer station to transmit a particular burst, a station shall send the burst described in
Table II-1-50 to the desired destination station. VSS user-specific parameters (prm) shall be encoded by starting in the
octet following the most significant (high order) bit of the requested message ID (r-mi) field. Unused bits (x) shall be
filled with zero (x = 0) on TRANSMIT and ignored on RECEIVE.
1.3.19.1.2 The values of the subfields shall be computed as defined in Table II-1-51.
1.3.19.1.3 The requested message ID (r-mi) shall define the VSS user (in accordance with Table II-1-6) which is
responsible for handling the request.
Table II-1-50. General request bit encoding
Bit number
5 r-mi 5 ...... r-mi1 0 0 1
requested message ID (r-mi) 6 x r-min ...... r-mi2
VSS user specific parameter (prm) 7 to n-3 prm11
n-2 prmk8
Note.— . . . . . . . . denotes variable length field.

Table II-1-51. General request field encoding

requested message ID See 1.3.2.3.
(r-mi)
VSS user specific This is an optional field defined by the
parameter (prm) VSS user.
1.3.19.2 General request procedures
1.3.19.2.1 Requester action
For a VSS user to request that a peer VSS user transmit (either broadcast or unicast request response) certain
information, the VSS user shall transmit a general request burst with the requested message ID (r-mi) field set to the
desired response. The unicast request reservation field shall be used if a single response is required from a single
station. Otherwise, the directed request reservation field shall be used if multiple responses are required from a single
station.
1.3.19.2.2 Responder action
The addressed responder(s) shall respond in the indicated slots with the requested bursts, except for the conditions
specified in 1.3.6.5 regarding reservation conflicts.
1.3.19.2.3 Exceptional cases
1.3.19.2.3.1 If the requested function is not supported, the responder shall send a GENERAL FAILURE (see
1.3.20) with the parameters set to the following values:
— confirm/failure flag (ok) bit set to zero (ok = 0);
— requested message ID (r-mi) field set to the requested VSS user (r-mi = VSS user);
— backoff delay (bd) set to FF hex (bd = FF hex); and
— error type (err) set to 00 hex (err = 00 hex) (if that ground station does not support the requested function
but other ground stations in the same system could support it).
1.3.19.2.3.2 If the requested function is supported but there has been no response in time for transmission in the
reserved slot, then the responder shall transmit a GENERAL FAILURE (see 1.3.20) with the parameters set to the
following values:
— confirm/failure flag (ok) bit set to zero (ok = 0);
— requested message ID (r-mi) and extended reservation ID (erid) fields set to the requested VSS user
(r-mi = VSS user, erid = VSS user);
— backoff delay (bd) set to an estimate of when the data will be available; and
— error type (err) set to either 7E hex or FE hex (err = 7E hex or err = FE hex).
Ground stations shall use 7E hex to indicate that mobile stations might get a quicker response via a different ground
station. A ground station not capable of responding because of network problems shall use the error type (err) of either
03 hex (if no response can be expected) or 04 hex (if a response can be expected but will be delayed).
1.3.20 General response protocol specification
1.3.20.1 General response burst format
1.3.20.1.1 A station shall transmit a general response burst (either a GENERAL FAILURE or a GENERAL
CONFIRM) as defined in Table II-1-52 (with the parameters defined in Table II-1-53) in response to certain requests
from another station. The requested message ID (r-mi) shall indicate the identity of the peer VSS user to which a
response is being generated. The general response burst shall include one of the following reservation fields: unicast
request reservation, information transfer request or response. The destination (d) subfield contained in the reservation
field shall indicate to which VSS user the response is being directed.
Table II-1-52. General response bit encoding
Bit number
Confirm/failure flag (ok) 5 ok 1 1 1 0 1 0 1
Requested message ID (r-mi) 6 res r-mik ... r-mi1
Backoff delay (bd) 7 bd8 bd7 bd6 bd5 bd4 bd3 bd2 bd1
error type (err) 8 err8 err7 err6 err5 err4 err3 err2 err1
VSS user specific 9 to n-3 prm11
parameter (prm) n-2 prmk8
Table II-1-53. General response field encoding

confirm/failure flag (ok) 1 = GENERAL CONFIRM 0 =
GENERAL FAILURE
Requested message ID See 1.3.2.3. Can extend into octet 7 for long
(r-mi) extended ids.
backoff delay (bd) 0 to 255 integer seconds, FF hex = forever In seconds, ignore on
CONFIRM.
error type (err) See Table II-1-54.
VSS user specific Defined by the VSS user.
parameter (prm)
1.3.20.1.2 The requested message ID (r-mi) shall define the VSS user (in accordance with Table II-1-6), which is
responsible for handling the response.
1.3.20.1.3 If the confirm/failure flag (ok) bit is set to one (ok = 1) (i.e. a GENERAL CONFIRM), and the
response does not utilize the parameter field, the information (in) field shall contain the requested message ID (r-mi)
subfield only while the remaining parameters shall be omitted. If the ok bit is set to one (ok = 1) and the parameter field
is used, then the backoff delay (bd) and error type (err) fields shall be included and set to 00 hex. If the ok bit is set to
zero (ok = 0) (i.e. a GENERAL FAILURE), then the remaining parameters shall define the reason why the request
failed.
1.3.20.1.4 The error type (err) shall be encoded in accordance with Table II-1-54; err of 00 hex to 7F hex shall
apply to the responding station; and err of 80 hex to FF hex shall apply to the responding system.
a) A VSS user receiving a GENERAL FAILURE with err < 80 hex shall not transmit another request to that
peer station for the duration of time designated by the backoff delay (bd) subfield (in seconds).
b) A VSS user receiving a GENERAL FAILURE with err > 7F hex shall not transmit another request to that
peer system for the duration of time designated by the backoff delay (bd) subfield (in seconds).
Note.— A mobile VSS user receiving a ground station-based error type (err) from one ground station may
immediately transmit the same request to another ground station of the same ground system.
Table II-1-54. Error type (err) definition
Parameter encoding
(prm bits 1 to 8)
Cause Function 8 7 6 5 4 3 2 1
00 hex Unsupported local function. 0 0 0 0 0 0 0 0
The parameters (defining the protocol options supported) will
be filled in when defined.
01 hex Out of local resources. Reserved.
02 hex VSS user-specific local error. Defined by the VSS user.
03 hex Terrestrial network not available.
04 hex Terrestrial network congestion. Reserved.
05 to 7D hex Reserved. Set to 0 on TRANSMIT, ignore on
RECEIPT.
7E hex No response from VSS user.
7F hex Other unspecified local reason.
80 hex Unsupported global function. 0 0 0 0 0 0 0 0
The parameters (defining the protocol options supported) will
be filled in when defined.
81 hex Out of global resources. Reserved.
82 hex VSS user-specific global error. Defined by the VSS user.
83 to FC hex Reserved.
Reserved.
FD hex Rejected for internal policy reasons.
Set to 0 on TRANSMIT, ignore on
FE hex No response from VSS user. RECEIPT.
FF hex Other unspecified system reason.
1.3.20.2 General response procedures
1.3.20.2.1 If a reservation for a response or an acknowledgement has been placed but the VSS sub-layer has
received neither the response nor the acknowledgement from the VSS user in time for the scheduled reservation, the
station shall send a GENERAL FAILURE (see 1.3.20) with cause code 7E hex or FE hex.
1.3.20.2.2 If a response is received, the VSS shall inform the VSS user.
1.3.21 Re-transmission procedures
1.3.21.1 After transmitting a burst containing a reservation for a peer station (i.e. unicast request reservation,
directed request reservation, and information transfer request reservation) and not receiving a response by the expected
slot, a station shall either re-transmit the request or inform the VSS user and LME if Q5num (number of attempts)
attempts have already been made or if more than Q5wait (maximum time to wait for a reply) seconds have elapsed since
the VSS user initiated the request.
Note.— If Q5num = 1, no re-transmission is attempted and therefore parameters Q5max (maximum),

Q5min (minimum), Q5mult (multiplier), and Q5exp (exponent) are not used.
1.3.21.2 The re-transmitting station shall wait for {Q5min + [U(x), Q5max] min} seconds before attempting to re-
transmit the burst, where:
U(x) is a uniform random number generated between 0 and x;

x is defined by Q5mult • (Q5expretrans) • M1 / ((M1 + 1) − u);
u is the number of occupied slots within the preceding minute on the channel
concerned;
retrans is the number of times that a burst has been re-transmitted.
1.4 DATA LINK SERVICE (DLS) SUB-LAYER
The DLS shall support communications on a shared communications channel as described in this section.
1.4.1 Services
1.4.1.1.1 The DLS shall support bit-oriented simplex communications by using a network set-up connection
orientated protocol (NSCOP) and a zero overhead connection orientated protocol (ZOCOP) between DLE pairs.
Note 1.— It is intended that NSCOP be used for air/ground (A/G) communications and ZOCOP for air/air (A/A)
communications.
Note 2.— Apart from the procedures for link set-up and tear down, the NSCOP and ZOCOP protocols operate
identically.
Note 3.— Any two stations have one DLE pair per frequency.
1.4.1.1.2 The DLS shall support broadcast and multicast connectionless communications.
1.4.1.1.3 The DLS shall provide the following services:
a) transmission of user data,
b) indication that user data has been sent,

c) reception of user data,
d) indication that the DLS link has been established, and
e) indication that the DLS link has been broken.
1.4.1.1.4 Stations supporting the communications functionality provided by the DLS shall simultaneously
support at least 8 peer-to-peer links with other stations.
1.4.1.1.5 Stations not supporting the communications functionality provided by the DLS shall implement 1.4.2.2
and 1.4.4.7 only.
1.4.1.2 Data transfer
User data packets and LME data shall be transferred in the information fields of INFO, UDATA, and CTRL data link
protocol data units (DLPDUs), all collectively known as DATA DLPDUs. LME data shall be contained in CTRL and
UCTRL frames only. The link layer shall process the largest packet size, specified in 1.4.3.5 of this document, without
fragmenting. Larger packets shall be fragmented according to the procedures of 1.4.4.3.2. Only one data link user
packet shall be contained in a DATA DLPDU.
Note 1.— The Frame Mode Subnetwork Dependent Convergence Function (SNDCF) may concatenate multiple
packets, but this is presented as a single user data packet to the DLS.
Note 2.— UDATA DLPDUs consist of UINFO DLPDUs for broadcast of user data packets, and UCTRL DLPDUs
for broadcast of LME data. UDATA is the broadcast equivalent of DATA and embraces all broadcast-type DLPDUs.
1.4.1.3 DATA DLPDU duplicate suppression and sequencing
On a point-to-point connection, the receiving DLS sub-layer shall ensure that duplicated DATA DLPDUs are discarded
and that all DATA DLPDUs which are part of a fragmented packet are delivered in the same order in which they
appear in the packet.
Note.— To facilitate duplicate suppression, a Toggle bit is included in the DLS DLPDU format.
1.4.1.4 Error detection
The DLS shall rely on the MAC layer to ensure that DLPDUs corrupted during transmission are detected and discarded.
Note.— A 16-bit CRC is provided in the burst format to support this error detection service. The MAC layer will
reject corrupted packets.
1.4.1.5 Station identification
A receiving station shall accept unicast DLPDUs addressed to its current station address.
Note.— Unique source and destination addresses are included in the VDL Mode 4 DLS burst format in order to
facilitate station identification. DLPDUs addressed to the current station address are routed to the DLS by the VSS.
However, non-unique addressing is possible — with the resultant communications risk minimized through the
assurance that any link address is locally unique. The ATN requires a unique address, hence non-unique addressing is
not used with the ATN.
1.4.1.6 Broadcast addressing
A VDL Mode 4 station shall accept broadcast DLPDUs and accept multicast DLPDUs that have been multicast to
addresses to which it is listening.
1.4.1.7 DLS priority
The DLS shall accept an indication of the priority of the DATA DLPDU as defined in Table II-1-11.
Note.— The DLS service user’ s selection of priority affects the QoS parameters used in the transfer of the DLS
user packet as well as the queuing of the packet.
1.4.1.8 DLS link control DLPDUs
For the purposes of link control, the DLS shall provide the following DLS DLPDU types:
a) ACK (acknowledgment) DLPDUs, consisting of INFO_ACK and CTRL_ACK, for the purposes of
acknowledging DATA DLPDUs and DLS link control DLPDUs, respectively.
b) RTS (Request to Send) DLPDUs, consisting of CTRL_RTS, INFO_RTS and UDATA_RTS, for the purposes
of making reservations for the transfer of DATA DLPDUs.
c) CTS (Clear to Send) DLPDUs, consisting of CTRL_CTS, INFO_CTS and UDATA_CTS, for the purposes of
acknowledging RTS DLPDUs and providing slots for subsequent transmission of DATA DLPDUs.
d) Other DLS link control DLPDUs, consisting of FRMR (frame reject), FRMR_ACK, DM/DISC and
DM/FRMR (Disconnect Mode DLPDUs), and SZOM (start zero overhead mode), for purposes of link
initialization, reset and maintenance.
1.4.2 DLS protocol specification
1.4.2.1 State variables
The DLS shall maintain the following state variables for each data link between two peer stations:
State variable Usage

TT Current value of Toggle bit (T) (0 or 1) for transmitted DLPDUs
TR Value of Toggle bit (T) (0 or 1) for last received DLPDU.
SEND array An array storing user data packets and more bit (M) linked
fragments queued for transmission (one per priority level)
RECEIVE array An array storing received more bit (M) linked fragments queued
for concatenation (one per priority level)
Note.— If the link is reset for any reason, the DLS will discard any fragments associated with a partially sent
packet
1.4.2.2 Station address encoding
1.4.2.2.1 Address type
The address type field is defined in Table II-1-55.
Table II-1-55. Address type field encoding
Bit encoding Description type Bits 1 to 24

27 26 25
0 0 0 Mobile Non-unique identity
0 0 1 Aircraft 24-bit ICAO address
0 1 0 Ground vehicles Nationally administered address space
0 1 1 Reserved Future use
1 0 0 Ground station ICAO-administered address space
1 0 1 Ground station ICAO-delegated address space
1 1 0 Reserved Future use
1 1 1 All stations broadcast All stations
1.4.2.2.2 Non-unique identity address
1.4.2.2.2.1 A mobile station using the non-unique identity address shall randomly choose a 24-bit address. The
non-unique identity address of all zeros (“ 0” ) shall not be used. The non-unique identity address of all ones (“ 1” ) shall
be used for broadcast applications only. All radio units located at a station shall use the same non-unique identity
address.
1.4.2.2.2.2 If the station detects another station using the same random address, it shall stop transmitting on the
current address. It shall then randomly select a new address that is not already present in its Peer Entity Contact Table
(PECT) and shall use this new address in subsequent transmissions.
Note 1. — The processing of ambiguous data resulting from use of the non-unique address is an end system issue.
1.4.2.2.2.3 When using VDL Mode 4 for Air Traffic Service (ATS) applications, aircraft shall use the unique
24-bit ICAO address.
Note 2.— In this case, bits 25, 26, and 27 of the full 27-bit address will be 1, 0, and 0 respectively, as defined in
Table II-1-55.
Note 3.— Mobiles using non-unique addresses cannot be unambiguously identified and this mode of use is itself
inherently insecure. Higher level functions are required when there is a need to provide data origin authentication in
case non-unique addresses are used.
Note 4.— Non-unique addressing violates the subnetwork requirements of the ICAO ATN, and mobiles using this
addressing mode cannot implement ATN applications.
1.4.2.2.3 Aircraft specific addresses
The aircraft specific address field shall be the 24-bit ICAO aircraft address.
1.4.2.2.4 ICAO-administered ground station specific addresses
The ICAO-administered ground station specific address shall consist of a variable length country code prefix (using the
same country code assignment defined in Annex 10 — Aeronautical Telecommunications, Volume III, Part I — Digital
Data Communication System, Chapter 9, Appendix to Chapter 9, Table 9-1) and a suffix. The appropriate authority
shall assign the bits in the suffix.
1.4.2.2.5 ICAO-delegated ground station specific addresses
The ICAO-delegated ground station specific address shall be determined by the organization to which the address space
is delegated.
1.4.2.2.6 Broadcast and multicast addresses
The broadcast and multicast addresses shall be used only as a destination address for UDATA DLPDUs.
1.4.2.2.6.1 Broadcast and multicast address encoding
The broadcast and multicast addresses shall be encoded as in Table II-1-56.
Table II-1-56. Broadcast and multicast address encoding
Broadcast destination Type field Specific address field

All mobiles that use non-unique addresses 000 All ones (“ 1” )
All mobiles 001 All ones (“ 1” )
All ground stations of a particular provider 100 or 101, as necessary Most significant bits: Variable length
provider code
Remaining bits: All ones (“ 1” )
All ground stations with ICAO-administered 100 All ones (“ 1” )
addresses
All ground stations 101 All ones (“ 1” )
All stations 111 All ones (“ 1” )
1.4.2.3 DLS burst formats
1.4.2.3.1 DLS burst
1.4.2.3.1.1 A DLS station shall transmit the DLS burst defined in Table II-1-57, with the VSS user-supplied QoS
and reservation parameters.
Note 1.— The DLS DLPDU field may continue past octet 10.
1.4.2.3.1.2 The DLS burst shall consist of one or two DLS DLPDUs combined according to the procedures of
1.4.4.12. A DATA DLPDU shall be the final field in the burst (and thus the burst can contain only one of these fields).
Note 2. — The DLS burst will be able to combine up to two DLPDUs. DATA and UDATA must come last because
they are variable length DLPDUs.
Table II-1-57. Normal unicast DLS burst format
Bit Number
message ID 5 res res res res 1 1 0 1
6
7
DLS DLPDU 8 As per 1.4.2.3.2.
9
10
Note.— All bits labelled “ res” are reserved and shall be set to “ 0” .
1.4.2.3.2 DLS DLPDU encoding
1.4.2.3.2.1 The DLS DLPDU field shall indicate the DLPDU type and contain, as appropriate, the priority (pr),
the more bit (M), the Toggle bit (T), the Initialize bit (IB) and length (lg) subfields.
1.4.2.3.2.2 The DATA DLPDUs shall consist of a single octet containing link control information and a variable
length information (in) field, and shall be encoded as defined in Table II-1-57a.
Table II-1-57a. DATA DLPDU encoding
Octet n n+1 .................. n+lg

Bit 8 7 6 5 4 3 2 1
CTRL M T re c/r res 0 0 0 information field of length lg octets
INFO M T pr4 pr3 pr2 pr1 1 0 information field of length lg octets
Reserved X X X X 0 1 0 0 information field of length lg octets
Reserved 0 0 0 0 1 1 0 0 information field of length lg octets
Reserved X X X 1 1 1 0 0 information field of length lg octets
Reserved X X 1 0 1 1 0 0 information field of length lg octets
Reserved X 1 0 0 1 1 0 0 information field of length lg octets
Reserved 1 0 0 0 1 1 0 0 information field of length lg octets
Note.— “ X” means 0 or 1; M is more bit; T is Toggle bit; c/r is command/response status bit; re is response expected; IB is
Initialize bit; pr is priority; ucid is UCTRL ID; n is DATA DLPDU octet.
1.4.2.3.2.3 The command/response (c/r) bit indicates whether the CTRL DLPDU is a command (c/r = 0) or
response (c/r = 1). The response expected (re) bit indicates whether a response is expected (re = 1) or not (re = 0).
These subfields are defined in 1.5.2.6 and 1.5.3.3.2. The UCTRL ID (ucid) subfield, is defined in 1.5.2.6.
1.4.2.3.2.4 The RTS DLPDUs consist of 2 octets containing link control information and shall be encoded as
defined in Table II-1-57b.
1.4.2.3.2.5 The ACK, CTS and other DLS link control DLPDUs shall consist of 1 octet containing link control
information. These DLPDUs shall be encoded as defined in Table II-1-57c.
1.4.2.3.2.5.1 A station receiving a reserved DLPDU from a peer with which it has a link shall reset the link in
accordance with the procedures of 1.4.4.11. A station receiving a reserved DLPDU from a peer with which it does not
have a link shall either respond with a DM/DISC, DM/FRMR or simply ignore the DLPDU.
Table II-1-57b. RTS DLPDU encoding
Octet n n+1
Bit 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
CTRL_RTS 0 T IB 0 1 0 0 1 res res res res lg4 lg3 lg2 lg1
INFO_RTS 0 T 0 1 1 0 0 1 pr4 pr3 pr2 pr1 lg4 lg3 lg2 lg1
UDATA_RTS 0 0 1 1 1 0 0 1 pr4 pr3 pr2 pr1 lg4 lg3 lg2 lg1
SZOM neg4 neg3 neg2 neg1 1 1 0 1 seq8 seq7 seq6 seq5 seq4 seq3 seq2 seq1
Reserved lg5 1 1 1 1 0 0 1 pr4 pr3 pr2 pr1 lg4 lg3 lg2 lg1
Reserved 1 X X 0 1 0 0 1 X X X X X X X X
Reserved 1 X 0 1 1 0 0 1 X X X X X X X X
Reserved 1 0 1 1 1 0 0 1 X X X X X X X X
Reserved 1 1 1 1 1 0 0 1 X X X X X X X X
Note.— lg refers to length; T to Toggle bit; IB to Initialize bit; pr to priority; res refers to bits available for the
information field.
Table II-1-57c. Single octet DLPDUs encoding
Octet n
Bit 8 7 6 5 4 3 2 1
UDATA_CTS 0 0 1 1 1 0 1 1
INFO_ACK 0 T 0 1 0 0 0 1
INFO_CTS 0 res 0 1 1 0 1 1
CTRL_ACK 0 T res 0 0 0 0 1
CTRL_CTS 0 res res 0 1 0 1 1
Reserved 0 X X 1 0 1 0 1
FRMR_ACK 1 0 0 1 0 0 0 1
FRMR 1 0 0 1 0 1 0 1
DM/DISC 1 0 1 1 0 1 0 1
DM/FRMR 1 1 1 1 0 1 0 1
Reserved 1 0 1 1 1 0 1 1
Reserved 1 1 0 1 0 0 0 1
Reserved 1 X 0 1 1 0 1 1
Reserved X X X 0 0 1 0 1
Octet n
Bit 8 7 6 5 4 3 2 1
Reserved X X 1 1 0 0 0 1
Reserved X X X X 0 0 1 1
Reserved 1 1 0 1 0 1 0 1
Reserved X 1 1 1 1 0 1 1
Note 1.— “ X” means 0 or 1; neg refers to negotiation subfield; T to Toggle bit; IB to Initialize bit; FRMR to frame reject;
DM/DISC to disconnect mode; SZOM to start zero overhead mode; res refers to bits available for the information field..
Note 2.— All header bits labelled “ res” are reserved and shall be set to “ 0” .
1.4.2.3.3 Toggle bit (T)
The Toggle bit (T) shall be alternately set to zero (T = 0) and set to one (T = 1) on each successful transmission. At the
start of a communication between two stations or when the link is reset, the T bit shall be initiated according to the
procedures of 1.4.4.3.3.1 for NSCOP communication and according to the procedures of 1.4.4.3.3.2 for ZOCOP
communication.
Note.— The Toggle bit (T) is sufficient to provide duplicate detection and rejection.
1.4.2.3.4 More bit (M)
The more bit (M) shall be set to zero (M = 0) to indicate the end of a user data packet and set to one (M = 1) to indicate
that this fragment is not the last fragment in a multi-fragment user data packet and that further fragments will be
transmitted.
Note.— The more bit (M) is set to zero (M = 0) if a user data packet is sent as a single fragment or on the last
fragment of a fragmented user data packet; otherwise, it is set to one (M = 1). The receiver reassembles a fragmented
user data packet on reception before passing it to the user.
1.4.2.3.5 Priority (pr) subfield
The priority (pr) subfield shall indicate the priority level of the transmission as defined in 1.4.1.7.
1.4.2.3.6 Length (lg) subfield
The length (lg) subfield shall indicate the length of the DLS burst containing a DATA DLPDU in slots. It shall be
encoded as one less than the absolute length.
Note.— In the calculation of the length of the DLS burst, the size of the reservation protocol (default is response)
and the effects of bit stuffing should be taken into account. A length of one (“ 1” ) slot would be encoded as 0000 binary
and the maximum length of sixteen slots would be encoded as 1111 binary.
1.4.2.3.7 Initialize bit (IB)
Prior to sending a CTRL_RTS or upon receipt of a CTRL_RTS with the Initialize bit (IB) set to one (IB = 1), the
station shall initialize the state variables Tt and Tr as well as clear the SEND and RECEIVE arrays while processing the
DLPDU.
Note.— See 1.4.4.3.3.1 for the handling of INFO and CTRL DLPDUs in the process of being sent.
1.4.2.3.8 Negotiation (neg) subfield
The negotiation (neg) subfield shall indicate the link management parameters to be used for ZOCOP link control as
defined in Table II-1-57d.
Table II-1-57d. Interpretation of negotiation (neg) subfield
Negotiation (neg) subfield Parameters to use for ZOCOP link

0 VDL Mode 4 default parameters for version 0.
1 to 15 Reserved for future use.
1.4.2.3.9 SZOM sequence (seq) subfield
The SZOM sequence (seq) subfield shall indicate the SZOM sequence number.
1.4.2.3.10 UDATA DLPDU encoding
1.4.2.3.10.1 A DLS station wishing to send a UDATA shall transmit the UDATA burst defined in Table II-1-57e
with the VSS user supplied QoS and reservation parameters. The DLS station shall select between Tables II-1-57e,
II-1-57f or II-1-57g based on the UDATA ID (udid) of the message as defined by Table II-1-57h.
Table II-1-57e. One-byte UDATA burst format
Bit Number
Description Octet
8 7 6 5 4 3 2 1
Message ID, UDATA ID (ud1) 5 ud15 ud14 ud13 ud12 ud11 ucd 1 1
6
7
UDATA DLPDU 8 Information field
9
10
Table 1-57f. Two byte UDATA burst format
Bit Number
Description Octet
8 7 6 5 4 3 2 1
Message ID 5 1 1 1 1 0 ucd 1 1
UDATA ID (ud2) 6 ud28 ud27 ud26 ud25 ud24 ud23 ud22 ud21
Bit Number
Description Octet
8 7 6 5 4 3 2 1
7
8
10
11
Table II-1-57g. Three-byte UDATA burst format
Bit Number
Description Octet
8 7 6 5 4 3 2 1
Message ID 5 1 1 1 1 1 ucd 1 1
UDATA ID (ud3) 6 ud316 ud315 ud314 ud313 ud312 ud311 ud310 ud39
7 ud38 ud37 ud36 ud35 ud34 ud33 ud32 ud31
8
9
11
12
Note.— The UDATA DLPDU field may be up to ND4 octets long.
Table II-1-57h. Encoding of the UDATA ID (udid) value
UDATA ID (udid) Encoded by

0 to 29 Table II-1-57e, ud1 = udid
30 to 285 Table II-1-57f, ud2 = udid – 30
286 to 65 821 Table II-1-57g, ud3 = udid – 286
Note.— The UCTRL ID (ucid) subfield, is defined in 1.5.2.6.
1.4.2.3.10.2 A DLS station sending a UCTRL shall set ucd to zero (ucd = 0) and encode the appropriate ud1, ud2
or ud3 fields to the value of ucid per Tale II-1-57h. A DLS station sending a UINFO shall set ucd to one (ucd = 1) and
encode the appropriate ud1, ud2 or ud3 field to the value of uinf per Table II-1-57i.
Table 1-57i. UINFO ID (uinf) assignments
UINFO ID (uinf) Assignment

0 to 60 000 Reserved for future use
60 001 to 65 821 Messages reserved for transmission by ground station only and defined by ground station
operator.
1.4.2.3.11 Compressed and combined RTS/INFO DLPFU encoding (type 1)
A DLS station wishing to send a combined RTS and INFO DLPDU according to the procedures of 1.4.4.12, when the
priority of the RTS is different to that of the INFO packet, shall transmit the compressed combined RTS/INFO (type 1)
burst defined in Table II-1-57j with the VSS user supplied QoS and reservation parameters. The T bit for the RTS shall
be the inverse of the INFO T bit.
Table II-1-57j. Compressed combined RTS/INFO (type 1) burst format
Bit Number
Description Octet
8 7 6 5 4 3 2 1
Message ID 5 1 0 0 1 0 1 0 1
RTS priority and length 6 pr4 pr3 pr2 pr1 lg4 lg 3 lg 2 lg 1
INFO priority, M and T 7 M T pr4 pr3 pr2 pr1 res res
8
9
Compressed RTS/INFO (type 1) DLPDU 10 Information field
11
12
Note 1.— The compressed combined RTS/INFO (type 1) DLPDU field may continue past octet 12.
Note 2.— “ res” refers to bits available for the information field.
1.4.2.3.12 Compressed and combined RTS/INFO DLPDU encoding (type 2)
A DLS station wishing to send a combined RTS and INFO DLPDU according to the procedures of 1.4.4.12, when the
priority of the RTS is the same as that of the INFO DLPDU, shall transmit the compressed combined RTS/INFO
(type 2) burst defined in Table II-1-57k with the VSS user supplied QoS and reservation parameters. The T bit for the
RTS shall be set as the inverse of the INFO T bit and the priority set the same as that of the INFO DLPDU.
Table II-1-57k. Compressed combined RTS/INFO (type 2) burst format
Bit Number
Description Octet
8 7 6 5 4 3 2 1
Message ID, INFO M/T bits 5 M T 1 0 0 1 0 1
RTS/INFO priority and RTS length 6 pr4 pr3 pr2 pr1 lg 4 lg 3 lg 2 lg 1
7
8
Compressed RTS/INFO (type 2) DLPDU 9 Information field
10
11
Note 1.— The compressed combined RTS/INFO (type 1) DLPDU field may continue past octet 11.
Note 2.— This burst format is intended to be used to link M-bit sequences where each fragment is part of the same user data
packet and hence has the same priority.
1.4.3 DLS system parameters
The parameters needed by the DLS sub-layer shall be as listed in Table II-1-58. The DLS parameters for NSCOP
communications shall be determined during the exchange of CTRL DLPDUs, if the default values are not used. The
DLS parameters for ZOCOP communications shall be determined by the exchange of the negotiation (neg) subfield
within the SZOM DLPDU.
Table II-1-58. DLS system parameters

TD1 ZOCOP link transmit reset 5 sec 600 sec 60 sec 1 sec
timer
TD2 ZOCOP link receive reset 10 sec 1 200 sec 90 sec 1 sec
timer
ND1 Maximum number of octets 143 octets 2 063 octets 1 511 octets 1 octet
in any user data packet
ND2 Maximum length of DLS 2 octets 496 octets 86 octets 1 octet
transmission
ND3 Maximum length of 1 slot 16 slots 5 slots 1 slot
fragment
ND4 Maximum length of UDATA 23 octets 496 octets 271 octets 1 octet
burst
Note 1.— The value of ND3 should be chosen so that the length of each DLS transmission containing the fragment is less
than the maximum length of the DLS transmission defined by ND1 and greater than the maximum length of a short DLS
transmission defined by ND2.
Note 2.— Keep-alive have been eliminated from the protocol as peer presence is performed with synchronization bursts and
ground stations transmit an alert on start up per 1.5.5.1.3.1, or the ground system transmits a broadcast connection handoff.
1.4.3.1 Parameter TD1 (ZOCOP transmit reset timer)
For a mobile station maintaining a ZOCOP link with another mobile station, timer TD1 shall be reset when a DLPDU
is sent to the peer. Timer TD1 shall not be cancelled. If timer TD1 expires, then TT shall be set to zero (TT = 0) and the
SEND channel array shall be cleared.
Note.— See 1.4.4.14.2 for an example of when the response reservation type is not used.
1.4.3.2 Parameter TD2 (ZOCOP receive reset timer)
For a mobile station maintaining a ZOCOP link with another mobile station, timer TD2 shall be reset when a DLPDU
is received from the peer. Timer TD2 shall not be cancelled. If timer TD2 expires, the link shall be considered to be
terminated.
1.4.3.3 Parameter ND1 (maximum number of octets of any user data packet)
The parameter ND1 shall define the maximum number of octets in any user data packet that a DLS may accept from
the data link user or from a peer station. A station receiving a user data packet from a peer station greater in length than
ND1 shall discard the packet and reset the link in accordance with the procedures of 1.4.4.11. A station receiving a user
data packet from a data link user greater in length than ND1 shall discard the packet.
Note.— The maximum size of a user data packet for broadcast is set by parameter ND4 (maximum length of
fragment).
1.4.3.4 Parameter ND2 (maximum length of a short DLS transmission)
1.4.3.4.1 The parameter ND2 shall define the maximum size in octets of a short DLS transmission (including
flags and reservation data) that shall be sent by using the short transmission procedures defined in 1.4.4.5.
1.4.3.4.2 To calculate the number of octets, a burst occupying x number of slots shall contain up to {23 +
[(x − 1) • 63/2]} octets of data (including flags and reservation data).
Note.— A slot can contain 32 octets of data but the last slot in a sequence should only contain 24 octets to allow
for propagation guard time. Allowing an average of one octet for every two slots for bit stuffing, one slot could contain
23 octets of data (including flags and reservation blocks); two slots could contain 54 octets; three slots could contain
86 octets; and so forth.
1.4.3.5 Parameter ND3 (maximum length of fragment)
The parameter ND3 shall define the maximum size of a DLS burst in terms of slots.
1.4.3.6 Parameter ND4 (maximum length of a UDATA burst)
The parameter ND4 shall define the maximum size in octets of a UDATA burst.
1.4.4 DLS procedures
Note.— Either the mobile or ground station may send user data packets at any time and is considered peers with
respect to management of the link
1.4.4.1 Broadcast
Only UDATA DLPDUs shall be broadcast.
1.4.4.2 Setting of re-transmission parameter
For all DLS bursts containing CTRL, INFO, CTRL_RTS,INFO_RTS and UCTRL_RTS DLPDUs, the QoS parameters
of Q5min, Q5max, Q5mult, Q5exp and Q5num shall be set as defined in Table II-1-59.
Note.— Re-transmission of DLS DLPDUs may be handled in the VSS or DLS.

Table II-1-59. Re-transmission parameters
Symbol Parameter name Default

Q5min VSS re-transmission parameters — minimum 1.0 sec
Q5max VSS re-transmission parameters — maximum 15 sec
Q5mult VSS re-transmission parameters — multiplier 1.45
Q5exp VSS re-transmission parameters — exponent 1.7
Q5num VSS re-transmission parameters — number of attempts 4
Q5wait VSS re-transmission parameters — maximum time to wait for a reply 20 sec
1.4.4.3 Selection of user data packet for transmission
1.4.4.3.1 User data packet priority
1.4.4.3.1.1 A sending station shall maintain a prioritized queue of user data packets for transmission.
1.4.4.3.1.2 When determining which user data packet to transmit, the highest priority user data packet shall be
sent first.
1.4.4.3.1.3 The DLS DLPDUs CTRL and CTRL_RTS shall be classified as network management messages and
given the highest priority.
1.4.4.3.1.4 The DLS DLPDUs INFO_RTS and UDATA_RTS shall be assigned the same priority as the DATA
DLPDU with which they are associated.
Note.— All other DLS DLPDU types will be sent in pre-reserved slots (FRMR, DM/FRMR and DM/DISC) or take
the priority of the DATA packet to which they are combined (SZOM). Hence priority is not an issue.
1.4.4.3.2 User data packet fragmentation
1.4.4.3.2.1 Determination of single or multiple fragment transmission
1.4.4.3.2.1.1 If the length of the DLS burst containing a CTRL or INFO DLPDU is greater than ND3 slots, the
sending station shall fragment the user data packet into one or more fragments of maximum size ND3, and format it
according to the procedures of 1.4.4.3.2.3. Otherwise, the user data packet shall be sent as a single fragment formatted
according to the procedures of 1.4.4.3.2.2.
1.4.4.3.2.1.2 The fragmentation of a user data packet shall take into account whether or not the station is
combining a CTRL or INFO DLPDU with another DLS DLPDU in accordance with the procedures of 1.4.4.12.3.
1.4.4.3.2.2 Single fragment user data packet transmission
A single fragment user data packet shall be transferred as a CTRL or INFO DLPDU.
— The more bit (M) shall be set to zero (M = 0).
— For an INFO DLPDU, the priority bits (pr) shall indicate the priority of the DLPDU.
1.4.4.3.2.3 Multiple fragment user data packet transmission
A multiple fragment user data packet shall be transferred as a series of CTRL or INFO DLPDUs using the long
transmission procedures defined in 1.4.4.6.
— The more bit (M) shall be set to one (M = 1) for all fragments except the last fragment.
— The more bit (M) shall be set to zero (M = 0) for the last fragment.
— For INFO DLPDUs, the priority bits (pr) shall indicate the priority of the DLPDU.
1.4.4.3.3 Setting of Toggle bit (T)
1.4.4.3.3.1 T bit initialization for NSCOP communication
When there is no established link (or link in the process of being established) between a mobile DLE and a ground
DLE, and the LME of either station requests the transmission of a CTRL user data packet, the sending DLE shall send
the CTRL DLPDU using the long transmission procedures (see 1.4.4.6). In the CTRL_RTS it shall set the Initialize bit
(IB) to one (IB = 1), the Toggle bit (T) to zero (T = 0) and follow the procedures of 1.4.2.3.7.
1.4.4.3.3.1.1 On receipt of a CTRL_RTS DLPDU with IB = 1, the receiving DLE shall follow the procedures of
1.4.2.3.7. The sender and receiver shall consider the link initialized. The receiver shall immediately terminate any
INFO transfers in progress. Any partially received CTRL DLPDUs shall be discarded. If any CTRL fragments had
already been acknowledged, then the remainder of the CTRL DLPDU shall be abandoned; however, if no CTRL_ACK
had been received for a CTRL DLPDU, then its transfer shall continue unaffected.
Note 1.— The DLE to which the mobile sent the CTRL_CMD may not be the DLE which responds with the
CTRL_RSP. The IB bit in the CTRL_RSP may either be 0 or 1 depending on whether the responding DLE received the
CTRL_CMD or not.
Note 2.— INFO DLPDUs and partially sent or received CTRL DLPDUs are abandoned mid-transfer on the
presumption that the peer station has restarted (there is no other legitimate reason for the IB=1).
1.4.4.3.3.1.2 The DLE shall consider the link connected upon direction from the LME, INFO, INFO_RTS,
INFO_ACK, and INFO_CTS DLPDUs shall only be sent on links that are connected. Although a DLE may receive
INFO DLPDUs (and generate INFO_ACKs), it shall not transmit INFO DLPDUs until it receives a CTRL_ACK to its
CTRL (M = 0).
Note 3.— If the receiving LME indicates to the receiving DLE that the link is established after the receiving DLE’ s
transmission of the CTRL_ACK, then the receiving DLE will not respond with a DM/FRMR to the INFO_RTS or INFO
that it receives.
1.4.4.3.3.1.3 On receipt of a CTRL_RTS in a DLS burst addressed to it for which the Initialize bit (IB) is equal to
one (IB = 1) and for which the T bit is equal to one (T = 1), a station sends a DM/FRMR. If a DLE with uninitialized
state variables receives a CTRL_RTS DLPDU with IB equal to zero (IB = 0), then it shall respond with a DM/FRMR.
1.4.4.3.3.1.4 If a DLE receives a SZOM from a peer DLE with which it will only communicate using the
NSCOP, it shall respond with a DM/FRMR.
1.4.4.3.3.2 T bit initialization for ZOCOP communication
1.4.4.3.3.2.1 A mobile sending station (the “ sending station” ) wishing to send data to a mobile station (the
“ receiving station” ) for which it does not currently have a link shall send a DLS burst containing a SZOM DLPDU and
the first INFO (short transmission procedures) or INFO_RTS (long transmission procedures) DLPDU to the receiving
station, using the short transmission procedures (see 1.4.4.5) or the long transmission procedures (see 1.4.4.6),
respectively. It shall set the negotiation (neg) subfield to the highest value that is supported by the DLS in the SZOM
DLPDU, the sequence (seq) subfield to a value that it has not transmitted to the receiving station within the preceding
TD2 seconds, the T bit to zero (T = 0) in the INFO DLPDU, and initialize its sending and receiving state variables.
1.4.4.3.3.2.2 On receipt of an unsolicited SZOM DLPDU with a sequence subfield different from the most
recently received SZOM from the sending station, the receiving station shall initialize its sending and receiving state
and consider the link established for receipt of further DLPDUs from the sending station. The receiving station shall
send a SZOM DLPDU combined with an INFO_ACK (short transmission procedures) setting T = 0 or an INFO_CTS
(long transmission procedures), in the slot reserved for the transmission. In the SZOM DLPDU, the receiving station
shall set the negotiation (neg) field to the highest value that is supported by the DLS and the sequence subfield to zero
(seq = 0). The receiving station shall not transmit any INFO or INFO_RTS DLPDUs to the sending station prior to
sending the SZOM/INFO_ACK or SZOM/INFO_CTS reserved transmission.
1.4.4.3.3.2.3 For both sending and receiving stations, link parameters shall be selected which correspond to the
lower value of the negotiation (neg) subfields contained in the SZOM DLPDU sent by the sending station and in the
SZOM DLPDU sent by the receiving station.
1.4.4.3.3.2.4 A station that transmitted an SZOM to a peer shall re-transmit its initial transmission in response to
any DLPDU other than a SZOM, DM/DISC, DM/FRMR or GENERAL FAILURE until it receives a SZOM. After
Q5num attempts, it shall report a failure to the DLE user.
1.4.4.3.3.3 Transfer after initialization
When the Toggle bit (T) has been initialized, the sending station shall set the T bit for transmitted DLPDUs to the value
of TT (T = TT).
1.4.4.4 Selection of transmission procedures
After a packet has been selected for transmission according to the procedures of 1.4.4.3, the sending station shall
calculate the total length in octets of the DLS burst required to contain the DLPDU queued for transmission, using the
short transmission procedures defined in 1.4.4.5. The total length shall include the length of any reservation fields
contained within the DLS burst, together with any flags. The calculation of the length of the DLS burst shall take into
account whether or not the station will combine a DATA DLPDU with another DLS DLPDU in accordance with the
procedures of 1.4.4.12.3. If the total length is less than or equal to ND2, then the station shall use short transmission
procedures (1.4.4.5) to transmit the queued data. Otherwise, the station shall use the long transmission procedures
(1.4.4.6). The more bit (M) shall be set to zero (M = 0) for a short transmission.
If there are other DLPDUs queued for transmission, then the station should also include an RTS in accordance to
1.4.4.12.3.
1.4.4.5 Short transmission procedures
1.4.4.5.1 Transmission of DATA DLPDU
1.4.4.5.1.1 After the selection of a short transmission procedure, the sending station shall transmit a DLS burst
containing the DATA DLPDU queued for transmission, with QoS parameters as defined in Table II-1-60 and using the
random access procedures. For CTRL and INFO DLPDUs, the Toggle bit (T) shall be set to TT (T = TT).
Table II-1-60. Short transmission INFO DLPDU parameters

V32 Minimum response delay [54 milliseconds • M1/60] slots
V33 Maximum response delay [5 sec • M1/60] slots
V34 Source/destination control 0
V35 Broadcast control 0
V36 Length of reserved block 1 slot
Q1 Priority Priority of INFO DLPDU
Q2a Slot selection range constraint for level 1 150 NM
Q2b Slot selection range constraint for level 2 150 NM
Q2c Slot selection range constraint for level 3 0 NM
Q2d Slot selection range constraint for level 4 300 NM
Q3 Replace queued data FALSE
Q4 Number of available slots 3
1.4.4.5.1.2 A burst containing a CTRL or INFO DLPDU shall contain a unicast request reservation field for the
acknowledgement with the parameters in Table II-1-60.
Note 1.— The priority field in the unicast reservation field is set equal to the priority setting in the INFO DLPDU
as specified in Table II-1-60.
Note 2.— If the responder VSS sub-layer has not received a response from the VSS user in the scheduled
reservation, it can send:
a) a GENERAL FAILURE (see 1.3.20) with error type (err) 7E hex or FE hex; and
b) a unicast request reservation according to the procedures of 1.3.19.2.
1.4.4.5.2 Acknowledgement of DATA DLPDU
1.4.4.5.2.1 Established link with sender
If a station receiving a CTRL or INFO DLPDU has an established link with the sender, it shall transmit a DLS burst
containing an ACK DLPDU in the slot reserved by the unicast request reservation field that is contained in the DATA
DLPDU transmission:
a) A CTRL_ACK DLPDU shall be sent in response to a CTRL DLPDU, and an INFO_ACK DLPDU sent in
response to an INFO DLPDU.
b) The Toggle bit (T) in the CTRL_ACK or INFO ACK DLPDU shall be set to the value of the T bit in the
received DATA DLPDU.
Note.— See 1.4.4.12. for an example of when the response reservation type is not used.
1.4.4.5.3 Non-receipt of acknowledgement
If an acknowledgement to a CTRL or INFO DLPDU is not received from the receiving station, the sending station shall
re-transmit:
a) the DLS burst containing the CTRL or INFO DLPDU; and
b) a unicast request reservation field according to the procedures of 1.3.21.
1.4.4.5.4 Action on receipt of a UDATA DLPDU
A station receiving a UDATA DLPDU shall forward the contents of the information (in) field to the DLS user and take
no further action.
1.4.4.6 Long transmission procedures
1.4.4.6.1 Transmission of Request to Send (RTS)
After the selection of a long transmission procedure, the sending station shall transmit a DLS burst containing an RTS
DLPDU to the receiving station in the transmit queue with QoS parameters as defined in Table II-1-61. When using the
long transmission procedure:
a) A station shall send a CTRL_RTS, INFO_RTS or UDATA_RTS DLPDU if a CTRL, INFO or UDATA
DLPDU, respectively, is to be transmitted.
b) The priority (pr) subfield shall indicate the priority of the INFO_RTS and UDATA_RTS DLPDUs to be
transmitted (see 1.4.1.7)
c) The length (lg) subfield shall indicate the length of the DLS burst required to contain the DATA DLPDU (see
1.4.2.3.6).
d) For CTRL_RTS and INFO_RTS DLPDUs, the Toggle bit (T) shall be set to state variable TT (T = TT).
Each burst shall contain a unicast request reservation field, with the parameters set as defined in Table II-1-61.
Note 1.— The ground may use the priority (pr) subfield to manage the link resource during congestion.
Note 2.— Transfer of broadcast data using the long transmission procedures involves directing the UDATA_RTS
at a specific station, receiving a set of slots from that station via the UDATA_CTS, and then broadcasting the UDATA
in the reserved slots
Note 3.— The priority field in the unicast request reservation field is set equal to the priority setting in the INFO
DLPU as specified in Table II-1-61.
Table II-1-61. Long transmission Request to Send (RTS) DLPDU parameters

V34 Source/destination control 0
V35 Broadcast control 0
V36 Length of reserved block 1 slot
Q1 Priority Priority of RTS
1.4.4.6.2 No response to Request to Send (RTS)
If a response is not received for the RTS DLPDU, the station re-transmits:
a) the DLS burst containing the RTS DLPDU, and
b) the unicast request according to the procedures of 1.3.14.4.4.
1.4.4.6.3 Response to Request to Send (RTS)
1.4.4.6.3.1 Response if a DATA DLPDU has not previously been received,

with the parameters defined in Table II-1-62.
Table II-1-62. General response to Request to Send (RTS) parameters

1.4.4.6.3.1.1 If the responder has an established link with the sender and the received DLPDU is a UDATA_RTS
or if the Toggle bit (T) within the CTRL_RTS or INFO_RTS DLPDU is not equal to TR (T TR), then the receiving
station shall transmit a CTS DLPDU in a DLS burst in the slot reserved by the RTS DLPDU.
1.4.4.6.3.1.2 A CTRL_CTS, INFO_CTS or UDATA_CTS DLPDU shall be sent in response to a CTRL_RTS,

INFO_RTS or UDATA_RTS DLPDU, respectively.
1.4.4.6.3.1.3 For CTRL_CTS and INFO_CTS DLPDUs, the burst shall contain an information transfer request
reservation field and it shall be transmitted with the parameters in Table II-1-63, indicating the number of slots reserved
for transfer of the DATA DLPDU.
Table II-1-63. Clear to Send (CTS) DLPDU parameters

V42 Length of information transfer Sufficient to included requested INFO DLPDUs
V43 Minimum information transfer delay [54 milliseconds • M1/60] slots
V44 Maximum information transfer delay [5 sec • M1/60] slots
1.4.4.6.3.1.4 For a UDATA_CTS DLPDU, the burst shall contain a unicast request reservation field and it shall
be transmitted with the parameters in Table II-1-61, indicating the number of slots reserved for transfer of the DATA
DLPDU.
1.4.4.6.3.2 Response if a DATA DLPDU has been received previously
If the responder has an established link with the sender and if the Toggle bit (T) within the CTRL_RTS or INFO_RTS
DLPDU is equal to TR (T = TR), then the receiving station shall transmit an ACK DLPDU in the slot reserved by the
RTS.
a) A CTRL_ACK or INFO_ACK DLPDU shall be sent in response to a CTRL_RTS or INFO_RTS DLPDU,
respectively.
b) The Toggle bit (T) shall be set to the value of the T bit in the received DATA DLPDU.
The DLS burst containing the ACK DLPDU shall contain a response reservation type except as determined by the
procedures of 1.4.4.12.
1.4.4.6.3.3 Channel too busy
If the channel is too busy (either the receiving station cannot find a sufficiently large series of contiguous slots or the
priority is too low for the channel utilization), then the receiving station shall transmit either:
— a GENERAL CONFIRM (including a unicast reservation with V34 = 1) to indicate when the responder will
transmit an information transfer request in response to the RTS, or
— a GENERAL FAILURE (see 1.3.20), with error type (err) = 01 hex (err = 01 hex).
Note.— If the responder sends a GENERAL FAILURE (see 1.3.20), the sender can re-transmit the RTS after the
time out defined by the backoff delay or in the slot reserved by the destination.
1.4.4.6.4 Response to Clear to Send (CTS)
1.4.4.6.4.1 Transmission of DATA DLPDU
1.4.4.6.4.1.1 On receipt of a CTRL_CTS or INFO_CTS DLPDU in a DLS burst addressed to it and with an
information transfer request reservation field, a station shall transmit the requested DATA DLPDU in the allocated
reservation with the T bit set to TT. The DLS burst containing the DATA DLPDU shall contain a response reservation
type.
1.4.4.6.4.1.2 On receipt of a UDATA_CTS DLPDU in a DLS burst, with a unicast request reservation field, a
station shall transmit the requested UDATA DLPDU in the allocated reservation.
1.4.4.6.4.2 Response if there is no information to transmit
If upon receipt of a CTS the station has nothing to transmit (e.g. after a reset), it shall transmit one of the following:
a) an FRMR if the link is connected;
b) a DM/DISC if the link is disconnected; and
c) a DM/FRMR if the link is in the process of connecting.
If the station has not transmitted an INFO DLPDU and a higher priority user data packet arrived after the RTS had been
transmitted, the station should transmit as much of the highest priority packets as will fit in the current reservation with
the same value for T as contained in the RTS.
1.4.4.6.5 Acknowledging the data
1.4.4.6.5.1 DATA DLPDU received
For a receiving station which has transmitted a CTRL_CTS or INFO_CTS DLPDU in a DLS burst containing an
information transfer request reservation field (and consequently has a reservation for an acknowledgement) and which
has received the DATA with a T bit not equal to TR, follow the procedures of 1.4.4.5.2.1.
1.4.4.6.5.2 Response if DATA DLPDU not received
1.4.4.6.5.2.1 A receiving station which transmitted a CTRL_CTS or INFO_CTS DLPDU in a DLS burst
containing an information transfer request reservation field (and consequently has a reservation for an
acknowledgement) and which has not received the CTRL or INFO DLPDU with a T bit not equal to TR shall transmit
an ACK DLPDU in a DLS burst in the slot reserved for an acknowledgement.
a) A CTRL_ACK or INFO_ACK DLPDU shall be sent in response to a CTRL or INFO DLPDU, respectively.
b) The Toggle bit (T) shall be set to the inverse of the value of the T bit in the last received RTS DLPDU.
Note.— The use of the Toggle bit (T) not equal to TR indicates a “ negative acknowledgement (NACK).”
1.4.4.6.5.2.2 The DLS burst containing the ACK DLPDU shall contain a response reservation type.
1.4.4.7 DLS not supported
If the responder to a CTRL, CTRL_RTS, INFO, INFO_RTS or SZOM DLPDU does not support the DLS, then it shall
transmit a GENERAL FAILURE (see 1.3.20) with an error type (err) of 80 hex (err = 80 hex) in the slot reserved by
the unicast request reservation field as contained in the data DLPDU transmission.
Note.— The response upon receipt of a GENERAL FAILURE, described in 1.3.20.1, is to not transmit another DLS
burst to the ending station for the duration of the backoff timer.
1.4.4.8 No link with sender
If the responder to any DLPDU other than a CTRL_RTS DLPDU, with Initialize bit (IB) not equal to one (IB 1) or
SZOM DLPDU (which may be combined with an INFO or INFO_RTS DLPDU or has not or is not attempting to
establish a link with the sender, the responder shall send a DLS burst containing a DM/DISC DLPDU in the slot
reserved by the unicast or information transfer request reservation field as contained in the data DLPDU transmission.
If the responder is trying to establish an NSCOP or ZOCOP link with the sender, then it shall respond with a
DM/FRMR to any DLPDU other than a CTRL-related DLPDU or SZOM DLPDU for NSCOP and ZOCOP,
respectively.
Note.— Per 1.4.4.3.3.1, an NSCOP link is considered established when a DLE sends or receives the last fragment
of a CTRL_RSP. Consequently, a DLE may be re-transmitting the last fragment of a CTRL_RSP while acknowledging
INFO DLPDUs.
1.4.4.9 User data packet reception
1.4.4.9.1 Receipt and forwarding of received DATA DLPDUs
1.4.4.9.1.1 When a CTRL or INFO DLPDU is received without errors from another station, the value of the
Toggle bit (T) shall be inspected and recorded. In case:
a) an INFO DLPDU with the T bit set to zero (T = 0) is combined with a SZOM DLPDU, and
b) the value of the Toggle bit (T) is not equal to TR (T TR),
then the user data packet or user data packet fragment shall be accepted and TR shall be set to the value of the T bit in
the received INFO or CTRL DLPDU. Otherwise, the received user data packet or user data packet fragment shall be
discarded as a duplicate.
1.4.4.9.1.2 When a UDATA DLPDU is received without errors from another station, it shall be passed to the
service user as a single incoming user data packet. Otherwise, it shall be discarded.
1.4.4.9.2 Concatenation of multiple fragment user data packets
1.4.4.9.2.1 If any preceding user data packet fragments have been received with (as in the case of an INFO
DLPDU) the same value of priority (pr) subfield and with the more bit (M) set to one (M = 1), then the user data part of
the received DATA DLPDU shall be concatenated to the end of the user data packet fragments.
1.4.4.9.2.2 If the more bit (M) is set to zero (M = 0) on the received DATA DLPDU, then the user data part of
the received DATA DLPDU (including any user data packet fragments received earlier and with which it has been
concatenated) shall be passed to the service user as a single incoming user data packet.
1.4.4.9.3 Unacknowledged DLPDUs
UDATA, DM/DISC, DM/FRMR and all ACK DLPDUs shall be unacknowledged.
1.4.4.10 Receipt of ACK DLPDU
1.4.4.10.1 Receipt of an expected ACK DLPDU
1.4.4.10.1.1 When an ACK DLPDU is received without errors from another station and there was an outstanding
DATA DLPDU to be acknowledged, the value of the Toggle bit (T) shall be inspected and the following operations
performed.
1.4.4.10.1.2 If T = TT in the ACK DLPDU, then the DATA DLPDU shall be assumed to have been successfully
received. Furthermore, if the value of TT in the DATA DLPDU is zero (TT = 0), then the current value of TT should be
set at one (TT = 1) or vice versa.
1.4.4.10.1.3 If the ACK DLPDU is not received by the expected reserved slot, then the sending station shall
resend the DATA DLPDU by using the short or long transmission procedures as determined by the procedures of
1.4.4.4.
Note 1.— Re-transmission is based on the expected receipt time and not on the receipt of a NACK.
1.4.4.10.1.4 When a DATA DLPDU has been successfully received, the highest priority fragment (either the
next fragment of the current user data packet or the first fragment/complete DLPDU of the next user data packet) in the
send queue, if any, shall be selected for transmission by using the procedures of 1.4.4.3.
Note 2.— The selection of highest priority allows the station to pre-empt a lower priority transfer (e.g. more bit
(M) linked fragments) with a higher priority user data packet or set of fragments.
1.4.4.10.2 Receipt of an unexpected ACK DLPDU
When an ACK DLPDU is received without errors from another station and there was no outstanding DATA DLPDU to
be acknowledged, the value of the T bit shall be inspected and the following operations performed. If T = TT, then the
link shall be reset as per 1.4.4.11. If T TT, then the ACK shall be ignored.
1.4.4.11 Link reset
1.4.4.11.1 Link reset during link set up
The sending station shall disconnect the link by sending a DM/FRMR DLPDU, which is transmitted in the reservation
placed for the response. Upon receipt of a DM/FRMR DLPDU, the receiving station shall disconnect the link.
1.4.4.11.2 Link reset of an established link
1.4.4.11.2.1 The sending station shall reset the link by sending a FRMR DLPDU in a DLS burst that places a
unicast reservation for the response. The sending station shall also discard all outstanding user data packets in the
SEND and RECEIVE array. The receiving station shall clear the state variables and clear the send and receive arrays. If
a FRMR_ACK is not received in the reserved slot, the FRMR shall be sent again using the re-transmission procedures.
Only when a FRMR_ACK has been received shall the station attempt to resend data to the receiving station by using
the procedures of 1.4.4.3.3. If the sending station receives an INFO or RTS DLPDU from the peer while waiting for a
FRMR_ACK, it shall send an FRMR in response. Upon receipt of an unsolicited FRMR_ACK, a DLE shall respond
with an FRMR.
1.4.4.11.2.2 On receipt of a FRMR DLPDU, the receiving station shall discard any outstanding fragments in the
RECEIVE array and shall transmit a FRMR_ACK DLPDU in a DLS burst in the reserved slot.
1.4.4.12 Linking DLS DLPDU transmissions
An implementation of the DLS shall be capable of providing a combined DLPDU response even if the station does not
initiate the use of combined DLPDUs.
A station with a queue of transmissions to send to a receiving station should link transmissions by using the procedures
set out in this section.
1.4.4.12.2 Allowed DLPDU combinations
It shall be possible to combine the following DLPDUs:
• RTS/DATA
• ACK/CTS
• ACK/DATA
• ACK/RTS
• SZOM/other DLPDUs as described in 1.4.4.3.3.2.
Note.— Receipt of a combined DLPDU not listed in this section is handled in an implementation-defined manner.
1.4.4.12.3 Recommendation: Combined RTS/DATA DLPDUs
When a receiving station has selected a user data packet for transmission by using the procedures of 1.4.4.3, it should
also select the next user data packet with the highest priority and place an RTS DLPDU in the DLS burst containing the
DATA DLPDU for the first user data packet by setting the Toggle bit (T) to the inverse of state variable TT (T = 1/TT)
and appending a response reservation type.
Note 1.— Because the DATA DLPDU is unlimited in length, the RTS must precede the DATA DLPDU. However,
since the RTS contains the inverse T bit of the transmitted DATA DLPDU (as it is for the subsequent DATA DLPDU), it
must be the second to be processed.
Note 2.— This recommendation also applies in cases where the short transmission procedure would normally be
selected for transmission but for which there is an opportunity to combine it with the end of the previous long
transmission procedure.
1.4.4.12.4 Combined ACK/CTS DLPDUs
1.4.4.12.4.1 On receipt of a RTS/DATA DLS burst, a station shall process the DATA DLPDU first according to
the procedures of 1.4.4.6.5.1. If the station can find sufficient resources for a subsequent DATA DLPDU transfer, then
the DLS burst containing the ACK DLPDU shall also contain a CTS DLPDU for the next DATA DLPDU transfer:
— A CTRL_CTS, INFO_CTS or UDATA_CTS DLPDU shall be sent in response to a CTRL_RTS, INFO_RTS

or UDATA_RTS DLPDU, respectively.
1.4.4.12.4.2 In the case of CTRL_CTS and INFO_CTS DLPDUs, instead of the response reservation type
required by the procedures of 1.4.4.6.5.1, the burst shall contain an information transfer request reservation field
transmitted by using the parameters defined in Table II-1-63, indicating the number of slots reserved for transfer of the
DATA DLPDU.
1.4.4.12.5 Combined DATA/ACK DLPDUs
For a receiving station which has data that would fit into a single slot DLS burst that contains an ACK DLPDU to be
sent back to the sending station, the receiving station shall include its own DATA DLPDU in this DLS burst. The burst
shall contain a unicast request reservation field, with the parameters in Table II-1-61 used for the acknowledgement of
the DATA DLPDU.
Note.— A station may combine a transport acknowledgement with the ACK if this can be produced in time.
1.4.4.12.6 Combined ACK/RTS DLPDUs
If a receiving station has data to send back to the sending station but the data cannot fit into a single slot DLS burst
containing an ACK DLPDU, then the receiving station shall combine an RTS DLPDU for its own DATA DLPDU in
the DLS burst containing the ACK DLPDU and use the long transmission procedures for the data transfer.
1.4.4.12.7 Recommendation: Combined ACK/RTS DLPDUs to different peers
If a station is sending an ACK DLPDU to one destination and has data to send to a different destination, then the
station should include a unicast reservation field with source/destination flag (sdf) = 1 (with the DLS burst containing
the ACK) and then transmit an RTS DLPDU to the new destination in the reserved slot.
Note.— This makes it possible for a ground station to link a series of transmissions to different destinations.
1.4.4.13 CTRL DLPDU
The CTRL DLPDU shall be used for the LME to establish and maintain links as defined in 1.5.
1.4.4.14 Procedures for air-air communication
Air-air communication services shall be supported by a ZOCOP.
1.4.4.14.1 Air-air data exchange after link initialization
When a ZOCOP link has been established, data shall be exchanged as determined by either the short or long
transmission procedures that are described in 1.4.4.5 and 1.4.4.6.
1.4.4.14.2 Maintenance of ZOCOP link
1.4.4.14.2.1 A station that has established a ZOCOP link with a peer, has not sent a packet to that peer for TD1
seconds, and wishes to send a DATA packet to the peer shall re-establish the link according to the procedures of
1.4.4.3.3.2.
1.4.4.14.2.2 A station shall regard the ZOCOP link as terminated if it has not transmitted to the same peer for
TD1 seconds and if it has not received a transmission from the same peer for TD2 seconds.
1.4.4.14.2.3 A station shall regard the ZOCOP link as terminated if it receives a DM/DISC DLPDU from the
peer station or if an attempt to send a packet to the peer station fails because of a failure conveyed through the re-
transmission procedures of 1.3.21.
1.4.4.14.3 Action on receipt of a CTRL parameter in a ZOCOP link
1.4.4.14.3.1 If a CTRL_RTS (IB=0), CTRL_CTS, CTRL, or CTRL_ACK DLPDU is received on an established

ZOCOP link, then the receiver shall respond with a DM/FRMR in the reserved slot.
1.4.4.14.3.2 If a CTRL_RTS (IB=1) is received on an established ZOCOP link, then the old link shall be
considered disconnected and the receiver shall either proceed to establish the link via NSCOP procedures or respond
with a GENERAL FAILURE with a cause code indicating policy reasons.
1.5 LINK MANAGEMENT ENTITY (LME) SUB-LAYER
1.5.1 Services
The services of the LME shall be as follows:
a) link provision, and
b) link change notification.
1.5.1.1 Link provision
1.5.1.1.1 Each ground system and each mobile system supporting air/ground point-to-point communication
services shall include the functionality of a VDL Management Entity (VME). A VME shall be responsible for the data
link management policy of the system.
a) In a mobile system, the VME shall be responsible for determining with which ground system(s) the mobile
system should maintain data link communications at any given time.
b) In a ground system, the VME shall be responsible for determining which mobile system(s) should be provided
with data link communications as well as which ground station and mobiles (when the ground system supports
multiple frequency operations) are to be assigned frequencies.
1.5.1.1.2 A VME shall have an LME for each peer LME. Hence, a ground VME shall have an LME for every
mobile system and a mobile VME shall have an LME for every ground system. An LME shall establish a link between
a local data link entity (DLE) and a remote DLE associated with its peer LME.
a) A ground LME shall determine if a mobile station is associated with its peer mobile LME by comparing the
station address. Two mobile stations with identical station addresses are associated with the same LME.
b) A mobile LME shall determine if a ground station is associated with its peer ground LME by conducting bit-
wise logical AND operations of the DLS address and of the station ground system mask. The station ground
system mask is provided by the peer ground LME. Two ground stations with identical masked DLS addresses
are associated with the same LME.
Note.— If a mobile receives a burst from a ground station, only one LME will process and react to that burst.
Thus, the qualifying phrase “ from a ground station associated with its peer LME” will not be included and should be
understood to be implied.
1.5.1.1.3 Each ground and mobile LME shall monitor all transmissions (both DLS and VSS) from its peer
stations in order to maintain a reliable link between some ground stations and the mobile station while the mobile
station is within the coverage area of an acceptable ground station.
1.5.1.2 Link change notifications
The VME shall notify the intermediate system— system management entity (IS-SME) of changes in link connectivity
by supplying information contained in the CTRL DLPDUs received.
1.5.2 Synchronization burst format
All VDL Mode 4 stations shall transmit synchronization bursts to support link management.
1.5.2.1 Fixed and variable data fields
The synchronization burst shall consist of two portions:
a) a fixed data field containing information that is sent with each synchronization burst, and
b) a variable data field containing additional system management information that does not have to be included
in each synchronization burst.
Note 1.— The variable data field can also include VSS user-specific information.
Note 2.— The fixed data field contains 55 bits of data consisting of bits 2 through 8 of octet 5 and all of octets 6
through 11 inclusive (the fixed data field begins after the source address (s) and message identification (mi) fields
which consist of the first 4 octets and bit 1 of octet 5). The variable portion contains 54 bits of data consisting of octets
12 through 17 and bits 3 through 8 of octet 18.
Note 3.— Certain variable information fields have been assigned and are described in Chapter 3.
1.5.2.2 Fixed data field format
1.5.2.2.1 Stations shall have fixed data fields as defined in Table II-1-64.
Note.— Mobile and ground stations are identified by the address type field in the 27-bit code (see 1.4.2.1).
1.5.2.2.2 The subfields shall be computed as defined in Table II-1-65.
Note.— The information field ID (id) and ID extension (idn) subfields shall provide addresses for information
fields (in) as follows:
a) An information field ID (id) equal to F hex (id = F hex) shall indicate that no information (in) field is present.
b) An information field ID (id) subfield equal to 0 hex to 9 hex (id = 0 hex to 9 hex) or B hex to E hex (id = B hex
to E hex) shall indicate one of 14 information (in) fields of length 54 bits.
c) An ID extension 1 (id1) subfield shall only be present if the information field ID (id) is equal to A hex
(id = A hex). An ID extension 1 (id1) subfield equal to 0 hex to 9 hex (id = 0 hex to 9 hex) or B hex to F hex
(id = B hex to F hex) shall indicate one of 15 information (in) fields of length 50 bits.
d) An ID extension n (idn) subfield shall only be present if the ID extension n − 1 (idn − 1) subfield is equal to
A hex [(idn − 1) = A hex]. An ID extension n (idn) subfield equal to 0 hex to 9 hex (idn = 0 hex to 9 hex) or
B hex to F hex (idn = B hex to F hex) shall indicate one of 15 information (in ) fields of length [54 – 4n] bits.
Table II-1-64. Synchronization burst format
Bit number
Trajectory Change Point / State Vector 5 nic4 nic3 nic2 nic1 cprf b/g tc 0
Quality (TCP/SVQ) change flag (tqc)
baro/geo altitude (b/g)
Compact Position Reporting (CPR)
Format (cprf)even/odd
navigational integrity category (nic)
latitude (lat) 6 lat8 lat7 lat6 lat5 lat4 lat3 lat2 lat1
base altitude (balt) 7 balt12 balt11 balt10 balt9 lat12 lat11 lat10 lat9
8 balt8 balt7 balt6 balt5 balt4 balt3 balt2 balt1
longitude (lon) 9 lon8 lon7 lon6 lon5 lon4 lon3 lon2 lon1
time figure of merit (tfom) 10 tfom2 tfom1 lon14 lon13 lon12 lon11 lon10 lon9
data age (da) 11 da4 da3 da2 da1 id4 id3 id2 id1
information field ID (id)
ID extension 1 (id1) 12 id14 id13 id12 id11 id24 id23 id22 id21
ID extension 2 (id2)
ID extension 3 (id3) 13 id34 id33 id32 id31 ink
information field (in) 14
15 ........
16
17 in14 in13 in12 in11 in10 in9 in8 in7
18 in6 in5 in4 in3 in2 in1

Table II-1-65. Synchronization burst field encoding (fixed data field)

TCP/SVQ change Boolean Encoded as defined in 3.6 if the message ID
flag (tqc) (see Table II-1-6) indicates that the burst is a
directed synchronization burst; otherwise,
reserved for future definition and set equal to 1.
time figure of 0 to 3 0 = primary certified See 1.2.3.
merit (tfom) 1 = primary/non-certified
2 = secondary
3 = tertiary
Navigational 0 to 15 See Table II-1-66.
integrity category Values 12 to 15 are reserved for future
(nic) definition
latitude (lat) −90° to +90° The 12-bit low resolution encoding according to The 12-bit CPR encoding provides
the CPR encoding algorithm adapted for VDL position to a resolution of
Mode 4, as described in Chapter 4. approximately ±140 m, within a
segment (patch) of approximately
600 NM.
longitude (lon) −180° to +180° The 14-bit low resolution encoding according to The 14-bit CPR encoding provides
the CPR encoding algorithm adapted for VDL position to a resolution of
Mode 4, as described in Chapter 4. approximately ±120 m, within a
segment (patch) of approximately
600 NM.
CPR format 0 to 1 0 = even
even/odd 1 = odd
The CPR flag shall apply to all CPR encoded
subfields included in the synchronization burst.
base altitude 0 to 4 095 Base altitude is reported as specified in Table
(balt) II-1-67.
baro/geo altitude 0 to 1 0 = barometric Indicates whether barometric or
(b/g) 1 = geometric geometric base altitude is reported.
data age (da) 0 to 15 See Table II-1-68.
Information field 0 to 15 As defined by application standards. Some Provides the information field
ID (id) values for the information field ID are pre- identity contained in the variable
reserved and defined in Chapter 3. data field (see 1.5.2.3).
ID extension 0 to 15 See Note b) in 1.5.2.2.2. Provides a means of increasing the
number of variable fields that can
be accommodated.
information field — As defined by application standards. The information field contained in
(in) the variable data field (see 1.5.2.3).
1.5.2.2.3 The station shall encode its navigation integrity category (nic) in accordance with Table II-1-66.
1.5.2.2.4 The station shall encode base altitude (balt) in accordance with Table II-1-67.
1.5.2.2.5 The data age (da) subfield shall be encoded based on the report latency which shall be the difference
between the time of validity of the horizontal position data (latitude and longitude) and the time of transmission, in
accordance with Table II-1-68. If the report latency is greater than 4 seconds, then the nic shall be set to zero (nic = 0).
Table II-1-66. Encoding of navigational integrity category (nic)
NIC Required Navigation Performance (RNP) class Horizontal and vertical containment
radius (Rc)
0 Unknown integrity Rc 20 NM
1 RNP-10 Rc 20 NM
2 RNP-4 Rc 8 NM
3 RNP-2 Rc 4 NM
4 RNP-1 Rc 2 NM
5 RNP-0.5 Rc 1 NM
6 RNP-0.3 Rc 0.6 NM
7 RNP-0.1 Rc 0.2 NM
8 RNP-0.05 Rc 0.1 NM
9 Undefined Rc 75 m
10 Undefined Rc 25 m
11 Undefined Rc 7.5 m
12 Reserved for future definition
Table II-1-67. Base altitude encoding
Actual base altitude of transmitting Transmitted value Decoded base altitude (feet)
station (feet) of altitude (geo = WGS84 height, except as noted)
Unknown 0 altitude unknown
altitude < −1 305 1 < −1 300
−1 305 ≤ altitude < −1 295 2 −1 300
−1 295 ≤ altitude < −1 285 3 −1 290
↓ ↓ ↓
−15 ≤ altitude < −5 131 −10
−5 ≤ altitude < 5 132 0
5 ≤ altitude < 15 133 10
↓ ↓ ↓
7 995 ≤ altitude < 8 005 932 8 000
8 005 ≤ altitude < 8 015 933 8 010
8 015 ≤ altitude < 8 037.5 934 8 025
8 037.5 ≤ altitude < 8 062.5 935 8 050
8 062.5 ≤ altitude < 8 087.5 936 8 075
↓ ↓ ↓
71 912.5 ≤ altitude < 71 950 3 490 71 925
Actual base altitude of transmitting Transmitted value Decoded base altitude (feet)
station (feet) of altitude (geo = WGS84 height, except as noted)
71 950 ≤ altitude < 72 050 3 491 72 000
72 050 ≤ altitude < 72 150 3 492 72 100
72 050 ≤ altitude < 72 250 3 493 72 200
72 250 ≤ altitude < 72 350 3 494 72 300
72 350 ≤ altitude < 72 450 3 495 72 400
↓ ↓ ↓
129 950 ≤ altitude < 130 050 4 072 130 000
130 050 ≤ altitude 4 073 130 100
4 074 to 4 094 reserved
station on ground 4 095 station at 0 AGL
Table II-1-68. Report latency encoding and decoding
Transmitted value of data age

Report latency (millisecond) (da) Decoded latency (millisecond)
difference < 100 0 50
100 ≤ difference < 200 1 150
200 ≤ difference < 300 2 250
↓ ↓ ↓
900 ≤ difference < 1 000 9 950
1 000 ≤ difference < 1 200 10 1 100
1 200 ≤ difference < 1 500 11 1 350
1 500 ≤ difference < 2 000 12 1 750
2 000 ≤ difference < 3 000 13 2 500
3 000 ≤ difference < 4 000 14 3 500
4 000 ≤ difference or unknown 15 unknown
1.5.2.3 Variable data field format
The variable data field shall be available to carry additional information as may be required by another VSS user or
application. The content and format of the variable data field shall be identified by the information field ID (id). The
format of the variable data field corresponding to a given id shall be as specified in the appropriate application standard.
Note.— Up to 15 different information(in) fields can be addressed. Information fields 1 to 9 are given priority over
other information fields. Further short information fields may be addressed with the use of the extension field ID of 10
(see 1.5.2.2 and Table II-1-65).
1.5.2.4 Synchronization burst request
To request that a station transmit a synchronization burst with a specific information field, a station shall transmit a
general request burst to the appropriate application process as defined in 3.4.
1.5.2.5 Control (CTRL) DLPDU
1.5.2.5.1 Link management data shall be contained within a CTRL DLPDU encoded within the information (in)
field of a CTRL DLPDU (see Table II-1-57a) as defined in Table II-1-69.
1.5.2.5.2 The settings of the more bit (M), Initialize bit (IB) and Toggle bit (T) shall be as defined in 1.4. The
settings of the command/response status (c/r) and response expected (re) bits shall be as defined in 1.5.3.3.2.
Table II-1-69. CTRL DLPDU format
Bit number
CTRL DLPDU header n M T re c/r res 0 0 0
CTRL parameter 1: Parameter ID n+1 id8 id7 id6 id5 id4 id3 id2 id1
Parameter length n+2 lg8 lg7 lg6 lg5 lg4 lg3 lg2 lg1
Parameter value n+3 q18 q17 q16 q15 q14 q13 q12 q11
to to
n + 2 + lg qlg8 qlg7 qlg6 qlg5 qlg4 qlg3 qlg2 qlg1
more CTRL parameters
Note.— “ res” refers to bits available for the information field.
1.5.2.6 Broadcast link management burst
1.5.2.6.1 The broadcast link management data shall be contained within the information (in) field of a UCTRL
DLPDU (see Table II-1-57a) as defined in Table II-1-70.
Table II-1-70. UCTRL DLPDU format for broadcast of link management information
Bit number
UCTRL DLPDU 5 ucid5 ucid4 ucid3 ucid2 ucid1 0 1 1
CTRL parameter 1: n id8 id7 id6 id5 id4 id3 id2 id1
Parameter ID
to to
n + 2 + lg qlg8 qlg7 qlg6 qlg5 qlg4 qlg3 qlg2 qlg1
more CTRL parameters
1.5.2.6.2 The setting of the UCTRL identity (ucid) subfield shall be follows:
• ucid = 0 indicates that the UCTRL DLPDU is a ground station information frame (GSIF) containing data
defined in Table II-1-116a and used according to the procedures of 1.5.7.3.
• ucid = 1 indicates that the UCTRL DLPDU is a GSIF containing a Directory of Service (DoS) parameter
defined in 1.5.3.6.6.
• ucid = 2 indicates that the UCTRL DLPDU is a GSIF containing a channel management parameter defined in
3.7.2.
• ucid = 3 indicates that the UCTRL DLPDU contains a broadcast CTRL_CMD. The values of
command/response status (c/r) and response expected (re), defined in 1.5.3.3.2, shall be assumed to be equal
to zero (c/r = 0, re= 0).
• ucid = 4 indicates that the UCTRL DLPDU contains a UCTRL_DM parameter only as defined in 1.5.3.3.6.
• ucid = 5 to 31 are currently unassigned and available for future definition.
Note.— For ucid = 1, 2 and 4, the parameter ID and parameter length fields are absent from the UCTRL DLPDU
as defined in 1.5.3.3.6, 1.5.3.6.6 and 1.5.3.6.7.
1.5.3 Control (CTRL) parameter formats
1.5.3.1 Encoding
The CTRL parameters described in this section shall be included in the user data field of CTRL and UCTRL DLPDUs.
Except for parameter ID 00 (which must appear last), the parameters in a CTRL DLPDU shall be listed in non-
decreasing numeric order.
Note 1.— The tables in this section are divided into three major columns that define the field name, the bit
encoding and brief explanatory notes.
Note 2. – The CTRL parameters are extracted from the DLS sub-layer CTRL DLPDUs and sent to the LME.
1.5.3.2 VDL Mode 4 parameter identification
Bits 7 and 8 of the parameter ID field shall allow simple identification of the purpose of the parameter as defined in
Table II-1-71.
Table II-1-71. VDL Mode 4 parameter identifier purpose
Bit 8 Bit 7 Purpose

0 0 General purpose information parameter
0 1 Ground-initiated modification parameter
1 0 Mobile-initiated information parameter
1 1 Ground-initiated information parameter
1.5.3.3 General purpose information parameters
VDL Mode 4 shall use the CTRL parameters defined in 1.5.3.3.1 to 1.5.3.3.5 to allow mobile and ground-based LMEs
to transfer basic information to each other.
1.5.3.3.1 Parameter set identifier
1.5.3.3.1.1 The parameter set identifier shall be sent first in a group of non-VDL Mode 4 parameters and shall
indicate the set to which the parameters belong. It shall be encoded as per Table II-1-72.
Table II-1-72. Parameter set identifier encoding
Bit number
Field Octet 8 7 6 5 4 3 2 1 Notes
Parameter ID n+1 id8 id7 id6 id5 id4 id3 id2 id1 Parameter set identifier
1.5.3.3.1.2 There shall be no VDL Mode 4 parameter set identifier. VDL Mode 4 parameters shall always be sent
before any other parameter groups.
Note 1. — Parameter ID 00 hex means change to different set, in which case the parameter value will contain the
identity of the new parameter set. A parameter set identity starting with “ X” (equals 58 hex) is proprietary and not
defined in this manual.
Note 2. — Parameters defined in other standards may be included in the CTRL frame starting with the parameter
set identifier applicable to the particular standard.
Note 3.— Parameter ID FF hex is reserved for upper layer data, in which case the parameter value will contain
upper layer data.
1.5.3.3.2 Connection management parameter
The connection management parameter shall define the type of CTRL sent and the connection options negotiated for
that particular link. It shall be used in CTRL DLPDUs sent during link establishment and ground-based initiated ground
station handoff (ho), and shall be encoded as per Tables II-1-73, II-1-74 and II-1-75. An LME shall set the reserved bits
(res) to zero (res = 0) on transmission, and shall ignore the value of the reserved bits on receipt.
Table II-1-73. Connection management parameter
Bit number
Parameter ID n+1 0 0 0 0 0 0 0 1 Connection
management
Parameter value n+3 0 0 0 0 0 0 r h
Table II-1-74. Connection management parameter values
Bit Name Encoding

1 h h=0 No link currently established.
h=1 Link currently established.
2 r r=0 Link connection accepted.
r=1 Link connection refused.
3 to 8 Reserved Set to 0
Table II-1-75. Abbreviated Control (CTRL) names
Name c/r re h r Notes

GSIF — — — — Ground Station Identification Frame (GSIF) — sent by using
format defined in 1.5.2.6.
CTRL_CMD_LE 0 1 0 0
CTRL_CMD_LCR 0 0 0 1 Link Connection Rejection (LCR)
CTRL_CMD_HO 0 1 1 0 If re = 1, then Initiating Handoff (HO).
CTRL_CMD_HO 0 0 1 0 If broadcast and re = 0, then commanding a Broadcast Handoff.
If unicast and re = 0, then Requesting Handoff.
CTRL_RSP_LE 1 1 0 0
CTRL_RSP_LCR 1 1 0 1
CTRL_RSP_HO 1 1 1 0
1.5.3.3.3 CTRL sequencing parameter
The CTRL sequencing parameter shall define the CTRL sequence number (sss) and a CTRL re-transmission number
(rrr). It shall be encoded as per Table II-1-76. An LME shall increment the sequence number for every new CTRL
(setting the re-transmission field to zero (retrans = 0) on the first transmission) and shall increment the re-transmission
field after every re-transmission. In a CTRL_RSP, the sequence number shall be set to the value of the CTRL_CMD
sequence number that is generating the response (the re-transmission field shall be ignored), and the transmission field
set to zero when transmitted and ignored when received.
Table II-1-76. Control (CTRL) sequencing parameter
Bit number
Parameter ID n+1 0 0 0 0 0 0 1 0 CTRL sequencing
Parameter length n+2 0 0 0 0 0 0 0 1
Parameter value n+3 r4 r3 r2 r1 s4 s3 s2 s1
Note.— “ r” refers to re-transmission number; “ s” refers to sequence number.
1.5.3.3.4 Protocol options parameter
The protocol options parameter shall define which protocol options are supported by the transmitting station. It shall be
encoded as per Tables II-1-77 and II-1-78. When both this parameter and the connection management parameter are
included in a CTRL, the bit values for those options which are included in both parameters shall be determined by the
connection management parameter.
Table II-1-77. Protocol options parameter
Bit number
Parameter ID n+1 0 0 0 0 0 0 1 1 CTRL sequencing
Bit number
Parameter value n+3 0 0 0 0 0 b i 0
Note.— “ b” refers to broadcast link handoff; “ i” refers to initiated handoff.
Table II-1-78. Protocol options parameter values
Bit Name Encoding

2 i i=0 Does not support initiated handoff
i=1 Supports initiated handoff
3 b b=0 Does not support broadcast link handoff
b=1 Supports broadcast link handoff
1, 4 to 8 Reserved Set to 0
1.5.3.3.5 Link Connection Rejection (LCR) cause parameter
1.5.3.3.5.1 The LCR cause parameter shall define the reason for the refusal of the link connection request. The
parameter, which may be repeated, shall consist of a rejection cause code (c bits), backoff delay time in seconds
(d bits), and any additional data required by the various parameters. It shall be encoded as per Table II-1-79.
Table II-1-79. Link Connection Rejection (LCR) cause parameter
Bit number
Parameter ID n+1 0 0 0 0 0 1 0 0 LCR cause
Parameter value n+3 c8 c7 c6 c5 c4 c3 c2 c1 Cause
n+4 d16 d15 d14 d13 d12 d11 d10 d9 Delay
n+5 d8 d7 d6 d5 d4 d3 d2 d1
n+6 a8 a7 a6 a5 a4 a3 a2 a1 Additional data
1.5.3.3.5.2 Cause codes 00 hex to 7F hex shall apply to the responding station; cause codes 80 hex to FF hex
shall apply to the responding system and shall be encoded as per Table II-1-80. At least one copy of this parameter
shall be included whenever the link connection “ r” bit in the connection management parameter is set to one (r = 1);
this parameter shall not be included if the “ r” bit is set to zero (r = 0).
1.5.3.3.5.3 An LME receiving an LCR cause parameter less than 80 hex shall not transmit another CTRL_CMD
to that peer station for the duration of time designated in the LCR cause parameter.
1.5.3.3.5.4 An LME receiving an LCR cause parameter greater than 7F hex shall not transmit another
CTRL_CMD to that peer system for the duration of time designated in the LCR Cause parameter.
Note.— A mobile LME receiving a station-based cause code from one ground station may immediately transmit the
same CTRL_CMD to another ground station of the same ground system.
Table II-1-80. Cause code table
Cause Function Additional data encoding

00h Bad local parameter. g8 g7 g6 g5 g4 g3 g2 g1
The additional data block, which may be repeated, contains the p8 p7 p6 p5 p4 p3 p2 p1
parameter identifier (PI) of a parameter which cannot be satisfied
by this ground station. This cause will not be sent for an illegal
connection management parameter.
01h Out of link layer resources undefined
02h Out of packet layer resources
03h Terrestrial network not available
04h Terrestrial network congestion
05h Cannot support autotune
06h Station cannot support initiating handoff
07 to 7Eh Reserved
7Fh Other unspecified local reason
80h Bad global parameter identical to cause code 00
The additional data block, which may be repeated, contains the PI
of a parameter which cannot be satisfied by any ground station in
the system. This cause will not be sent for an illegal connection
management parameter.
81h Protocol violation. 0 0 0 u il d p c
The first octet of the additional data block contains:
1) command/response c/r bit (c bit) of the received CTRL;
2) re bit of the received CTRL;
3) Disconnected bit (d bit) shall be set to one (d = 1) if the
LME has no links with the remote LME (the unexpected bit shall
also be set to 1);
4) Illegal bit (il bit) shall be set to one (il = 1) if the LME
receives an illegal CTRL (i.e. not listed in Table II-I-97 or
described under 1.5.7);
5) Unexpected bit (u bit) shall be set to one (u = 1) if the LME
receives a legal CTRL which is not legal in the context in which it
was received.
The remaining octets contains the parameter value of the m8 m7 m6 m5 m4 m3 m2 m1
connection management parameter (m bits) if included in the
illegal CTRL.
After transmitting or receiving an LCR with this cause code, an
LME shall delete all of its links.
82h Ground system out of resources
83 to FCh Reserved
FDh Rejected for internal policy reasons
FEh No response from VSS user
FFh Other unspecified system reason
1.5.3.3.6 UCTRL_DM parameter
1.5.3.3.6.1 The UCTRL_DM parameter shall define the period of time until an LME will accept new
connections. If the most significant bit is a one, then all existing connections are disconnected without any automatic
recovery. The seven least significant bits encode a field of 0 to 127 seconds of time until new connections will be
accepted. The field shall be encoded per Table II-1-81.
Table II-1-81. UCTRL_DM parameter
Bit number
Parameter ID n+1 0 0 0 0 0 1 0 1
Parameter value n+3 uda nct7 nct6 nct5 nct4 nct3 nct2 nct1 Bits 1 to 7: new
connection time out
Bit 8: disconnect all flag
1.5.3.3.6.2 If the UCTRL_DM parameter is included within a UCTRL DLPDU with the ucid subfield set to 4
(ucid = 4), the UCTRL_DM parameter ID and parameter length shall be omitted and no other parameter included in the
UCTRL.
1.5.3.4 Mobile-initiated information parameters
A mobile LME shall use mobile-initiated information parameters to inform the ground station about the capabilities or
desires of that mobile. Ground LMEs shall not send these parameters.
1.5.3.4.1 Modulation support parameter
This parameter shall define a list of modulation schemes that are supported by the VDL Mode 4 system. This parameter
shall be sent on link establishment. It shall be encoded as shown in Tables II-1-82 and II-1-83.
Table II-1-82. Modulation support list encoding
Bit Position
Parameter ID n+1 1 0 0 0 0 0 0 0 Modulation support
Parameter value n+3 res res res res m4 m3 m2 m1 Mode
Note.— “ res” refers to bits available for the information field.
Table II-1-83. Modulation encoding
Encoding Meaning
0 to 1 Reserved
2 VDL Mode 2
Encoding Meaning
3 VDL Mode 3
4 VDL Mode 4 (Gaussian-filtered Frequency Shift Keying modulation)
5 to F Reserved
1.5.3.4.2 Acceptable alternate ground station parameter
The acceptable alternate ground station parameter shall define a list of ground stations in order of preference. This
parameter shall be defined by a list of DLS addresses encoded as per Table II-1-84. These shall be used by the ground
LME as possible alternate ground stations during handoffs, in case the proposed ground station is not acceptable to the
ground LME.
Table II-1-84. Acceptable alternative ground station parameter
Bit number
Parameter ID n+1 1 0 0 0 0 0 0 1 Alternate ground station
Parameter value n+3 0 0 0 0 0 g27 g26 g25 DLS address
n+4 g24 g23 g22 g21 g20 g19 g18 g17
n+5 g16 g15 g14 g13 g12 g11 g10 g9
n+6 g8 g7 g6 g5 g4 g3 g2 g1
1.5.3.4.3 Destination airport parameter
The destination airport parameter shall define the destination airport identifier of the mobile. It shall be encoded as four
8-bit ISO IA5 characters as defined in Table II-1-85.
Table II-1-85. Destination airport parameter
Bit number
Parameter ID n+1 1 0 0 0 0 0 1 0 Destination airport
Parameter value n+3 a8 a7 a6 a5 a4 a3 a2 a1 (first character)
n+4 b8 b7 b6 b5 b4 b3 b2 b1
n+5 c8 c7 c6 c5 c4 c3 c2 c1
n+6 d8 d7 d6 d5 d4 d3 d2 d1 (fourth character)
1.5.3.5 Ground-initiated modification parameters
A ground LME shall use the ground-initiated modification parameters to change the value of various parameters in one
or more mobiles. Mobile LMEs shall not send a CTRL containing these parameters.
1.5.3.5.1 DLS parameter
The DLS parameter shall define the values of ND1, ND2, ND3, TD1, and TD2 that a mobile shall use for priority levels
of Q1min to Q1max. These values shall be encoded as per Table II-1-86.
Table II-1-86. Data link service (DLS) parameter encoding
Bit position
Parameter DLS
n+1 0 1 0 0 0 0 0 0
ID parameter
Parameter
n+2 lg8 lg7 lg6 lg5 lg4 lg3 lg2 lg1
length
minimum
priority
(Q1min),
n+3 Q1max4 Q1max3 Q1max2 Q1max1 Q1min4 Q1min 3 Q1min 2 Q1min 1
maximum
priority
(Q1max)
n+4 ND18 ND17 ND16 ND15 ND14 ND13 ND12 ND11 ND1
Parameter n+5 res res TD213 TD113 ND29 ND111 ND110 ND19
value
n+9 TD18 TD17 TD16 TD15 TD14 TD13 TD12 TD11 TD1
n+10 TD212 TD211 TD210 TD29 TD112 TD111 TD110 TD19
n+11 TD28 TD27 TD26 TD25 TD24 TD23 TD22 TD21 TD2
1.5.3.5.2 VSS sub-layer parameter
This parameter defines the values of VS1, VS2, VS4 and VS5 that a mobile shall use, encoded as per Table II-1-87.
Table II-1-87. VSS sub-layer parameter encoding
Bit number
Parameter ID n+1 0 1 0 0 0 0 0 1 VSS sub-layer
parameter
Parameter n+2 0 0 0 0 0 0 1 1
length
Parameter n+3 VS54 VS53 VS52 VS51 VS14 VS13 VS12 VS11 VS1, VS5 (dB)
value n+4 0 0 VS26 VS25 VS24 VS23 VS22 VS21 VS2 (NM)
n+5 0 VS47 VS46 VS45 VS44 VS43 VS42 VS41 VS4
1.5.3.5.3 QoS parameter
This parameter defines the QoS parameters that a mobile shall use for the priority levels of Q1min to Q1max, encoded as
per Table II-1-88.
Table II-1-88. Quality of service (QoS) parameter encoding
Bit number
Parameter n+1 0 1 0 0 0 0 1 0 QoS
ID parameter
Parameter n+2 lg8 lg7 lg6 lg5 lg4 lg3 lg2 lg1
length
Parameter n+3 Q1max4 Q1max3 Q1max2 Q1max 1 Q1min4 Q1min3 Q1min2 Q1min1
value n+4 Q2a8 Q2a7 Q2a6 Q2a5 Q2a4 Q2a3 Q2a2 Q2a1 Q2a (NM)
n+5 Q2b8 Q2b7 Q2b6 Q2b5 Q2b4 Q2b3 Q2b2 Q2b1 Q2b (NM)
n+6 Q2c8 Q2c7 Q2c6 Q2c5 Q2c4 Q2c3 Q2c2 Q2c1 Q2c (NM)
n+7 Q2d8 Q2d7 Q2d6 Q2d5 Q2d4 Q2d3 Q2d2 Q2d1 Q2d (NM)
n+8 Q2d10 Q2d9 Q2c10 Q2c9 Q2b10 Q2b 9 Q2a10 Q2a9
n+9 0 0 0 Q45 Q44 Q43 Q42 Q41 Q4
1.5.3.5.4 Measure of the uncertainty of reservation data (m2) filter parameters
Table II-1-89 shall define the encoding of parameters for the m2 filter to be used by a mobile. M2_inc, the filter
increment for receiver blocking check, shall be encoded as an 8-bit unsigned integer. M2_limit, the filter threshold for
receiver blocking check, shall be encoded as a 16-bit unsigned integer.
Table II-1-89. m2 filter parameter encoding
Bit number
Parameter ID n+1 0 1 0 0 0 0 1 1 m2 filter parameters
Parameter
n+2 0 0 0 0 0 0 1 1
length
M2_inc
parameter n+3 i8 i7 i6 i5 i4 i3 i2 i1 M2_inc
value
M2_limit n+4 l16 l15 l14 l13 l12 l11 l10 l9
parameter M2_limit
value n+5 l8 l7 l6 l5 l4 l3 l2 l1
1.5.3.5.5 CG1 filter parameters
The values of parameters used by mobiles for the CG1 shall be as defined in Table II-1-90. CG1_plea, the minimum
pool size of peer stations for plea, shall be encoded as an 8-bit unsigned integer. CG1_range, the range limit used in
digital filter for “ exposure” determination, shall be encoded as an 8-bit unsigned integer. TL5, the maximum delay for
plea response, shall be encoded as an 8-bit unsigned integer. CG1_inc, the digital filter increment when a
synchronization burst from a previously unknown station is detected, shall be encoded as an 8-bit unsigned integer.
1/CG1_decay (CG1_decay is the decay rate for CG1 filter) shall be encoded as an 8-bit unsigned integer. CG_limit, the
digital filter threshold which triggers network entry due to station being “ expose,” shall be encoded as a 16-bit
unsigned integer.
Table II-1-90. CG1 filter parameter encoding
Bit number
CG1 filter
Parameter ID n+1 0 1 0 0 0 1 0 0
parameters
CG1_plea
n+3 p8 p7 p6 p5 p4 p3 p2 p1 CG1_plea
parameter value
CG1_range
n+4 r8 r7 r6 r5 r4 r3 r2 r1 CG1_range
parameter value
TL5 parameter
n+5 t8 t7 t6 t5 t4 t3 t2 t1 TL5
value
CG1_limit n+6 l16 l15 l14 l13 l12 l11 l10 l9
CG1_limit
parameter value n+7 l8 l7 l6 l5 l4 l3 l2 l1
CG1_inc parameter
n+8 i8 i7 i6 i5 i4 i3 i2 i1 CG1_inc
value
1/CG1_decay
n+9 d8 d7 d6 d5 d4 d3 d2 d1 1/CG1_decay
parameter value
1.5.3.5.6 Autotune frequency parameter
This parameter defines the frequency and modulation scheme that a mobile LME shall use to reply to a ground station
listed in the replacement ground station list parameter. This parameter shall be sent by a ground LME when an autotune
is required. The parameter shall be encoded as a 16-bit field as per Table II-1-91. The modulation (m bits) subfield shall
be defined as per Table II-1-83. The frequency (f bits) subfield shall be defined as per Table II-1-30.
Table II-1-91. Autotune parameter encoding
Bit number
Parameter ID n+1 0 1 0 0 0 1 0 1 Autotune frequency
Parameter
n+2 0 0 0 0 0 0 1 0
length
n+3 m4 m3 m2 m1 f12 f11 f10 f9
Parameter value
n+4 f8 f7 f6 f5 f4 f3 f2 f1
1.5.3.5.7 Maximum number of missed reservations parameter
This parameter shall define the number of consecutive missed reservations that will be used to determine that a station
is unreachable. This parameter shall be sent by a ground LME, as required, to adjust the timeliness of the LEAVE event.
The parameter shall be encoded as per Table II-1-92. The parameters [L1 (maximum number of missed reservations),
TL3 (inter-miss timer) and TL4 (leave generation latency)] shall be defined as per Table II-1-93.
Note 1.— The range of the L1 counter is 1 to 255. The value of 0 (L1=0) is invalid.
Note 2.— When situated in the centre of the service volume the generation of the LEAVE event should be
suppressed for a period of time on the assumption that the data link will become available again, thus the value of TL4
should provide sufficient time to complete a handoff. When on the edge of a service volume, a LEAVE event should be
generated as soon as the unreachability is declared internally, thus the value of TL4 should be low.
Table II-1-92. L1 parameter encoding
Bit number
Parameter ID n+1 0 1 0 0 0 1 1 0
Parameter
n+2 0 0 0 0 0 0 0 1
length
Parameter value n+3 L18 L17 L16 L15 L14 L13 L12 L11 L1 counter
n+4 0 0 0 TL35 TL34 TL33 TL32 TL31 TL3 timer
n+5 TL48 TL47 TL46 TL45 TL44 TL43 TL42 TL41 TL4 timer
Table II-1-93. Management entity system parameters

L1 Maximum number of missed 1 255 3 1
reservations
TL1 Maximum link overlap time
initiating 0 sec 255 sec 20 sec 1 sec
responding 0 sec 255 sec 60 sec 1 sec
TL2 Link initialization time 5 sec 25 sec 6 sec 1 millisecond
TL3 Inter-miss timer 0 31 sec 5sec 1 sec
TL4 Leave event generation latency 0 sec 255 sec 20 sec 1 sec
1.5.3.5.8 Replacement ground station list parameter
The replacement ground station list parameter shall define a list of ground stations in order of ground LME preference.
This parameter shall be encoded as a list of DLS addresses in 32-bit fields as per Table II-1-94. These addresses shall
be used by the mobile LME as possible alternate ground stations during handoffs, in case the proposed ground station is
not acceptable to the LME.
1.5.3.5.9 Random access parameter
The random access parameter shall define p (persistence), VS3 (maximum number of access attempts) and TM2
(channel busy timer) that are used within the random access protocol, and shall be encoded as per Table II-1-95.
Note.— p is encoded as hexadecimal 00 (= decimal 1/256) to hexadecimal FF (= decimal 256/256).

Table II-1-94. Replacement ground station list parameter encoding
Bit number
Replacement ground station

Parameter ID n+1 0 1 0 0 0 1 1 1
list parameter
n+3 0 0 0 0 0 g27 g26 g25
n+4 g24 g23 g22 g21 g20 g19 g18 g17
Parameter value
n+5 g16 g15 g14 g13 g12 g11 g10 g9
n+6 g8 g7 g6 g5 g4 g3 g2 g1
Table II-1-95. Random access parameter encoding
Bit number
Random access
Parameter ID n+1 0 1 0 0 1 0 0 0
parameter encoding
n+3 p8 p7 p6 p5 p4 p3 p2 p1 p
n+4 VS38 VS37 VS36 VS35 VS34 VS33 VS32 VS31
Parameter value
n+5 VS316 VS315 VS314 VS313 VS312 VS311 VS310 VS39
n+6 TM28 TM27 TM26 TM25 TM24 TM23 TM22 TM21
1.5.3.5.10 Re-transmission parameter
The re-transmission parameter shall define the value of Q5 (VSS re-transmission parameters) that a mobile MAC shall
use for priority levels Q1min to Q1max. It shall be encoded as per Table II-1-96.
Table II-1-96. Re-transmission parameter encoding
Bit number
Re-transmission
Parameter ID n+1 0 1 0 0 1 0 0 1
parameter
Parameter
n+2 lg8 lg7 lg6 lg5 lg4 lg3 lg2 lg1
length
Parameter minimum priority

value n+3 Q1max4 Q1max3 Q1max 2 Q1max1 Q1min4 Q1min 3 Q1min 2 Q1min 1 (Q1min), maximum
priority (Q1max)
n+4 min8 min7 min6 min5 min4 min3 min2 min1
Q5min
n+5 0 min15 min14 min13 min12 min11 min10 min9
n+6 max8 max7 max6 max5 max4 max3 max2 max1 Q5max
Bit number
n+7 0 max15 max14 max13 max12 max11 max10 max9
n+8 mult8 mult7 mult6 mult5 mult4 mult3 mult2 mult1 Q5mult
n+9 exp8 exp7 exp6 exp5 exp4 exp3 exp2 exp1 Q5exp
n+10 0 0 0 0 num4 num3 num2 num1 Q5num
n+11 0 wait7 wait6 wait5 wait4 wait3 wait2 wait1 Q5wait
1.5.3.5.11 Timer TL1 (maximum link overlap time) parameter
The timer TL1 parameter shall define the value of timer TL1 (in seconds) that the initiating and responding LMEs shall
use. It shall be encoded as two 8-bit integers per Table II-1-97.
Table II-1-97. Timer TL1 parameter encoding
Field Octet Bit number Notes

8 7 6 5 4 3 2 1
Parameter ID n+1 0 1 0 0 1 0 1 0 Timer TL1 parameter
n+3 i8 i7 i6 i5 i4 i3 i2 i1 (initiating)
Parameter value
n+4 r8 r7 r6 r5 r4 r3 r2 r1 (responding)
1.5.3.5.12 Ground station address filter parameter
This parameter shall define the DLS address of the ground station from which links are handed off. This parameter
shall be sent in a CTRL_CMD and a receiving mobile LME shall process the CTRL_CMD only if it has a link to the
identified ground station. The ground station address filter shall be encoded as defined in Table II-1-98.
Table II-1-98. Ground station address filter parameter
Bit number Notes

Field Octet 8 7 6 5 4 3 2 1
Parameter ID n+1 0 1 0 0 1 0 1 1 Ground station address filter
n+3 0 0 0 0 0 g27 g26 g25
n+4 g24 g23 g22 g21 g20 g19 g18 g17
Parameter value DLS address
n+5 g16 g15 g14 g13 g12 g11 g10 g9
n+6 g8 g7 g6 g5 g4 g3 g2 g1
1.5.3.5.13. Broadcast connection parameter
The broadcast connection parameter shall define a single mobile’ s link attributes for a new link, i.e. the station address
whose link was successfully established on the new link. As per Table II-1-99, the mobile id (a bits) subfield shall be
the station address.
Table II-1-99. Broadcast connection parameter encoding
Bit number
Ground station address
Parameter ID n+1 0 1 0 0 1 1 0 0
filter parameter
Parameter value n+3 0 0 0 0 0 a27 a26 a25 mobile ID

n+4 a24 a23 a22 a21 a20 a19 a18 a17
n+5 a16 a15 a14 a13 a12 a11 a10 a9
n+6 a8 a7 a6 a5 a4 a3 a2 a1
1.5.3.6 Ground-initiated information parameters
A ground LME shall use ground-initiated information parameters to inform one or more mobile LMEs about the
capabilities of that ground-based system. Mobile LMEs shall not send these parameters.
1.5.3.6.1 Airport coverage indication parameter
The airport coverage indication parameter shall define a list of four-character airport identifiers of airports where the
ground station can support communication with a mobile on the ground. Each four-character identifier shall be encoded
as four 8-bit ISO IA5 characters as per Table II-1-100.
Table II-1-100. Airport coverage indication parameter encoding
Bit number
Airport coverage indication
Parameter ID n+1 1 1 0 0 0 0 0 0
parameter
n+3 a8 a7 a6 a5 a4 a3 a2 a1 (first character)
n+4 b8 b7 b6 b5 b4 b3 b2 b1
Parameter value
n+5 c8 c7 c6 c5 c4 c3 c2 c1
1.5.3.6.2 Nearest airport parameter
The nearest airport parameter shall define the four-character airport ID of the airport nearest the ground station. It shall
be encoded as four 8-bit ISO IA5 characters as per Table II-1-101. The nearest airport parameter shall not be included
in a CTRL if the Airport Coverage Indication is included.
Table II-1-101. Nearest airport parameter encoding
Bit number
Parameter ID n+1 1 1 0 0 0 0 0 1 Nearest airport parameter
n+3 a8 a7 a6 a5 a4 a3 a2 a1 (first character)
n+4 b8 b7 b6 b5 b4 b3 b2 b1
Parameter value
n+5 c8 c7 c6 c5 c4 c3 c2 c1
1.5.3.6.3 ATN router Network Entry Titles (NETs) parameter
The ATN router NETs parameter shall define a list of ATN air-ground routers identified by the “ administration
identifier” (ADM) and “ administration region selector” (ARS) subfields of their NETs. It shall be encoded as per
Table II-1-102.
Table II-1-102. ATN router NETs parameter encoding
Bit number

ATN router NETs
Parameter ID n+1 1 1 0 0 0 0 1 0
parameter
n+3 a24 a23 a22 a21 a20 a19 a18 a17
Administration identifier
n+4 a16 a15 a14 a13 a12 a11 a10 a9 (ADM) subfield
Parameter value n+5 a8 a7 a6 a5 a4 a3 a2 a1
n+6 r24 r23 r22 r21 r20 r19 r18 r17
Administration region
n+7 r16 r15 r14 r13 r12 r11 r10 r9 selector (ARS) subfield
n+8 r8 r7 r6 r5 r4 r3 r2 r1
1.5.3.6.4 Ground-based system mask parameter
The ground-based system mask parameter shall define the ground-based system mask. It shall be encoded as a 27-bit
mask in a 32-bit field as per Table II-1-103.
Table II-1-103. Ground-based system mask parameter encoding
Bit number
Ground-based system mask
Parameter ID n+1 1 1 0 0 0 0 1 1
parameter
Bit number
n+3 0 0 0 0 0 g27 g26 g25
n+4 g24 g23 g22 g21 g20 g19 g18 g17
Parameter value
n+5 g16 g15 g14 g13 g12 g11 g10 g9
n+6 g8 g7 g6 g5 g4 g3 g2 g1
1.5.3.6.5 Frequency support list
This parameter, encoded as per Table II-1-104, shall provide the mode (m), frequency (f), ground station address
information (g) and the relative location of the ground station listed. The location shall be encoded as an offset relative
to the position of the source station: easterly offset (eo) (west is negative)and northerly offset (no) (south is negative)
shall each be 8-bit parameters with a resolution of 4 NM encoded using two’ s complement math. The mode shall be
encoded as per Table II-1-83 and the frequency shall be encoded as per Table II-1-30.
Note.— The usage of this parameter is defined in 1.5.7.1.2.
Table II-1-104. Frequency support list encoding
Bit number
Parameter ID n+1 1 1 0 0 0 1 0 0 frequency support list
n+3 m4 m3 m2 m1 f12 f11 f10 f9
mode/frequency
n+4 f8 f7 f6 f5 f4 f3 f2 f1
n+5 0 0 0 0 0 g27 g26 g25
n+6 g24 g23 g22 g21 g20 g19 g18 g17 ground station
Parameter value
n+7 g16 g15 g14 g13 g12 g11 g10 g9 identification
n+7 g8 g7 g6 g5 g4 g3 g2 g1
n+8 eo8 eo7 eo6 eo5 eo4 eo3 eo2 eo1 easterly offset
n+9 no8 no7 no6 no5 no4 no3 no2 no1 northerly offset
1.5.3.6.6 DoS parameter
1.5.3.6.6.1 The DoS parameter shall be encoded as defined in Table II-1-105.
Table II-1-105. Directory of Service (DoS) message encoding
Bit number

Parameter ID n+1 1 1 0 0 0 1 0 1 DOS parameter
Parameter
n+2 lg8 lg7 lg6 lg5 lg4 lg3 lg2 lg1 length
length
Bit number

entry number (ent),
current channel subfield
n+3 gsc ai3 ai2 ai1 ent4 ent3 ent2 ent1
additional service info
(ai); GSC flag (gsc)
n+4 si8 si7 si6 si5 si4 si3 si2 si1 service information (si)
application number
n+5 res res res res anum4 anum3 anum2 anum1 (anum) res field absent if
anum field is absent.
n+6 a18 a17 a16 a15 a14 a13 a12 a11 application 1 (a1)
n+7 to
n+8 ak8 ak7 ak6 ak5 ak4 ak3 ak2 ak1 application k (ak)
Parameter
channel subfield:
value n+9 gsc ai3 ai2 ai1 f12 f11 f10 f9 additional service info
(ai); GSC flag (gsc)
n+10 f8 f7 f6 f5 f4 f3 f2 f1 frequency (f)
n+11 si8 si7 si6 si5 si4 si3 si2 si1 service information (si)
application number
n+12 res res res res anum4 anum3 anum2 anum1
(anum)
n+13 a18 a17 a16 a15 a14 a13 a12 a11 application 1 (a1)
n+14 to
n+15 ak8 ak7 ak6 ak5 ak4 ak3 ak2 ak1 application k (ak)
service information type
n+16 sit6 sit5 sit4 sit3 sit2 sit1 x x
(sit)
Note.— Bits denoted “ x” may be used within the reservation field; “ res” refers to bits available for the information field.
1.5.3.6.6.2 If the DoS parameter is included within a UCTRL DLPDU, with the UCTRL identity (ucid) subfield
set to one (ucid = 1), then the DoS parameter ID and parameter length shall be omitted and no other parameter included
in the GSIF.
Note.— This makes it possible to provide a single slot transmission of basic DoS information
1.5.3.6.6.3 The current channel subfield shall always be present. One, two or more other channel subfields
(channel 1, channel 2, etc) shall be added as required in a continuous bit sequence. The contents of the channel
subfields shall be determined by the additional service information (ai) subfield as defined in Table II-1-106. The
service information type (sit) subfield shall follow the last channel subfield. The subfields within each channel subfield
shall be computed as defined in Table II-1-106.
Table II-1-106. Directory of Service (DoS) message subfield encoding

entry number (ent) 0 to 15 ent = entry number of DoS message Up to 16 different DoS parameters
can be accommodated or associated
with each ground station
transmitting DoS parameters.

frequency (f) See Table II-1-30. indicates the channel which
Absent in current channel subfield. provides DoS.
GSC flag (gsc) 0 to 1 Set to 1 if channel is a GSC.
additional service 0 to 7 bit 1: set to 1 if si field included.
information (ai) bit 2: set to 1 if anum field present.
bit 3: set to 1 if application (a) subfield(s) present.
service information 0 to 63 Defines services indicated by each bit in the
type (sit) service information (si) field. As defined by
application standards.
service information Contains 8 Bits indicate the services provided on the
(si) single bit flags indicated channel.
bit set if service is available.
Meaning of bits defined by application standards.
Field absent if ai bit 1 = 0.
application number 0 to 15 Indicates the number of application fields present.
(anum) Field absent if ai bit 2 = 0.
application (a) 0 to 255 Identifies a single service defined by application
standards.
Field absent if ai bit 3 = 0.
If ai bit 1 = 0 and ai bit 2 ≠ 0, only one application
subfield shall be present.
1.5.3.6.6.4 Each DoS parameter shall override any previous DoS parameter from the same ground station with
the same entry number (ent).
1.5.3.6.6.5 The upper bit of the application field shall be used as an extension field, so that a “ 0” indicates a one
octet field and a “ 1” indicates that the ID continues in the next byte.
1.5.3.6.6.6 Application fields shall be allocated as defined in Table II-1-107.
Table II-1-107. Allocation of application (a) fields
Encoding (decimal equivalent) Allocation

0 to 3 Defined in Table II-3-23.
4 to 31 Reserved for future allocation by ICAO.
32 to 63 Reserved for private allocation by service provider.
128 to 255 Reserved for future use (extension of application field).
1.5.3.6.6.7 Service information type (sit) fields shall be allocated as defined in Table II-1-108.
Table II-1-108. Allocation of service information type (sit) fields
Encoding (decimal equivalent) Allocation

0 to 3 Defined in Table II-3-24.
4 to 31 Reserved for future allocation by ICAO.
48 to 63 Reserved for future allocation by ICAO delegated authority.
1.5.3.6.7 Channel management parameter
1.5.3.6.7.1 The channel management parameter shall have a parameter ID equal to C6 hex and shall be encoded
as defined in 3.7.2.
1.5.3.6.7.2 If the channel management parameter is included within a UCTRL DLPDU, with the ucid subfield set
to two (ucid = 2), the channel management parameter ID and parameter length shall be omitted and no other parameter
included in the UCTRL DLPDU.
1.5.4 LME timers and parameters
The LME service shall implement the system parameters defined in Table II-1-93 and detailed in 1.5.4.1 to 1.5.4.3.
1.5.4.1 Counter L1 (maximum number of missed reservations) and timer TL3 (inter-miss timer)
Parameter L1 shall be the maximum number of missed reservations before a station assumes that a peer station is
unreachable. There shall be one counter L1 per peer station as well as one per frequency (per peer station). Counter L1
(both the all-frequencies and the appropriate frequency elements of the counter) shall be set to zero (L1 = 0) when a
transmission is received from a peer station. Counter L1 (both the all-frequencies and the appropriate frequency
elements) shall be incremented when no transmission is received from a peer station for which there was a prior
reservation made by the peer station for itself, if the particular L1 has not been incremented in the prior TL3 seconds.
When the all-frequencies counter L1 exceeds the maximum number of missed reservations (the value of parameter L1),
the peer station shall be marked as unreachable in the PECT (see 1.5.6.2) and it shall attempt to hand off to another
ground station following the procedures of 1.5.7. Stations marked as unreachable shall be retained in the PECT for a
time period of not less than 60 minutes. When the single-frequency counter L1 exceeds the maximum number of
missed reservations, the peer station shall be marked unreachable on that frequency.
Note 1.— The reason that L1 is not incremented when no response is received in a slot that another station had
reserved for its peer is the possibility that the reservation itself was lost and thus no reliable inference can be made on
the reachability of the peer station. Lost or missed reservation in this context means no decoded transmission, i.e. the
receiving station has not decoded a transmission it was expecting in a slot reserved for the sending station.
Note 2.— PECT entries are retained for a period of time in order to stabilize acquisition and track re-initialization
performance for stations at the limits of coverage, and also to support potential search and rescue applications that
may be developed in the future. Reservations for unreachable stations are retained in the reservation table and allowed
to expire normally. These reservations represent real transmissions that may be expected to occur at the indicated
times.
Note 3.— The timeliness of the generation of LEAVE events depends on the value of the L1 counter and the number
of reservations known to have been made by a station within a time interval. If the TL3 timer is set to a low value, then
a string of messages closely spaced in time that are lost due to aircraft banking, antenna shadowing effects, and
interference may be considered as independent indicators. If the L1 counter or the TL3 timer is set too low, then a
LEAVE event may be generated incorrectly. A ground station can readjust the L1 counter and TL3 timer with the CTRL
parameter defined in 1.5.3.5.7 in order to minimize the likelihood of a LEAVE event false alarm.
1.5.4.2 Timer TL1 (maximum link overlap time)
Timer TL1 shall be set to the maximum time to enable the initiating and responding LMEs to maintain the old link
during handoffs (HO). The LME initiating the handoff shall start its timer TL1 when it receives an CTRL_RSP_HO.
The LME responding to the handoff shall start its timer TL1 when it transmits its CTRL_RSP_HO. The initiating LME
shall never restart its timer TL1; the responding LME shall restart its timer TL1 if it re-transmits a CTRL_RSP_HO.
Timer TL1 shall be cancelled if either the old or new link is prematurely disconnected. After timer TL1 expires, each
LME shall silently disconnect its half of the old link.
Note.— There is one timer TL1 per LME.
1.5.4.3 Parameters TL2 (link initialization time)
1.5.4.3.1 The parameter TL2 shall control the re-transmission of CTRL DLPDUs for which an expected response
has not been received.
1.5.4.3.2 Timer TL2 shall be set after the transmission of a CTRL for which a response is expected. Timer TL2
shall be cleared upon receipt of a CTRL DLPDU from the peer LME. If timer TL2 expires, the LME shall attempt to
hand off to another ground station in accordance with the procedures of 1.5.7.
1.5.4.4 Timer TL4 (LEAVE generation latency)
Timer TL4 shall control the triggering of LEAVE events. Timer TL4 shall be set whenever the LME initiates a handoff
because of an invalid link. Timer TL4 shall be cancelled upon completion of a successful handoff. If timer TL4 expires,
the LME shall generate a LEAVE event as described in Chapter 2. Timer TL4 shall never be restarted.
Note 1.— There is one TL4 timer per peer station.
Note 2.— Instances of when a link may be considered invalid are upon expiration of Q5num or Q5wait, upon
surpassing of L1, and upon receipt of a DM/DISC or a UCTRL_DM.
1.5.5 LME procedures
1.5.5.1 Synchronization burst procedures
a) All stations shall transmit the appropriate synchronization burst defined in 1.5.2, depending on whether it is a
mobile station or a ground station. If the synchronization burst is transmitted with a periodic broadcast
protocol, it shall use default QoS parameters except as defined in Table II-1-109. If the synchronization burst
is not transmitted with a periodic broadcast protocol, slot selection shall use either the default QoS parameters
defined for the selected reservation protocol or the user-supplied QoS parameters.
Table II-1-109. Synchronization burst parameters

V11 Nominal periodic rate 6
Q1 Priority 14
Q3 Replace queued data TRUE
b) The values of the subfields shall be the latest available data that can be obtained by the station at the start of
the slot that is two slots before the first slot of the intended transmission.
c) Where time is used to calculate fields in the transmission, it shall be the time associated with the latitude and
longitude data contained in the transmission.
1.5.5.1.1 Transmission of synchronization bursts supporting applications
1.5.5.1.1.1 A station shall transmit synchronization bursts in accordance with a request from a peer station as
described in 1.5.2.4, at the specified rate, and containing the information (in) field corresponding to the requested
information field ID (r-id).
1.5.5.1.1.2 The station shall transmit additional synchronization bursts required to meet the demands of any
application. In the event that an application request requiring the transmission of synchronization bursts is delivered by
means of a directed request, the required bursts shall be transmitted in the slots reserved by the directed request
protocol.
Note.— The interaction between the LME and the application of specific requirements for transmission of
synchronization bursts is a local issue.
1.5.5.1.2 Mobile stations
Whenever a mobile station is not directed to transmit synchronization bursts on any frequency, it shall transmit mobile
synchronization bursts at least once per M1 (number of slots per superframe) slots on all GSCs, which it can receive.
When transmitting autonomously on the GSCs, mobile stations shall use the standard parameters defined in
Table II-1-65.
Note.— Upon termination of all directed synchronization burst transmissions on a channel(s) other than the GSCs,
mobile stations may employ the network entry procedures as described in 1.5.5.3 to quickly enter the GSC network(s).
1.5.5.1.3 Ground stations
1.5.5.1.3.1 Ground broadcast re-connect alert
A ground system that supports link connections shall transmit one of the following DLPDUs:
a) a UCTRL_DM at least 3 times during the first minute of operation of every ground station; and
b) a broadcast connection handoff from an appropriate ground station at least 3 times during the first minute
when any ground station reboots.
Note.— This may be accomplished either in fixed reservations or delayed burst transmissions.
A set of ground stations should ensure that sufficient synchronization bursts are available to support the derivation of
secondary timing.
Note.— To optimize the secondary navigation calculations, the transmissions from the various ground stations
should all be in contiguous slots so that aircraft movement does not lead to additional error.
1.5.5.1.4 Procedures for conflict resolution
For the purposes of assessing whether or not a reservation conflicts with another reservation for a synchronization burst,
the station shall apply the procedures defined in 1.3.6.5, except that the QoS parameters defined in Table II-1-110 or
user-supplied parameters shall be applied when reserving the synchronization burst.
Note.— These parameters place tighter constraint than the defaults for original slot selection, which would always
result in a slot being selected. The tighter constraint forces the stream to dither to find slots that might be available at
higher levels and hence reduces the probability of slot conflict.
Table II-1-110. Synchronization burst parameters for conflict resolution
Symbol Parameter name Value

Q1 Priority As per information field.
1.5.5.2 Peer Entity Contact Table (PECT)
Every station shall maintain a table of all known stations. For each station, the table shall include:
a) the type of the station;
b) a copy of the last type of broadcast burst;
c) the time of the last transmission; and
d) a L1 counter.
The ability to reach a peer station shall be assumed to have been lost after attempting L1 number of missed reservations.
1.5.5.3 Network entry protocol specifications
1.5.5.3.1 Network entry parameters
The network entry protocol shall implement the system parameters defined in Table II-1-111.
Note.— There is a separate CG1 filter for each channel which implements the exposure filter.
1.5.5.3.1.1 Parameter CG1_plea (minimum pool size of peer stations for plea)
CG1_plea shall define the minimum number of viable peer stations which must be identified before a plea can be
issued. The plea target shall be selected uniformly from a set of CG1_plea viable peer stations.
Table II-1-111. Plea parameters

CG1_plea Minimum pool size of peer stations 1 256 2 1
for plea
CG1_range Range limit used in digital filter for 0 NM 255 NM 100 NM 1 NM
“ exposure” determination
TG6 Maximum delay for plea response 0.1 sec 16 sec 2 sec 0.1 sec
CG1_limit Digital filter threshold which 1 65 536 2 000 1
triggers network entry due to
station being “ exposed”
CG1_inc Digital filter increment when a 1 256 max{min[5 • 1
synchronization burst from a (V11−1), 256], 1}
previously unknown station is
detected
CG1_decay Decay rate for CG1 filter 1/256 1 247/256 0
CG1_reach Maximum unreachability time 1 min 15 min 3 min 1 min
TL6 Minimum time delay for CG1 filter 1 slot 255 slots 75 slots 1 slot
Note.— There is a separate CG1 filter for each channel which implements the exposure filter.
1.5.5.3.1.2 Parameter CG1_range (range limit used in digital filter for “ exposure” determination)
CG1_range shall define the threshold beyond which newly identified peer stations are disregarded for purposes of
determining “ exposure” .
Note 1.— This digital filter is intended to trigger network re-entry in cases where a station identifies a large
number of new peer stations in a short period of time (e.g. during climb-out from an airport or when crossing a
mountain range). Conversely, since it is normal for new stations to be identified at great range, stations at great range
should not be included in the determination of when a station has become “ exposed” .
Note 2.— If the CG1_range cannot be determined because a station is not aware of its own location, it is set to a
default value of zero (CG1 = 0). Therefore, unless a service provider has specifically reset CG1_range = 0 by a
previous command detected by the station, all newly identified peer stations will increment the value of the filter.
1.5.5.3.1.3 Parameter TL5 (maximum delay for plea response)
TL5 shall specify the maximum time interval allowed between receiving a plea and transmitting a plea response. A
station receiving a plea shall attempt to respond as quickly as possible. If a response cannot be generated in TL5
seconds, the station shall purge the plea and not respond.
Note.— This is intended to avoid creating reservations that will not be used.
1.5.5.3.1.4 Parameter CG1_limit (digital filter threshold which triggers network entry due to station being “ exposed” )
When CG1 is greater than or equal to CG1_limit (CG1 CG1_limit), the station shall consider itself “ exposed” (i.e. it
has recently detected a large number of users which were not previously in its PECT, indicating that its reservation
table may be incomplete). Consistent with the requirements of 1.5.5.3, the station shall then reset CG1 = 0 and perform
network entry on the affected channel.
1.5.5.3.1.5 Parameter CG1_inc (digital filter increment when a synchronization burst

from a previously unknown station is detected)
CG1_inc shall be the value by which CG1 is incremented each time:
a) a station has been unreachable for at least CG1_reach minutes; or
b) a previously unknown peer station is detected with a station-to-station range of less than or equal to
CG1_range; or
c) a previously unknown peer station is detected with station-to-station range which is indeterminate.
1.5.5.3.1.6 Parameter CG1_decay (decay rate for CG1 filter)
CG1_decay shall be the per second decay rate for CG1.
CG1_decay should be selected in such a way that CG1 represents an approximate metric for the uncertainty in
reservation information that is associated with newly detected stations.
1.5.5.3.1.8 Parameter CG1_reach (maximum unreachability time)
CG1_reach shall be the maximum time allowed between two successfully received transmissions from a peer station
without increasing the CG1_filter in accordance with the procedures defined in Table II-1-112.
Table II-1-112. Asynchronous events affecting value of management filter CG1
Events Values of CG1

Station detects a synchronization burst from a station which has been CG1new = CG1old + CG1_inc
unreachable on the channel for at least CG1_reach minutes or from a previously
unknown station at a station-to-station range which can either be calculated as
less than CG1_range or is indeterminate.
Station detects a synchronization burst from a station which has been CG1new = CG1old
unreachable on the channel for less than CG1_reach minutes or from a
previously unknown station at a station-to-station range which can be calculated
as greater or equal to CG1_range.
Once per second. CG1new = truncate(CG1old • CG1_decay)
1.5.5.3.1.9 Parameter TL6 (minimum time delay for plea)
1.5.5.3.1.9.1 TL6 shall be the minimum time delay, measured in slot intervals, between the initiation of network
entry procedures and the issuance of the first plea on the channel. It is also the retry interval between successive
examinations of the pool of viable peer stations for plea. TL6 shall be set when a station tunes to a new frequency on
which it has less than the nominal update rate (nr) reservations for synchronization bursts over the next M1 slots; or if
there are no viable peer stations for the plea upon expiration.
1.5.5.3.1.9.2 TL6 shall be cleared when the number of reservations for synchronization bursts, over the next M1
slots, equals or exceeds the nominal update rate (nr) or when the station has monitored the frequency for M1 slots since
the initiation of network entry procedures. Upon expiration of TL6, the station shall transmit a plea if a viable peer
station exists.
1.5.5.3.2 Conditions for application of network entry procedures
1.5.5.3.2.1 When entering the network, a VSS user shall apply at least one of the network entry procedures
defined in 1.5.5.3.3, 1.5.5.3.4 and 1.5.5.3.5, under any of the conditions identified in Table II-1-113, on the indicated
channels.
Table II-1-113. Conditions for network entry
Condition Channel(s)
Power ON Global Signalling Channels (GSCs)
m2 M2_limit (see 1.2.2.2) Any channel on which the station
intends to transmit synchronization
Note.— The m2 test addresses retuning as well as short periods of receiver non- bursts in autonomous mode.
performance for reasons such as receiver deactivation or desensitization in a single-
antenna configuration during transmission on another channel.
CG1 CG1_limit Any channel on which the station
intends to transmit synchronization
bursts in autonomous mode.
1.5.5.3.2.2 The events affecting the value of the CG1 filter shall be as defined in Table II-1-112.
1.5.5.3.2.3 If CG1 CG1_limit, CG1 shall be reset to zero (CG1 = 0).
1.5.5.3.2.4 Following the successful application of the network entry procedures of this section on a given
channel, yielding (60/nr) reservations, where nr = nominal update rate, a station shall not reapply the procedures of this
section on that channel for a period of M1 slots.
1.5.5.3.3 Network entry using plea/response procedures
1.5.5.3.3.1 Plea transmission procedures
1.5.5.3.3.1.1 A station desiring to transmit synchronization bursts on a VDL Mode 4 channel, which has been
tuned to the channel for at least TL6 slots but which is prevented from transmission by lack of a valid reservation table,
shall identify a set of peer stations, S, with the highest reported altitudes. The size of S, known as S_count, shall be
defined by:
S_count = min[(number of viable peer stations identified), CG1_plea].
A peer station shall be considered viable:
a) if it is a mobile station which is known to have transmitted a synchronization burst on the channel on the
normal slot boundary with the autonomous/directed flag (a/d bit) set = 0; or
b) if it is a ground station which is known to have transmitted a synchronization burst on the channel.
If S_count is equal to zero (S_count = 0), the TL6 timer shall be reset. If S_count is greater than zero (S_count > 0), the
station shall transmit a plea to a peer station selected randomly. The plea shall be transmitted by using the response
reservation encoding in 1.3.18.1 (with the destination address (d) bits set to the address of the selected peer station),
with transmission starting on the delayed burst slot boundary of an unoccupied slot. The station shall continue to
transmit plea requests, using the Q5 parameters specified in Table II-1-114, until one of the following conditions is
satisfied:
a) it receives a plea response directed reservation request;

b) it receives an autotune directed reservation request; and
c) it creates the necessary number of synchronization burst streams for the channel.
1.5.5.3.3.1.2 On each transmission of a plea request, the set of peer stations S shall be rebuilt and the destination
shall be selected randomly from the set.
1.5.5.3.3.1.3 A network entry burst (n) (defined in Table II-1-6) shall have length [n ≤ 11] octets excluding burst
flags and bit stuffing and shall have a priority (pr) of 14. The information (in) field, if present, shall be set to zero
(in = 0) on TRANSMIT and shall be ignored on RECEIVE.
Note 1.— A station may consider its reservation table for a channel invalid, for the purpose of selecting slots for
synchronization bursts, if it has been tuned to a channel for less than M1 slots or if the conditions for rapid network
entry (as defined in Table II-1-112) are satisfied.
Note 2.— If the station has less than nominal update rate (nr) reservations for synchronization bursts over the next
M1 slots at the time that the last directed reservation is executed, it may repeat the plea transmission procedure in
order to generate additional reservations. The TL6 timer will not be running and is not required in this scenario.
Note 3.— In the event that a station issues multiple pleas and receives multiple responses, the final plea/response
interaction could result in a total number of synchronization burst streams per M1 slots which exceeds the nominal
update rate (nr). In this case, the station would be required to cancel some of the reservations and shift individual
nominal slots (or sets of nominal slots) in order to form a periodic sequence of synchronization bursts in time in
accordance with 1.3.10.5.1.
Table II-1-114. Plea burst parameters

Q1 Priority 2
Q5num VSS re-transmission parameters — number of attempts 1
Q5wait VSS re-transmission parameters — maximum time to wait for a reply 3 seconds
1.5.5.3.3.2 Plea response transmission procedures
Upon receiving a network entry burst (n) with a response reservation addressed to itself (i.e. a plea), a station shall take
the following actions:
1) If the station has observed the given frequency (f) for at least the previous 60 seconds and has not initiated a
network entry or re-entry procedure within the previous 60 seconds, it shall transmit a plea response burst as
defined in 1.3.16.1.2 containing:
• min(12, number of reservations required to allow 1 minute of transmissions at the default synchronization
burst rate for this channel) reservations.
• If the transmission rate is not known, it shall transmit once per 10-second reservations. These reservations
shall be identified as follows:
a) unexpired reservations from any prior plea response addressed to the requesting station;
b) any periodic reservations for the requesting station, not otherwise contained in a prior plea response and
which
i) do not conflict with other known reservations, and
ii) can be appended to a possible list of reservations in accordance with item a) (considering the
encoding constraints of the plea response); and
c) additional reservations as required, using the selection parameters of Table II-1-115.
Otherwise, the station shall ignore the burst.
2) If the station cannot transmit the plea response within TL5 seconds of receiving the plea, the plea response
shall be purged and not transmitted.
Table II-1-115. Plea response parameters

Q1 Priority 14
The station should attempt to transmit the plea response as soon as possible following the plea (while still selecting the
transmit slot randomly). The first reservation contained in the plea response should occur as soon as possible in time
following the plea response, but not sooner than V52 (minimum response delay) slots. This supports rapid network
entry while still providing sufficient time for the station entering the network to plan for and form its first
synchronization burst. The station should attempt to reserve slots which are currently unreserved and which are related
to available slots for which the plea recipient can transmit BND reservations.
Note.— The constraints on transmission time prevent possible race conditions and conflicting reservation sets
associated with multiple exchanges of pleas and plea responses. The requirement to include unexpired reservations, if
they are known, minimizes the likelihood of wasted channel resources in the case where a station fails to hear its
requested plea response, but where other station(s) in the airspace heard it and allocated the appropriate slots.
1.5.5.3.3.4 Plea response reception procedures
A station receiving a plea response shall transmit in the reserved slots.
Note.— If the station has not yet declared/transmitted an existing set of periodic broadcast reservations for all
required synchronization bursts on a given frequency, it may use the reservation fields in the slots reserved by the plea
response to set up these periodic streams by using periodic broadcast reservations (if it has been listening to the
channel for at least 60 seconds) or BND reservations (if it has been listening to the channel long enough to use the
BND reservation, but not long enough for a periodic reservation). A station may also transmit a null reservation (see
1.3.9) or a periodic broadcast cancellation (see 1.3.10.5.9) in the slots reserved by the plea response. See 1.3.10.5.1 for
requirements regarding transmissions after the first M1 slots.
1.5.5.3.4 Network entry via BND
1.5.5.3.4.1 For a station intending to initiate synchronization burst transmissions on a channel, but which has
insufficient reservations for its intended number of synchronization burst streams and which cannot make periodic
broadcast reservations, the station shall transmit a series of delayed network entry bursts (n) with BND reservations.
The number per minute of delayed network entry bursts (n) with BND reservations shall be equal to or less than the
intended number of synchronization burst streams per minute. The station shall stop transmitting delayed network entry
bursts (n) with a BND reservation if it has set up the required number of streams or if it receives a plea response or a
directed reservation request. If it receives a plea response or directed reservation request, and thus does not require the
reservations created by previous BND transmissions, it shall include a no reservation field in the synchronization bursts
that are transmitted in the unnecessary slots. At most, one delayed network entry burst (n) using a BND broadcast
reservation shall be made per intended stream.
1.5.5.3.4.2 For a station which has reservations for synchronization burst transmissions and which intends to
continue operations on the channel, but which is unable to make periodic reservations, the station shall use BND
reservations in lieu of periodic broadcast reservations.
1.5.5.3.4.3 A network entry burst (n) (defined in Table II-1-6) shall have length [n ≤ 11] octets excluding burst
flags and bit stuffing and shall have a priority (pr) of 14. The information (in) field, if present, shall be set to zero
(in = 0) on TRANSMIT and shall be ignored on RECEIVE.
Note.— A station may be temporarily unable to make periodic broadcast reservations if its existing reservations
are due to a recently received plea response or if it determines that it has become “ exposed” (i.e. CG1 exceeded
CG1_limit within the previous 60 seconds).
1.5.5.3.5 Network entry by full slot random transmission or plea-to-self
In the event that a station has listened to a channel for a full minute prior to net entry, a station shall use one of two
procedures to begin transmitting synchronization bursts:
a) use default random transmission protocols with combined periodic/incremental broadcast reservation types to
place each new periodic broadcast reservation and to simultaneously reserve the next selected slot in the same
superframe for the transmission containing the next periodic broadcast reservation, or
b) use default random transmission protocols to transmit a plea response addressed to the station itself, followed
by synchronization bursts with periodic broadcast reservations in the reserved slots. (Note that these slots may
be affected by other reservations that are detected after transmission of the plea response.)
Note.— These default procedures may also be used when a station reverts to autonomous operations after a period
of directed operations on the GSC(s). Consequently, the station will have a valid reservation table at the time of its
reversion to autonomous mode.
1.5.6 Types and procedures of CTRL DLPDU
The mobile and ground LMEs shall use the CTRL DLPDU types listed in Table II-1-116a as well as the procedures
described in 1.5.7 to provide a reliable connection between the mobile and the ground-based systems. If an LME
receives any valid CTRL_HO DLPDU from a system with which it does not have a link, it shall respond with a
CTRL_LCR with the destination (d) bit set to one (d = 1) in the Protocol Violation Cause Code.
1.5.7 CTRL transmission procedures
1.5.7.1 Frequency management procedures
The mobile LME shall use the procedures outlined in 1.5.7.1.1 to 1.5.7.1.2 to acquire a frequency on which reliable
VDL services are available.
1.5.7.1.1 Frequency search
The mobile LME shall initiate the frequency search procedure on system initialization or after link disconnection, if
there are no ground stations that provide the requested VDL service within the operational coverage (range) of the
mobile LME. The mobile LME shall attempt to identify a frequency on which the required VDL service is available by
tuning the radio to the GSCs and/or to other frequencies on which it knows a priori that VDL service is available. On
the basis of information contained in the GSIF, the mobile LME shall select an appropriate channel to receive the
requested VDL service.
1.5.7.1.2 Frequency recovery
The mobile LME shall initiate the frequency recovery procedure if it can no longer establish a link on the current
frequency or if the VSS indicates that the current frequency is congested. It shall tune the radio to an alternate
frequency, using either the data in the Frequency Support List or the DoS message previously received on the current
link.
1.5.7.2 Link connectivity procedures
The mobile and ground LMEs shall use the following procedures to maintain connectivity across the VHF link:
a) ground station identification;
b) initial link establishment;
c) mobile-initiated handoff;
d) mobile-requested ground-based initiated handoff;
e) ground-based initiated handoff;
f) ground-based requested mobile-initiated handoff;
g) ground-based requested broadcast handoff; and

h) autotune.
1.5.7.3 Ground station identification
A ground station providing a VDL Mode 4 service shall send a GSIF at least once every minute on each of the channels
on which it offers the service, as well as on the GSCs by broadcasting a CTRL_CMD (re = 0) with parameters as per
Table II-1-116c. The operator of the ground station shall ensure that, in addition to transmitting GSIFs on the service
frequency, GSIFs are transmitted on the Global Signalling Channels (GSCs). Mobile LMEs receiving a GSIF shall
process the content of the GSIF to identify the functionality of the ground station as well as the correct operational
parameters to be used when communicating with the ground station. Mobile LMEs which have a connection with the
transmitting ground station shall only process information parameters as per Tables II-1-116a, II-1-116b and II-1-116c.
1.5.7.4 Link establishment (LE)
The mobile LME shall initiate the link establishment procedure with a ground station in order to establish an initial link
with the ground-based system. Whenever the link is disconnected (for example, on receipt of DM/DISC or DM/FRMR),
a mobile shall initiate link establishment according to the local link management policy.
1.5.7.4.1 Mobile LME initiation
1.5.7.4.1.1 The mobile LME shall choose a ground station with which it wishes to establish a link based on the
capability of the mobile LME to support a link. In this way, the mobile LME can maximize the likely duration of the
connection to the ground station.
Note.— To maximize the likely connection time, the mobile LME can take account of mobile position, intent,
ground station position, the signal quality of all received uplink bursts, and information in any received GSIFs.
1.5.7.4.1.2 The mobile LME shall then attempt to establish a link with the chosen ground station by sending a
CTRL_CMD_LE (re = 1) DLPDU. This DLPDU shall include the mandatory parameters of Table II-1-116b and also
any optional parameter in case the mobile LME does not wish to use the default value. If the mobile LME has received
a GSIF from the ground station to which it is transmitting the CTRL_CMD_LE (re = 1), then it shall use the
parameters as declared. Otherwise, it shall use the default parameters.
1.5.7.4.2 General ground response
— If the ground LME receives the CTRL_CMD_LE, it shall confirm link establishment by sending a
CTRL_RSP_LE DLPDU containing the parameters outlined in Table II-1-116a.
— The ground LME shall include in the CTRL_RSP_LE any optional parameters for which it is not using the
default values.
— If the CTRL_RSP_LE includes the autotune parameter, then the Replacement Ground Station List parameter
shall be included to indicate the ground stations on the new frequency with which the mobile LME can
establish a new link by using the operating parameters specified in the CTRL_RSP_LE.
— If the CTRL_RSP_LE does not include the autotune parameter, the ground LME shall include the
Replacement Ground Station List parameter if it wishes to indicate the ground stations which can be reached
on the current frequency by using the same operating parameters as the transmitting station.
— If an LME receiving the CTRL_CMD_LE cannot establish the link with the sending LME, then it shall
transmit a CTRL_RSP_LCR instead of a CTRL_RSP_LE.
— If the parameters in the CTRL_RSP_LE from the ground LME are not acceptable to the mobile LME, then the
mobile LME shall transmit a DM/DISC to the ground.
— If the autotune parameter is included in the CTRL_RSP_LE and the mobile LME is unable to perform the
autotune, then the mobile LME shall respond with an CTRL_CMD_LCR (re = 0); the link established on the
current frequency shall not be affected.
1.5.7.5 Mobile-initiated handoff (HO)
If a mobile LME implements a mobile-initiated handoff, then it shall set the “ i” bit in the Protocol Options parameter to
one (i = 1); otherwise, it shall set the “ i” bit to zero (i = 0). (See Table II-1-78)
1.5.7.5.1 Mobile handoff (HO)
Once the mobile LME has established a link to a ground station, it shall monitor the Very High Frequency (VHF)
signal quality on the link and the transmissions of the other ground stations. The mobile LME shall establish a link to a
new ground station if any of the following events occur:
a) According to the local link management policy, the VHF signal quality on the current link is determined to be
insufficient for maintaining reliable communications and the signal quality of another ground station is
significantly better.
b) TL2 (link initialization time) seconds have elapsed since the LME initiated the request to send any burst to the
current ground station.
c) The peer station has become unreachable as defined in 1.5.4.1.
d) Timer TM2 (channel busy timer) expires. In this case, the mobile LME shall autonomously tune to an alternate
frequency (provided in a frequency support list) before initiating the handoff.
e) The mobile LME is at a position which, according to the local link management policy, requires that the
station establish a link with a new ground station.
1.5.7.5.2 Site selection preference
From among those ground stations with acceptable link quality, the mobile LME shall prefer to hand off to a ground
station which indicates (in the GSIF) accessibility to the air-ground router(s) with the mobile Data Terminal Equipment
(DTE) has subnetwork connections.
If a mobile LME has commenced approach to its destination airport and its current link is with a ground station that
does not offer data link service at that airport, it should hand off to a ground station which indicates in its Airport
Coverage Indication parameter that it offers data link service at that airport.
1.5.7.5.4 Interaction of LMEs
When a mobile VME hands off from a ground station in one ground-based system (and thus associated with one LME)
to another ground station in another ground-based system (and thus associated with a different LME in the mobile), the
new LME shall use the link establishment procedures and the old LME shall send a DM/DISC when directed by the
VME.
Note.— Optimally the old link should not be disconnected until after the new link is capable of carrying
application data. This subject is however outside the scope of this technical manual.
— If the ground LME receives the CTRL_CMD_HO, it shall confirm link handoff (HO) by sending a
CTRL_RSP_HO DLPDU containing the parameters outlined in Tables II-1-116b and II-1-116c.
— The ground LME shall include in the CTRL_RSP_HO the optional parameters for which it is not using the
default values.
— If the CTRL_RSP_HO includes the autotune parameter, then the Replacement Ground Station List parameter
shall be included to indicate the ground stations with which the mobile LME can establish a new link on the
new frequency by using the operating parameters specified in the CTRL_RSP_HO.
— If the CTRL_RSP_HO does not include the autotune parameter, the ground LME shall include the
Replacement Ground Station List parameter if it wishes to indicate the ground stations which can be reached
on the current frequency by using the same operating parameters as the transmitting station.
1.5.7.5.6 Disconnecting old link
— If the new and old ground stations are associated with different systems, then the procedures of 1.5.7.5.4 shall
be followed.
— Otherwise, the mobile LME shall set timer TL1 (maximum link overlap timer) when it receives the
CTRL_RSP_HO.
— The ground LME shall set timer TL1 after it transmits the CTRL_RSP_HO.
— Both stations shall continue to operate on the old link until their respective timer TL1 expires, after which each
will consider the link disconnected without sending or receiving a DM/DISC.
— If the ground LME cannot satisfy the CTRL_CMD_HO, then it shall transmit a CTRL_RSP_LCR instead of a
CTRL_RSP_HO; the current link shall not be affected.
— If more than TL2 (link initialization time) seconds have elapsed since the LME initiated the request to send the
CTRL_CMD_HO, the aircraft LME shall attempt to hand off to another ground station; the current link shall
not be affected.
— If the mobile LME cannot perform the autotune, it shall transmit a CTRL_CMD_LCR (re = 0); the current
link shall not be affected.
— If the parameters in the CTRL_RSP_HO are not acceptable to the mobile LME, then the mobile LME shall
transmit a DM/DISC to the ground on the new link.
1.5.7.6 Mobile-requested ground-initiated handoff (HO)
A mobile LME shall not perform a mobile-requested ground-initiated handoff when its peer LME does not support
handoff initiation. A mobile LME shall only perform this handoff if the current and proposed ground stations are both
managed by its peer LME.
1.5.7.6.1 Mobile action
For a mobile LME to request the ground LME to initiate a handoff (HO), it shall send an CTRL_CMD_HO (re = 0)
addressed to its current or proposed ground station with the parameters outlined in Table II-1-116c. During this
procedure, the current link shall not be affected until the mobile LME has received a CTRL_CMD_HO (re = 1).
— If the ground LME receives the CTRL_CMD_HO, it shall commence a ground-initiated handoff from a
proposed ground station.
— The ground LME shall only transmit the CTRL_CMD_HO (re = 1) once for every CTRL_CMD_HO (re = 0)
request that it receives.
If the ground system cannot initiate the handoff, it shall send a CTRL_CMD_LCR (persistence p = 0); the current link
shall not be affected.
If more than TL2 (link initialization time) seconds have elapsed since the mobile LME initiated the request to send the
CTRL_CMD_HO, the mobile LME should attempt to request to hand off to another station before disconnecting all
links to the ground and restarting link establishment.
1.5.7.7 Ground-based initiated handoff (HO)
If a ground LME implements ground-based initiated handoff, then it shall set the “ i” bit in the Protocol Options
parameter to one (i = 1); otherwise, it shall set the “ i” bit to zero (i = 0). (See Table II-1-78.)
1.5.7.7.1 Ground action
— To command a mobile LME that already has an existing link in order to establish a new link to a proposed
ground station on the same frequency, the ground LME shall send via that ground station a CTRL_CMD_HO
(re = 1) to the mobile with parameters outlined in Table II-1-116b.
— If the ground LME will accept a handoff (HO) to other ground stations, the CTRL_CMD_HO shall include the
Replacement Ground Station List parameter specifying the link layer address of those other ground stations.
— Any operating parameters in the CTRL_CMD_HO (either modification or information) shall be valid for the
transmitting station and for all ground stations listed in the Replacement Ground Station List parameter,
except the Airport Coverage Indication parameter and Nearest Airport parameter which are only valid for the
transmitting ground station.
1.5.7.7.2 General mobile response
The mobile LME shall respond by sending a CTRL_RSP_HO with parameters outlined in Tables II-1-116b and
II-1-116c either to the proposed ground station or to its preferred ground station if the CTRL_CMD_HO includes the
Replacement Ground Station List parameter.
1.5.7.7.3 Disconnecting old link
— The mobile LME shall set timer TL1 (maximum link overlap time) after it transmits the CTRL_RSP_HO.
— The ground LME shall set timer TL1 when it receives the CTRL_RSP_HO.
— Although new traffic will be sent over the new link, the old link shall not be disconnected immediately so that
any old traffic can still be delivered.
— If the mobile LME cannot accept the handoff (HO) request, it shall respond with a CTRL_RSP_LCR; the
current link shall not be affected.
— If the parameters in the CTRL_RSP_HO are not acceptable to the ground LME, then the ground LME shall
transmit a DM/DISC to the mobile LME on the new link.
If TL2 (link initialization time) seconds have elapsed since the ground LME initiated the request to send the
CTRL_CMD_HO, the ground LME should attempt to hand off via another station before disconnecting all links to the
mobile LME.
1.5.7.8 Ground-based requested mobile-initiated handoff (HO)
A ground LME shall not perform ground-based requested mobile-initiated handoff (HO) with mobile LMEs that do not
support handoff initiation.
— For the ground LME to request a mobile LME to initiate a handoff (HO), it shall send a CTRL_CMD_HO
(re = 0) on the current link with parameters outlined in Table II-1-116c.
— The parameters in the CTRL (both modification and information) shall be valid for all ground stations listed in
the Replacement Ground Station List.
— The CTRL_CMD_HO shall only include operational parameters if it also includes the Replacement Ground
Station List parameter. If the autotune parameter is included, then the Replacement Ground Station List
parameter shall apply to the new frequency.
If the mobile LME receives the CTRL_CMD_HO, it shall commence an aircraft-initiated handoff to a ground station,
preferably one listed in the Replacement Ground Station List parameter.
— If the mobile LME cannot initiate the handoff (HO), it shall send a CTRL_CMD_LCR (re = 0); the current
link shall not be affected.
— If the autotune parameter is included in the CTRL_CMD_HO (re = 0), the mobile LME shall re-transmit on
the new frequency the CTRL_CMD_HO (re = 1) by using the normal re-transmission procedures. Otherwise,
the mobile LME shall only transmit the CTRL_CMD_HO (re = 1) once for every received CTRL_CMD_HO
(re = 0).
If TL2 (link initialization time) seconds have elapsed since the ground LME initiated the request to send the
CTRL_CMD_HO, the ground LME should attempt to request a handoff via another station before disconnecting all
links to the mobile LME.
1.5.7.9 Ground-based requested broadcast handoff (HO)
If the ground LME supports broadcast link handoffs, then it shall set the burst length (bl) bit in the protocol options
parameter to one (bl = 1). Otherwise, the ground LME shall set the “ bl” bit to zero (bl = 0).
If the ground LME supports broadcast link handoffs, for each mobile LME that indicates it supports broadcast link
handoff, the ground LME shall confirm the link handoff by including the Broadcast Connection parameter in
Table II-1-116c.
1.5.7.9.2 Mobile response
— The LME in each mobile shall process received broadcast CTRL_CMD_HO (re = 0) and determine if the
ground LME had performed a broadcast link recovery. The mobile LME shall do this by verifying that the
Ground Station Address Filter parameter contains the DLS address of the ground station to which it is
connected and that a Broadcast Connection parameter exists containing its station address.
— Mobile LMEs supporting broadcast link recovery shall consider that a link handoff has occurred with the new
link which has the same parameters as the old link (as modified by the parameters in the broadcast CTRL).
The old link shall be disconnected immediately.
— If the mobile LME does not support broadcast link recovery and the ground LME had performed a broadcast
link recovery, then the mobile LME shall either perform an air-initiated link handoff (if the mobile LME
supports the same) or request a link handoff.
— If the mobile LME finds the new ground station unacceptable, it shall either perform an air-initiated handoff
(if the mobile LME supports the same) or request a link handoff.
— If the Ground Station Address Filter parameter does not equal the DLS address of a link that the mobile LME
has or if no mobile identifier subfield in a Broadcast Connection parameter equals its mobile address, the
mobile LME shall not process the ground-based requested broadcast handoff.
1.5.7.10 Ground-based commanded autotune
Note.— This section summarizes the autotune details found in 1.5.7.7.
To command a mobile LME to hand off to a ground station on a different frequency, the ground LME shall include the
Autotune and Replacement Ground Station List parameters in a CTRL that it sends during a link establishment (LE) or
handoff (HO) procedure.
On receiving a CTRL commanding an autotune, the mobile LME shall retune the mobile radio to the new frequency
and commence a mobile-initiated handoff to the chosen ground station.
If the mobile LME cannot perform the autotune, it shall transmit a CTRL_CMD_LCR (re = 0); the current link shall
not be affected.
Table II-1-116a. Control (CTRL) parameters (1)
GSIF Air initiated link establishment

Source address Ground station Mobile New ground station
Destination
address (d) All aircraft Proposed ground station Mobile
CTRL parameters PI hex GSIF CTRL_CMD_LE CTRL_RSP_LE
Connection management 01h N/A M M
CTRL sequencing 02h N/A M M
Protocol options 03h N/A O O
LCR cause 04h N/A N/A N/A
DLS 40h O N/A O
VSS sub-layer 41h O N/A O
QoS 42h O N/A O
m2 filter 43h O N/A O
CG1 filter 44h O N/A O
Autotune 45h O N/A O
Maximum number of missed 46h N/A N/A O
reservations (L1)
Replying ground station 47h O N/A O
Random access 48h O N/A O
Re-transmission 49h O N/A O
Timer TL1 4Ah O N/A O
Ground station address filter 4Bh N/A N/A N/A
Broadcast connection 4Ch N/A N/A N/A
Modulation support 80h N/A O N/A
Alternate ground stations 81h N/A O N/A
Destination airport 82h N/A O N/A
Airport coverage C0h O N/A O
2
Nearest airport C1h M N/A O3
2
ATN router NETs C2h M N/A O3
Ground-based system mask C3h M N/A M
Frequency support C4h O N/A O
DoS C5h O N/A O
Channel management C6h O N/A O
Note 1.— PI refers to parameter identifier; M refers to mandatory; O refers to optional; N/A refers to not applicable, and h
refers to hexadecimal.
Note 2.— In a GSIF DLPDU, it is mandatory to include either the Airport Coverage Indication parameter or the Nearest
Airport Identifier parameter but not both.
Note 3.— Where the Airport Coverage Indication parameter and the Nearest Airport Identifier parameter are marked as
optional, either or neither of the parameters may be included in the DLPDU but not both at the same time.
Table II-1-116b. Control (CTRL) parameters (2)
Ground initiated handoff Air initiated handoff
Source Proposed ground New ground

address station Mobile Mobile station
Destination New ground Proposed ground

address (d) Mobile station station Mobile
CTRL parameters PI hex CTRL_CMD_HO CTRL_RSP_HO CTRL_CMD_HO CTRL_RSP_HO
(re = 1) (re = 1) (re = 1) (re = 1)
Connection 01h M M M M
management
CTRL sequencing 02h M M M M
Protocol options 03h O O O O
LCR cause 04h N/A N/A N/A N/A
DLS 40h O N/A N/A O
VSS sub-layer 41h O N/A N/A O
QoS 42h O N/A N/A O
m2 filter 43h O N/A N/A O
CG1 filter 44h O N/A N/A O
Autotune 45h O N/A N/A O
Maximum number 46h O N/A N/A O
of missed
reservations (L1)
Replying ground 47h O N/A N/A O
station
Random access 48h O N/A N/A O
Re-transmission 49h O N/A N/A O
Timer TL1 4Ah O N/A N/A O
Ground station 4Bh N/A N/A N/A N/A
address filter
Broadcast 4Ch N/A N/A N/A N/A
connection
Modulation support 80h N/A N/A N/A N/A
Alternate ground 81h N/A N/A O N/A
stations
Destination airport 82h N/A O O N/A
2
Airport coverage C0h O N/A N/A O2
Nearest airport C1h O2 N/A N/A O2
ATN router NETs C2h M N/A N/A O
Ground-based C3h M N/A N/A O
system mask
Frequency support C4h O N/A N/A O
DoS C5h O N/A N/A O
Ground initiated handoff Air initiated handoff
Source Proposed ground New ground

address station Mobile Mobile station
Destination New ground Proposed ground

address (d) Mobile station station Mobile
Channel C6h O N/A N/A O
management
Note 1.— PI refers to parameter identifier; M refers to mandatory; O refers to optional; N/A refers to not applicable; h refers to
hexadecimal; and re refers to response expected.
optional, either or neither of the parameters may be included in the burst but not both at the same time.
Table II-1-116c. Control (CTRL) parameters (3)
Air initiated Ground requested Ground requested Link connection

handoff handoff broadcast rejection
Source Mobile Current ground
address station New ground station Any station
Destination Current or proposed
address (d) ground station Mobile All mobiles Any station
CTRL parameters PI hex CTRL_CMD_HO CTRL_CMD_HO CTRL_CMD_HO CTRL_RSP_LCR
(re = 0) (re = 0) (re = 0) CTRL_CMD_LCR
Connection 01h M M M M
management
CTRL sequencing 02h M M M M
Protocol options 03h O O O O
LCR cause 04h N/A N/A N/A M
DLS 40h N/A O O N/A
VSS sub-layer 41h N/A O O N/A
QoS 42h N/A O O N/A
m2 filter 43h N/A O O N/A
CG1 filter 44h N/A O O N/A
Autotune 45h N/A O O N/A
Maximum number 46h N/A O O N/A
of missed
reservations (L1)
Replying ground 47h N/A O O N/A
station
Random access 48h N/A O O N/A
Re-transmission 49h N/A O O N/A
Timer TL1 4Ah N/A O O N/A
Air initiated Ground requested Ground requested Link connection

handoff handoff broadcast rejection
Source Mobile Current ground
address station New ground station Any station
Destination Current or proposed
address (d) ground station Mobile All mobiles Any station
Ground station 4Bh N/A N/A M N/A
address filter
Broadcast 4Ch N/A M M N/A
connection
Modulation support 80h N/A N/A O N/A
Alternate ground 81h O N/A N/A N/A
stations
Destination airport 82h O N/A N/A N/A
Airport coverage C0h N/A N/A O2 N/A
Nearest airport C1h N/A N/A O2 N/A
ATN router NETs C2h N/A O M N/A
Ground-based C3h N/A O O N/A
system mask
Frequency support C4h N/A O O N/A
DoS C5h N/A O O N/A
Channel C6h N/A O O N/A
management
Note 1.— PI refers to parameter identifier; M refers to mandatory; O refers to optional; N/A refers to not applicable; h refers to
hexadecimal; and re refers to response expected.
optional, either or neither of the parameters may be included in the DLPDU but not both at the same time.
___________________
Chapter 2
VDL MODE 4 MOBILE SUBNETWORK DEPENDENT

CONVERGENCE FUNCTION (SNDCF)
The VDL Mode 4 shall support the Frame Mode SNDCF as defined in 5.7.8 of the Manual of Technical Provisions for
the Aeronautical Telecommunications Network (ATN) (Doc 9705, Third Edition — available only in CD-ROM). To
support the interface, VDL Mode 4 shall:
a) generate a JOIN event upon reception of a CTRL_RSP_LE or a CTRL_RSP_HO.
b) generate a LEAVE event whenever the link is terminated or abandoned.
Note 1.— A link can be terminated for a variety of reasons, including a station becoming unreachable as defined in
1.5.5.1, protocol exchanges and link time outs (e.g. expiration of the TL1 (maximum link overlap time) or the TL2 (link
initialization time) timer). A link is abandoned when the TM2 (channel busy timer) timer indicates that the frequency is
congested, the Link Management Entity (LME) enters frequency recovery mode trying to find a less congested
frequency, and the VDL 4 station does not have a spare receiver to monitor both the old and the new channel.
c) provide a data transfer service as defined in 1.4.
Note 2.— The timeliness of the generation of LEAVE events depends on the value of the L1 (maximum number of
miss reservation) counter and the number of reservations known to have been made by a station within a time interval.
___________________
II-2-1
! "
!
! "" !" ! #
"" ! " $ %%&
! " " %%' (
#$ %&& '() & *'&#($*)( $+, +(-*
! " # " $# " %

! " %%' ((
) ' *+' (
" %%' ((
" %%' '*
" %%' +(
, , ! " %%' +(
") ) " %%' '-
" ) " %%' ((
") ) " %%' ((
. % " %%' +/
. " %%' ((
. " %%' ((
" " %%' '0
" %%' +1#%%' +2
! 3 43 .5 ! " " %%' ((
! " %%' +/#%%' +*
" %%' +/#%%' +*
" %%' +/#%%' +*
6 ! " %%' +/#%%' +*
&
! " # " $# " %

6 ! , " %%' +
7 " %%' ((
7 8 " %%' ((
3 . " %%' ((
% ! ' *+/ (
% " %%' +1#%%' +2
9 " %%' '0
" " %%' ((#%%' '0
/ /" " %%' ((
1 1" " %%' ((
" %%' '-
$ " %%' +(
" " %%' ((#%%' '0
/ /" " %%' ((
1 1" " %%' ((
% " %%' '*
3 . " %%' ((
3 . " %%' ((
: . : !. ! " %%' ((
: .$ : ! !& '/ +
: . : ! !& ! '/ +
:; : " ' *+(
:%. : ! ! " %%' 1
< !. $ 4 .$5 " " %%' ((
: ' *+'
: " %%' +
: : " ' *+(
" %%' +/#%%' +*
$ % " %%' ((
$ ' *+' '
, " %%' +(
$= $ ' *+'
$ ' *+' '
" %%' '0
! " %%' 1
") " ) " %%' +(
" %%' '*
% " " %%' +(
" %%' +
! " '
( " ' ) # " ")
! " # " $# " %

" %%' +/#%%' +*
3 . " %%' ((
% % ! " %%' '#%%' #%%' 1
" %%' +(
" %%' ((
! " %%' +(
" %%' +/#%%' +*
" %%' ((
! ! " %%' +/#%%' +*
> " %%' ++"#' / +
> " %%' ++"#' / +
> > ! " %%' ++"#' /
" %%' +/#%%' +*
.$ " %%' ++"#' / (
.$ " %%' ++"#' / (
" %%' ((
" %%' ((
, , " %%' +
3 " %%' '0
3. ! ' *+(
, " %%' '0#%%' '(
, ! " %%' +(
! 3 .! " %%' ((
''( " "! "

" %%' +
#$ +-)( & +(- )+$.*
"# * * &
& "# #
0 ,
( , ? !
+ , 6
' ,
, 3 .
- , >
"# * * &
& "# #
/ * , "
1 , 9 .$) >
2 , .$
, 0 , "
, ( , 4 # !# 5
, + 2 , "
, , 0 , ?
, , ( 2 , "
, , , ;, 4 " %
, 5
, , 6 , "
, 6 , "
; , "
6 , :
''+ 6 # " " %%' ' %%' (0
#$ -)( & +(- )+$. / 0 *+,
+ #% "
" , 1 * / - ' + (
% (( , , , , 0 0 0 0
% ! 4 5 (+ + ( // /- / /' /+ /(
/" 4 -5
/" 4 -5 (' ") // /- / /' /+ /(
" ) 4%"."5
" ) 4% 5 ( 2 " * " / " - " " ' " + " (
4 "5 (- 1 * / - ' + (
4 5 (/ 1 * / - ' + (
84 5 (* (( (0 2 - ' + (
(1 (( (0 2 1 * /
$ '
/ 0*1 " * '0" 1 "" 2 '
#$ 1 -)( & +(- )+$. 0 2+3 .'- &+,
+ #% "
" , 1 * / - ' + (
% (( , , , , 0 0 0 (
" ) 4%"."5# (+ ") " * " / " - " " ' " + " (
" ) 4% 5
!" '
( " ' ) # " ") 3
+ #% "
" , 1 * / - ' + (
4 "5 (' 1 * / - ' + (
% ! 4 5 ( 2 + ( (+ (( (0 2
4 5 (- 1 * / - ' + (
" 4 5 (/ ' + ( ' + (

" 4 5
84 5 (* 1 * / - ' + (
(1 (+ (( (0 2
$ '
/ 0*1 " * '0" 1 "" 2 '
#$ 4 -)( & +(- )+$. 0 %$$ (*++(-
+ #% "
" , 1 * / - ' + (
% (( , , , , 0 0 ( 0
/" 4 -5 (+ (0 2 // /- / /' /+ /(
% 4 5 (' 1 * / - ' + (
" ) 4% 5 ( (( " * " / " - " " ' " + " +
/" 4 -5 (- (0 2 // /- / /' /+ /(
84 5 (/ 1 * / - ' + (
4 5 (* 1 * / - ' + (
% ! 4 5 (1 (( (0 2 + (
$ '
/ 0*1 " * 40" 1 " " % 5 % " "# '
#$ 5 -)( & +(- )+$. 0 *+,3 (%-.
+ #% "
" , 1 * / - ' + (
% (( , , , , 0 0 ( (
3 . 45 (+ - ' + (
3 . 4# 5 (' (0 2 / - ' + (
% 4 5 ( 1 * / - ' + (
" ) 4% 5 (- " * " / " - " " ' " + " (
4 5 (/ 1 * / - ' + (
" 4 5 (* ' + ( ' + (

" 4 5
3 . 4 5 (1 / - ' + (
$ '
/ 0*1 " * '0" 1 "" 2 '
-
#$ 6 -)( & +(- )+$. 1 0 +&
+ #% "
" , 1 * / - ' + (
% (( , , , , 0 ( 0 0
3 . !4 25 (+ !- ! !' !+ !(
3 .! 42"5 (' !1 !* !/ !- ! !' !+ !(
3 . 4 5#3 . ( ' + ( ' + (
4# 5
3 . 4# 5 (- - / - ' + (
4 5 (/ 1 * / - ' + (
" 4 5 (* ' + ( ' + (

" 4 5
3 . 4 5 (1 / - ' + (
$ '
/ 0*1 " * '0" 1 "" 2 '
#$ 7 -)( & +(- )+$. 7 0 8( *$( 9,( ' -3 (+- :

,( ;% $+' : ;
+ #% "
" ,
1 * / - ' + (
% (( , , , , ( 0 0 0
(+ 1 * / - ' + (
4 5
(' " (+ " (( " (0 " 2 (+ (( (0 2
" 4% 5 ( " 1 " * " / " - " " ' " + " (
4 5 (- 1 * / - ' + (
(/ / - ( (' (+ (( (0 2
4 5 (* ' + (
< (1 1 * / - ' + (
4 5
(2 " (+ " (( " (0 " 2 (+ (( (0 2
" 4% 5 +0 " 1 " * " / " - " " ' " + " (
4 5 +( 1 * / - ' + (
++ / - ( (' (+ (( (0 2
4 5 +' ' + (
< + 1 * / - ' + (
4 5
+- " (+ " (( " (0 " 2 (+ (( (0 2
" 4% 5 +/ " 1 " * " / " - " " ' " + " (
4 5 +* 1 * / - ' + (
+1 / - ( (' (+ (( (0 2
4 5 +2 ' + (
!" '
( "' ) # " ") 6
+ #% "
" ,
1 * / - ' + (
< '0 1 * / - ' + (
4 5
'( " (+ " (( " (0 " 2 (+ (( (0 2
" 4% 5 '+ " 1 " * " / " - " " ' " + " (
4 5 '' 1 * / - ' + (
' / - ( (' (+ (( (0 2
4 5 '- ' + (
4 5 '/ 1 * / - ' + (
'* (/ (- ( (' (+ (( (0 2
4 5 '1 ' + ( +( +0 (2 (1 (*
4 "5 '2 1 * / - ' + (
0 (/ (- ( (' (+ (( (0 2
: . 4 55 ( ' + ( +( +0 (2 (1 (*
: .$4 5#. % ! + ' + ( "

" !4 5#
:%." 4 %5#
. 4 5#
!
4 5
% 4 5 ' 1 * / - ' + (
/" 4 -5 ' (0 2 // /- / /' /+ /(

/" 4 -5 - 2 ") // /- / /' /+ /(
" ) 4%"."5
4 "5 / 1 * / - ' + (
!4 5 * + ( - ' + (
% 4 5
4 5 1 1 * / - ' + (
84 5 2 (( (0 2 - ' + (
-0 (( (0 2 1 * /
$ '
/ 0*1 " * '0" 1 "" 2 '
$ &'
/ %" 7 " " 2 # 7 '
$ '
/ (! "# " " "
5 ## 2') 8 9 (! "# "% % 5 # 2% %: " "5 '
#$ 7# -)( & +(- )+$. = 0 +-3$ *$(
+ #% "
" , 1 * / - ' + (
% (( , , , , ( 0 0 (
" 4% 5 (+ " 1 " * " / " - " " ' " + " (
.$ " 4 5 (' " (+ " (( " (0 " 2 + ( (0 2

;
+ #% "
" , 1 * / - ' + (
% 4 5 ( 1 * / - ' + (
4 5 (- 1 * / - ' + (
4 5 (/ (+ (( (0 2 ( (' (+ ((
(* (0 2 1 * / - '
4 5 (1 / - ' + (
$ '
/ 0*1 " * '
#$ 7, -)( & +(- )+$. 4 0 +-3$ *$( ;
+ #% "
" ,
1 * / - ' + (
% % (( , , , , 0 ( 0 (
: .$ (+ 0 0 0 ( ' + (
: . 4 55# % 4 5#:%." (' ' + ( + ( "

4 %5# " .
! 4 . 5
4 5#
!
4" 5
4 5 ! ( ' + ( - ' + (
4 5
(-
(/
(*
$ '
/ 0*1 " * '0" 1 "" 2 '
$ &'
/ < "# " " "
5 ## 2') 8
9 < "# "% % ; # 2% %: " " 5 '
( "" 2 " 5 ## 2 " 5 " " "# "% ) +
" " 9 7 9 % 2 '' "# " () .)() 9( "
# " 5 ) ( "5 9 ' " " " " 5 "# 97 " " 9%
2 " " " # '
#$ = -)( & +(- )+$. 0 +, ) .
+ #% "
" , 1 * / - ' + (
% (( , , , , ( 0 ( 0
!4 5 (+ 0 0 0 ( ' + (
45 (' - ' + ( (+ (( (0 2
4 5 ( 1 * / - ' + (
(- +0 (2 (1 (* (/ (- ( ('
!" '
( " ' ) # " ") =
+ #% "
" , 1 * / - ' + (
4 "5 (/ +( * / - ' + (
(* (- ( (' (+ (( (0 2 1
(1 +( +0 (2 (1 (* (/
$ '
/ 0*1 " * '
#$ / -)( & +(- )+$. / 0 2+3 *($% +(-
+ #% "
" , 1 * / - ' + (
% (( , , , , ( 0 ( 0
(+ ( 0 ( 0 0 0 0 0
% ! 4 5 (' + ( (+ (( (0 2
4 5 ( 1 * / - ' + (
1" 4 ;5 (- 11 1* 1/ 1- 1 1' 1+ 1(
1" 4 ;5 (/ 11 1* 1/ 1- 1 1' 1+ 1(
84 5 (* 1 * / - ' + (
4 5 (1 (+ (( (0 2 + (
$ '
/ 0*1 " * 40" 1 " " % 5 % " "# '
''' " " " %%' ((
#$ -)( & +(- )+$. -,(.+-3 > +#$ . )+$.
% > ? $
% ! 0 ' 0#(#+#'# 9
4 5 % $ "!
. 4 .
5) @ + + A+ ( + (-
: ! 0 (( 0 (( 9
!& 9 : .$
4$)(!5 $ "! . ) @ + + A+ ( + ('
: ! 0 0#
(#+#
'# 9
!& ! : . $
4$)( 5 "! . ) @ + + A+ ( + (
" 4 5 &
/" 4 -5 & (+ " 9
, 4 " %% ( /-5 ;
1" 4 ;5 & " /
" 4 5 &
/" 4 -5 & ( " 9
, 4 " %% ( /-5 " /
1" 4 ;5 &
@
% > ? $
" ) 4% 5 0 (+* " B" &
; " %% ' (+
" ) 4%"."5 ! 0B "
(B
4 "5 C'+ (00 2
D'+ (00 9 0B " (B 2
" 0
8 9
1 (
" %% ' (
4 5 0 (( +-/ ; " %% ' (' 0 ' 0/2 8
8 (( " 0 (( +-/ (+
" (
8 8 : " (+
! "
! "
D(
84 5 0E : F4'/0)+ 5 0 7 8
'-2 2(+E : 8: " "
'/0)+: 4 (( (+5
" 8
4 5 0 ' 0B 3 8 9 #( B #+ B # 'B
% 4 5 & ; " 1
3 .! 42"5 ( +-- ! B (2*0#0B :)
3 . 4# 5 ( (+
3 . !4 25 ( '( ! #00B :)
3 . 4 5 0 +'
3 . 4# 5 0 -2
3 . 4 5 0 /0 /0 9
4 5 0 +-- #0
.$ " 4 5 0 ' 0B
(B ,
+ B , D(
' B , D+
.$ 4 5 0 /' % .$
4 A @5
.$ 4 A 9& " 5
; " %% ' (*
4 5# ; G
4 "5 (5 . " <
+5 @ ! H#0 2
I HB 0 +-#0 2 B +/ '-#
B '/
'5 . " 1 GJ (#
+# '# # -# /# *# 1K
! " '
( "' ) # " ")
% > ? $
' +
5 B ( '* D + '* D ' '* D
-5 B - '*' D / '*+ D * '* D 1
!4 5 0 '( ; " %% ' (-

4 5 0 * ; " %% ' (/
. % 4 5 ! 0B . %
( B. %
'''( 6 < !. $ 4 .$5 # % 4 5

" 1
'''+ 6 .$ " 4 2 ,5#" ( +

" " @ .$ " # " ( + "
" L
$ '/ % " %2 7 % ' # 5 % " 7 %

B 3@#9 * 7 " " 7 " B 3@#'
'' " ) 4% 5 " " " %% ' (+
#$ (:3 (())* -,(.+-3 > +#$ . )+$.
+ " # " . # " " #

" # 5 %
" + 0(+- + 0(+-M " " + 0(+ -
+ 0(+ - M"
" M N+ 0*- " M N- 0-0 ( M N+ 0*- M N- 0-0
N+ 0*- " M N+ 0+- N- 0-0 " M N 2-0 + N+ 0-0 N- 000
N+ 0+- " M N( 2*- N 2-0 " M N 1-0 ' N+ 000 N 200
N( 2*- " M N( 2+- N 1-0 " M N *-0 N( 2-0 N 100
N( 2+- " M N( 1*- N *-0 " M N /-0 - N( 200 N *00
N( 1*- " M N( 1+- N /-0 " M N --0 / N( 1-0 N /00
' 2*- " M 0+- *0-0 " M *(-0 (+' 000 *(00
0+- " M 0*- *(-0 " M *+-0 (+ 0-0 *+00
0*- " M (+- *+-0 " M *'-0 (+- (00 *'00
" (+- " *'-0 (+/ O (+- O *'-0
(+*
8 9 0 8 9
''- 4 5 " " " %% ' ('

#$ ? (%-. * . -,(.+-3 > +#$ . )+$.
! # " !
" " $ !!
% &' #( " )( ( ( " &
! " ! # $ % " #% $ ""%

%" &&' '
% &' #( $ * * ! ++!" $ " !+&,! &
! # " " " !

" ! " -! . &
&& ! "
(! (
(! (
(! (
( ! (
( ! (
/ & ( !
0( & " ! 11
! # " " " !

" !" -! . &&& !"
(! (
(! (
(! (
( ! (
( ! (
( ! (
( ! (
! ! !)# $ % " "" % %" &&' '
2 !3 ( 4 0 ""
" * # "% $ !"
! !+
* , # "% $
# "% $
! !+
+) * # "
%$ ! !
") +!%" , "! %" ) ,
-- ! !+
! !!
" !* ""
" ! !
! "+ "
*! ' ! + "
"! '" ' " !* ! " !
! * ) +!
- - ! !+
! + ". ! )+ "
! + ". !+ + "
/ ! ! ! %!
- ! !+
- - - - - - ! !+
!! #$ % " ""% %" &&' '

2 1
! )* ! !
!" ! )
" !* "
" "
" " !!
- ! !+
# $ % " ""% %" &&' '
# " " " !

" ! "
0 ! + "%"
"# $ %&'(&#
"# $ )
!1 %! 234'5 ! ! ) ! 6 %!- "" !

!"!1 %! !1 &3 # " $ 7 - "" " / " !) ! #
%" &&' ' - &&' ' &&' ' $ ! ! - + +" ! # $
! # $% ! % " "" % ! %" &&' '
8! ! %" "" % " ") ! + ! ! " % "" % " ! !
# " $ ! ! " %
* "# $ )
5 "6
-
% ! &3-2 ! " !'%* !'%*
# $
2 ! # $
91 % " # 63$
" 4 %" &&' ' &&' '
/ & ( !
0( & " ! 11 ,
& !1 ! ! ! "-% !
! + ! !+ " ) + ! " ! / - !1 ""
! # $% 7 %" &&' ' ""% : ! - %
""% 7 %" &&' ' "" %
% &
' #( ! ! 64 ( &#( 4 7 (
( 4 ( ( 8 7 ! 64 ( 4
! &
, "# $ )
-.
5 "6
-
!)! ! ! # $ ! ! ! ! + " + " + " + "
/ " + " )# $
/ " # $
& !1 ! ! ) ! 6 % ! + ! %" ! !
" ")%) ! - !1 "" ! # $%
7 %" &&' ' "" % : ! - "" 6 9 !
+ ! %" ! &3 ""% %" &&' '
% &' #( ! 9 : !( " " 6 9+ " 4 ( ( 8 4 !"

! " " 7 9 . !( 6 9 &
% &
' #( $ !" ! 7)( ( ! 6 (7 ( 6 ( " " "
( ) &#( 7! ) ( 6 7( " 6 64 ( "
!" 6 ! )( ( 15 $ ) (( " "
" $ 6 ! ! " ! (9 ; &
&%
' 8" 7 15 $ ! ! !! ( "" 7)( ( 7
46 ) (( !# 6 &#( " " ) () " 7&&
" 8" " 4 9 " 8" " 9 + "7 $ ( ( (
6 &#( 4 ! ( ( ( " 4
( ( ( 4 ( ( 8 &
+0 "# $ )
-.
5 "6
-
" #$ " " / / !' !' !' !'
/" !) # 8$
! 1 ! " &3 # $
% &
' #( ! " 4 ( 6 $ &
:
+ "# $ )
1 6! < 2 - !1 %
5 " 7 " ; 0*2 & - " !
! # $ 7 " !% " ! !
!+ ! "
! % "- !
5 " 7 ") " 0*2 & - " !

! # $ ! ! !% !1 !
"; 7 ! + !+ "
!1 ! ! % "- !
" ") # 9+ ") "
" ! !$- !
# 9 $
!1 5 !); 4 %" &&' ' 2+" 91 ! "
! &3 # $ + ! %" %" &&' ' ) + ! %"
" "
/ " ! 7 !
+ " )# $
/ " ! ! 7 !
# $
!)! ! 4 %" &&' ' 0*2
! # $ "
!
# !$
! !! 5 !) 0*2 & %! "
" # $ ! !! #
! !! !
" $
/" !) ! ! & !' 7 ! /- < & !! +"
# 8$ 7 %! ! ; 7 "
! ; 7 ! !+ ; @ +" ! ! !+
7 = !
& !' 7 /- < 7
!! >8; 7 /
>8; 7 / ? >8;
7 / ? >8
& !' 7 - - - - -2 -
!22 / <
/7 !
! !
!1 % 7! ! !
" # 63$ %! ! ! !
7! ! % ! ! !-
+ "%"-! !
!
7! ! ! !-
+ "%"-! !
%! !
7 ! !+ ! !
/ & ( !
0( & " ! 11 =
++ &1 "# $ )
- . ) . . /
5 "6
-
! 1 &3 # " $ #6 9 " !'%* !'%*
+$-% ! &3-2 ! # $ # $
# $-2 !
# $-! 1 % " # 63$
!)! ! ! # $- ! ! ! ! +" +" +" +"
/ " + " )# $ # $ # $ # $ # $ # $ # $ # $ # $
/ " # $
# $ # $ # $ # $ # $ # $ # $ # $
! 1 ! " &3 # $ " " / / !' !' !' !'
# $ # $ # $ # $ # $ # $ # $ # $
"&2 (3 "# $ %&45% 67
& % 234'5 !1 ! ! ! !1 ! 234'5 " -

"" ! " ) ! 6 %! ! +! +! A"% "4 "" > "
#A4> $
2 " !% ! + ")% A4>
"# $ 4%58&"(%&#
"# $ )
2 234'5 !1 "" ! # $% # 9 $
" !1 &3 # $ " !1 ! " % %!
!1 "" % 6! # 9 +$ " " !
! ! " ! ) !1 ""
! # $% 6! # 9 +$ !1 " %! ! # +
!1 ! !+ $
!1 "" ! # $ % # 9 $ "
+" ) ! " # $ ! %! ! 6) % !
! " ! -% %! !! ! ! ! 2 %" !
234'5 !1 - % # 9 $- "" ! +" ) !
/ ! ! "<
$ + ! / " # $ ! ! ! ! " ! ! !-
!
.
%$ + ! / " +" )# $
& 6! # 9 +$- ""% ! & 6! # 9 +$- +" )

"" % ! 2 / ! !+ " ) ! " ""% !
")%) ! "%! ! ! " "" !<
$ ! + ! !1 ! !+ ! !1 ) ! ")
+ !! % # $ # 9 $ #% ! "! !
! ! ""% $ #4 " %" &&' ' $;
$ ! ) ! 6 % ! % / ! "-%
+" ) ! " & % 1 ") ! ! ) ! 6 % ! # -
"" ! "! !+ " "" ! ! ) ! 6
% ! $; !
$ ! ) ! 6 % ! % / +" ) ! " &

% 1 ") ! ! ) ! 6 % ! ! +" ) % % " ! "
% &
' #( ! " 4 ) ( * " " &
+ . 9 )
2 !1 @ > ) ! 6 ! "# ! " &3 $ "" ") !

!1 ! ! !) ! # ! ! ! "9+
$
B !1 ! ! ) ! 6 %! ! + ! %" ! -
! " ---- 2 / "" + ! ! ) + ! ! ! "
: 8. 4 # ; '
84 #;' .
B ! >8 - %" "" ") ! !

) ! 6 %! "' " >8 + ! %" ! # %" &&' ' %$ !+ " !
! ""% # >8 !+ "$ ! ! ! ""% !
! # >8 ! ! $ - %" &&' '
++ : 8. 4 84
14"6 / " " " " 8" " !

>8
!+ "
>8 !
!
B 4CD - %" "" ") ! ! ) ! 6

%! "' " 4CD + ! %" !# %" &&' ' $ !+ " ! ! ""
/ & ( !
0( & " ! 11 ;
% #4CD !+ "$ ! ! ! ""% ! ! #4CD

! ! $ - %" &&' ' %
++ # ; ' #;'
14"6 / " " " " 8" " !

4+ 4CD
!+ "
4+ 4CD !
!
% &
' #( " ( 1 > ( 1 4 1 7
4 4' % 0/ 4 4' 4 % 0 &
% &' #( " ( ! ) ( &#( ( (

( ( 6 6 4 ! ! ! 1 > #0/ ( ) ( &
2 %" ! ! ) ! 6 %! " ' " >8*4CD

+ ! %" ! %" &&' ' ! ! "! ! ! ) ! 6 %! ""
) >8 ! 4CD ! %) >8*4CD " # $ 6! ""
! ) ! 6 %! ! %)
B %" >8*4CD " 6 ! - ") ! ""% ""

! %) 234'5 !1 % ! !1 %" ! ) ! 6 %!
'" >8*4CD + ! %" !
%" "" >8*4CD " ! >8

*!4CD ! '" >8*4CD + ! %" !
2 ! ! ) ! 6 %! " '" >8*4CD

+ ! %" ! ! "! ! ! ) ! 6 %! "" >8*4CD "
! 856 %53 8 %3 4 % < & &%#
! " # / " #
3 4 ! ""% ! %) ! ")- > 9E 3 4 ! !

" " ""% %" &&' '
+ &
2 " $ " "

234'5
! & ! 4 !+ . 5! # &4'5$
4 !) + %" )
F" & ! 4 !+ . 5! #F&4'5$
+
!+ ! #$ " ! !+ ! ) # $ " 1 " / ""%

%" &&' '
+ & /
1 ! " 2$
! 6 "6 1 ! #6
234'5
&4'5
4 !) + %" )
F&4'5
! !+
!+ 8.
" ! ! ""% + %" !% %" &&' ' & ! -

%" "" ! " ! ! ! ! %" &&' '
+ 8 = .
5
G ! %" > > 9E ! '! + ! ! %'
"
3 %" > " 6! ! ! ! ! ! -"
" ! !! " ! ! #6 !
" " %! $
! %" > ! ! ! ! " H
!% ! " ! ! ! # "! ) 4298 $
"" ! " + " ! " ! ! %" "
" ! ! %" # ) ! " !
$
F! 1 )%" > ! ! 1 ! ! " " " ! !
% ! 1 ) " ! " ! ! 1 )%" "
" ! ! %" # ) ! " !
! 1 )$
8! ! %" > D 4 ! ! ! ! % "
!
4! %" > ! ! ! " ! 0 ! ! " H !
" "! - ! 1 )%" !
! %" !
" ! ! ! %" "" ! ! "

! ! % %" &&' ' - % " %" &&' '
/ & ( !
0( & " ! 11
+ > =
5 "6
-
> 9E ! !&3
> 9E" #$ ?
! #$ ?
! # $ ?
# $ ?
&3 # $-! ?
#$
!1 ) #!$- ! ! ? ) ! ! ! !
) # 4 $- ! ! # $
! ! ! # $ ? ! !
! #$ ?
+! > =
1 6! 2 %
! # $ 4 %" &&' '
! # $ 4 %" &&' '
# $ < %" % # $ " %!
< %!
%"
&3 # $ < ! " ) ! 6 %! & ! ) #4
! ! 0 $
! "
! !
<+ " !;
< " "" ! !
! # $ <! %" %
< %! "
! %"
! 1 ) #! $ < ! 1 )" # 9 ,$ %! " ! 1 )
< %! ! 1 %"
! ! ) # 4$ 4 9 +<! ! ! %!
! ! ! ! ;
4 9 < ! ! ! %!
" ! !
! ! # $
" ! # $ & ! ! % )
F ! 4 9 +- ! %"
&&' '
F! 4 9 -
% # $
! # $ # $ 0 %! %) ! %"
1 6! 2 %
! ! ! # $ 0 %! %) ! ! !
%"
% & ' #( "" ) , ""

( ! ! ! ! ) &#( "" ( 4&
" ) ( 98 ! "9 876 ) (
!! 64 " ) ( 8& "" "
!" ( 4 ! " 7 ( " ( !!
! " ( & 8" $ ! 4 ( * 6 ) "
! $ ! 64 9 +7 $ ! #0/ ( " !! ! $ 4 !
64 9 &#( ! !! "" ) ! 6 ( "" 7 && 9+
9 7 ( (( ) ! "" " " 4( !! 6 ( &&
! 4 ( * 6 ) ! #0/ &
%! " ! # " %! ! +! ! ) "$ ""%

0H4 %! ! ! ""% 0 I
% &
' 4 6 ( 6" ! " 78 4 " 7 " " &
% &
' #( ! ! ( 6 &
=&&
;&#( ! "
! 7 ( ! " 7 " ) ! 7 ( ! "
" ! ( 6! &! ( ! 7" 6 ! 7!
( 6 ! 7 "6 ! " "7( ?%21 9 @ " " " 9 @ "&
% &
' #( ( ! ( " " " " ,, 6
0#< (! ( 0#< " ! " &
% &
'#( ! %# ! &
=&&&
%" "" 6! # %! $- ! ! ! -! ! "

-
& # $ !%" 6 ! # 9 +$- " > 9E ! ! ""

") ""
% &
' !( 6 " 6 9+ #6 =7 " ((
A &
&% ! %" 6 !- %" "" ! !

! ! %" &&' ' - %" &&' ' & ! ! + !-
! !! ! "" !
/ & ( !
0( & " ! 11
% &
' 5 . !( ! ( !( 6 &! * 7(
6 &! 7 " 6 &=&&& & (
!! ! ( ! ( 6 " + , + &
+* =
5 "6
-
+ " # $
! #$
+, =
1 6! 2 %
+ " # $ ! ! ! 4 !
! %"
!
! # $ 8!
2 %" ! + " ! ! + " # $ 1 "

6! # 9 +$ %" = ! - "" ! ! !
2 %" ! " ! ! # $7
!%" "" ! ! !
2 %" ! + " > 9E ! ! + " # $

1 " 6! %" = ! "" ! ! "
+ " ! !# $ ! ! ! # $ % " ""
%! " %) ! ! % ! ! " > 9E
2 ! " > 9E ! ! ! ! !
%" ! ! # $ 1 " 6 ! # B +$ "" ! ! "
"" % %) ! + ! % ! !+ %) %" ! !+ ! " # $ !
%) ! 1 ! # $
% &
' 64 6 ! ! ( " 6 9 &
< "
&% ! %" - %" "" ! "

" ! %" &&' ' - %" &&' ' 4 ! ! " !
!+ " ! !- ! ! ! !1 # $- "" ! ! " "
2 "" ! ! > ! !> !
> % ! # " %" &&' ' $<
> <2" "
" # % ! " - + " %" ; ! - " $ ! ! ! 1 "

" ! " - " ! 1 " ! " # ) C C $
> <9 "! " ! " + ! / #$ ! " " !

1 " =! "! ! ! #C D $
J ! ! ! # ! "H ! $ " ! 1 "

+ ! / # D C $
> %<9 "! " ! + ! / ! " " ! 1 "

=! "! ! ! #C D $
J ! ! ! # ! "H ! $ " ! 1 "

" + ! / " # D C $
& ! - ! ! ! ! " " "" !
% &
' #( 7 " 46 ) ( ! !( &
2 ( ) ( &
% &
' ( " ( ( 6 ! ( " ( "&
0 % =
5 "6
-
+! / # $ ! " " + + + +
! " # 7 $ " " " " " " " "
" " " " " " " "
! " # 7 $ " " " " " " " "
" " " " " " " "
" ! " # $ "" "" "" "" "" "" "" ""
! " # $ " " " " " " " "
+! / ! " #$ ! - ! - ! - ! - ! - ! - ! - ! -
#$ - - - - - - - -
+! / # ! " #$ ! - ! - ! - ! - ! - ! - ! - ! -
$
#$ - - - - - - - -
/ & ( !
0( & " ! 11 ,
% =
1 6! 2 %
C ! / # $ <+ ! / +! / !! ! "
<+ ! / +! / &
! " # 7 $ " -" -" -" ! >89 ! 4 4 9+-! !
! " # 7 $ > ! " ! > 9E
" ! " # $ < "7K 4 ") %!

! " # $ < "7K " #% ! + "%"- ! $
< " ! ! % " ! ! " 2"
+" ! " ! "
< !"
# $ 4 %" &&' ' C ! / %" ! " "")
! ! "! !# " !
! "# $ 0 ! 9 " *
! $
! -" !
+; 1
# " !
" $ !! E ( !?
0I
0I
0I
0I
0I
0I
0I
0I
0I
0I
0I
0I
0I
@ ! " > 9E ! ")

! -%! !! " - "" %" 0 I ! & ! ! )
:
# 4$ 7 - %# 9 F%21G H# ! # ! ! $ ! " " ! ! #

! " ! %" &&' ' $$ & 4 9 - %# 9 F%213 @ H & 4 9 0H4
" " L @ M- ! ! % ! ! ""
% N +" - ! > 9E ! ! ""% ! ! !!
: ! " ! ! !
%" - ! + "" ! !+ %" !!)
%" &&' ' "( + " # "$ "" !! "( ! # "$
! +
!! "
) 4
) &+ "
, 9 !+ "" " ! %! <
!N7 7 0 IK -
" 7 ! L ? ? # O I *0 I $ ? N P I M !
Q" ? ! L ? ? # PI *0 I $? NO I MR ! ! "
! + %!
, 7 9 !+ "" " ! %! <
! 7 0 IK -
" 7 ! L ? ? # PI *0 I $M ! Q" ? ! L ?# P
I *0 I $MR ! ! " ! + %!
% &
' #( 4 $ 6 ) (( ( $ "
64 ( &1 64 ( "" " ) ( " ( ""
&< ! ( "" " ) 76 $
6 6 $ & ( ( (
" ( "" &
! ( " " " ) ( !! $ * 9+
: ! > 9E "( ! ! +
! % " # $1 " 6 ! # 9 +$- ! + "" ! ") %)
! %! ! ! " ! ! # $ 0 I # 9 %# $ ! /L
" G M" - ! " # 3$% 6 ! # 3 9 +$ "" ""%
) "" ! ( " ! !
F I G 3%# H
! "" ! ! " ! ! ! !
! + " ! ! "" ! " ! ! +
! ( " " " ) ( !! (
: ! > 9E "( ! # "$ ! +

! # $ % " ! ! # J $- ! ""% !
/ & ( !
0( & " ! 11 =
! ! " #+" " ! ! " > 9E ! #+" 9 @ " 4% 1

! " ""% ) " ! ( " ! !
F K G 3%# H
! " ! ! " ! ! " # 3$% ""%

1 " #3 9 $
1 ! " # ( "
@ ! " - "" > 9E # !# $1 "

+" ! 9 $ ! # $ % " ##
" > 9E !
! "" ! ! !+ " H ! %! "" !
%! ! !+ " ! # $ % " 6 ! # 9 +$ ! #$
% " # - C K $L 9 " 7# I M2 !! - !# ""% !
B # ! 6 ! ## 9 +$- ! "" ! ! !! "
! ! @ ! ! - ! "" ! "
% + ! A4> -! !+ " !1 !
1( "
& ! ! ) # 4 $7 - ! + "" ! !
! " !0 I # " 0H4$ ! & "" " ! ! ! !
!1 )- ""% N +" ! " ! ! ""%
! & "" " ! ! ! " - % ) ! 6 %! ""
% ! ! "" " !
& ! + " !1 - "" 0 I "! ! ! ! !1 )

! " !
2 "" " " ! ! &3 # $

%) ! " ! ! ! #$ % " # 9 ,$;
! # $ ! ! " "" " ! " !
! !+ ""% "" ; "" ! % " +" ! " "
! ! % ""
2 "" " "" " ! ! ! !

%) ! " ! ! 9 ,
2! + " ""! !+ !) ! 6 %! !
""!+ ! " ) ! 6 %! !
& ! ! ") C3E I !+ #C44$ ! !

" ! ! % ! + - "" " / ! !+ !
- ! ! ! ! " ! !
.
0 "" "
2 ! + " ! ! 9+ "" ! ) !+
" ) ! 6 %! ! ! ! !! "
! !
F! ! + " ! ! !+ ")! +
" ! !- "" ! ) !+ ! %) !+ "
! ! ! ! !! " ! !
F! ! + " ! !%" 9+
L G M" - " ! !%" 9 +- ""!+ !
" ) ! 6 %! !
2 ! + " ! !%" 9 , "" " ""

! !+ !! !+ ") ! + " !+ !
" ) ! 6 %! !
F! ! + " ! !%" J+
L G M " - " ! !%" J +- ""
! ! " ! !%"
" #
/ ! " 6 !
"" ! ! " !' ! %" - %" &&' ' - ""% ! ! %)

! /#8 $ % " # %" &&' ' $ ! %" ' ! # $
% "# %" &&' ' $ 1 " " ! ! ! /#8 $
! 6- "" ! % ) ! 6 %!
4 =
2 # " !
4) ! 6 %! %! " - " ! !-% + ! %" "-% ! " !
4) ! 6 %! " - " ! !-% + ! %" "- "!
4) ! 6 %! %! " - " ! !- "" + ! %" "-% ! " !
4) ! 6 %! %! " - " ! !- !! + ! %" "
! !+
L ! " 6
S! !' ! %" ""% ! %"

%) ! #$ "# %" &&' ' $@ ! ! %"
""% %" &&' ' -&&' ' -&&' ' &&' '
& %" !+ "" ! ! # 6 9 ! %" &&' ' $-

%" "" ! ) + ! %" " % - "" -! ! " + ! %" "
/ & ( !
0( & " ! 11 ;
% &
'- ( (F @ H !&
B +! %" ! !1 ! # ! &3-
+ ! %" "- ! ! % ! %) %" ! %" +
!1 ! $- %" "" ! ) ! 6 %! % + ! %" "
( . 9 =
5 "6
-
&3 # $ / / %*
&3' / # !1 ! $
% &
' M 8N ! 8 4 " OM63N ! 6 3 &
( . 9 =
1 6! 2 %
% ! * " #63$ %* 7 < % ! & ! !! "
%* 7 < + " %" - !
+ " %"
+ ! %" " &3 # / $ 4 %" &&' ' : ") " !)
/" !) ! !# 8$ F! + ! %" " " & ! 1 + " %" -%
# % - ) - >8$- " ! - " ! 2
" 7 / #4 %" &&' ' $ / " - ! % + ! %" " -
89 + % ! ! #4
%" &&' ' $
! 6 . 9 =
5 "6
-
&3 #" $
" # $- " # $ " " " "
* 6 . 9 =
1 6! 2 %
" # $ 3 %) " %)
&3
" # $ 0 %! "" " #
" !1 ! ") % ! !
" !" $
&3 #" $ 8 ! %" &&' ' 0 " 9 ! "" ) /
) ! 6 %! T %
! %" &&' ' !
%" &&' '
+
$ % &
!1 )%" # %) !1 ) #! $ " $ "" " !1 "

!1 ! ! 2 + " %" ! + ! "" ! ! L" 7 "6 ! " 4
! $ M !1 !1 )" 2 " !1 ) "" % %" &&' ' -
% " %" &&' '
, 2 ) =
5 "6
-
F" " !+ !
!1 )#!$
% &
' M1 N " " OM N " ! " OM N < O
M N 6 &
0 2 ) =
1 6! 2 %
! 1 ) #!$ 4 %" &&' '
! + # $ 9 +<! 2 " ! ! ! ! )-
! 1 ) " ! + " ! 1 ) 9
9 <! + % ! ! 1 ) 9 ""
! 1 ) !) ! ! "
! !
2 ! # $ 4 & ! + % -
! # $ ! + %" !
< ""
2 ! ! +! " ! ! ! 1 "
' (
! "" ! "" ! ! %) ! !
%" &&' ' - % " > ! ! ! ! + ! %" ! + ""
! ! ! # $ ! %" &&' ' "+ " ! ! ! &
! ! " %" &&' ' - ! + "" ! "" %) "
! ! ""% ! ! ! " !
% &
'# " " ) 6 ( ( ( !#6 !" " )
! ( !) ) &
/ & ( !
0( & " ! 11
4 =
5 "6
-
D D D D D D D D D
D % D % D % D % D % D % D % D % D %
D D D D D D D D D
D D D D D D D D D
D D D D D % D % D D
D -D D D D D D D D D
C D C C C C C C C
C4 #0I $ ! ! C4 C4 C4 C4 C4 C4
C4 ! C4 C4 C4 C4 C4 C4 C4
% &
'M N ! 6 6 ! ( !" ! &
) *
" ! ! ! ""% %" &&' ' - % "

%" &&' '
! %" "" ! ! ! " ) ! " ""%

%" &&' ' 2 ! "" ! ! %" + %
1 " U V2! + "" ! " > 9E ! %"
+ % 1 " U V
+ # =
5 "6
-
!1 ) /#!$$-! !1 !1 !1 / / / /
/#8 $
! # $ ! ! ! ! !
!1 ) /#!$$- ' ! !1 !1 !1 / / / /
# $-!
/#8 $
# =
1 6! 2 %
! 1 ) /#! $$ < ! / ! 1 ) %" ! %
<! " # ! 1 ) ! 1 ) " #2 ! !
/ "" $ ! " ! 1 ) %" $
1 6! 2 %
' ! # $ 9 +<8 %" &&'
'
9 8 ! %
! " # $
! /#8 $ ! %
! " #2
! ! ! " " $
9 $ # $ %! !
! 1 ) # 78 $ "
WWWWWWWWWWWWWWWWWWW
Chapter 4
DEFINITIONS FOR COMPACT POSITION REPORTING (CPR)
4.1 INTRODUCTION
This section provides the Compact Position Reporting (CPR) encoding scheme to be used by VDL Mode 4 stations.
4.2 PARAMETER SYMBOLS, DATA TYPES, CONSTANTS AND VARIABLES
4.2.1 Parameter symbols
The parameter symbols outlined in Table II-4-1 are defined in the context of CPR. Other parameters have been listed in
previous chapters of this manual.
Table II-4-1. Summary of parameter symbols for CPR

TR1 Maximum age for use in global decode 4.10.2.1
TR2 Maximum time between global updates 4.10.2.2
4.2.2 Data types
4.2.2.1 All calculations in this chapter shall use signed integers.
Note.— Division is therefore considered to be integer division (the result of a division is truncated to an integer).
4.2.2.2 The results of any calculations used to perform encoding and decoding shall match the results of
calculations which are performed with 64-bit signed integer operations.
4.2.3 Constants
The constants used to describe CPR shall have the values defined in Table II-4-2.
Table II-4-2. Constants used in CPR calculations
Type Name Value Description
Integer LATZ 9 Number of zones from 0° to 90° latitude.
Integer MAXC 251 Maximum value for longitude and latitude.
Integer MAXC 212 − 1 Maximum transmitted latitude value.
Integer MAX Tlon 214 − 1 Maximum transmitted longitude value.
II-4-1
4.2.4 Variables
Note 1.— CPR calculations convert between three representations of a station’s position:
a) The external representation of latitude and longitude which is meaningful to applications.
b) The internal representation which provides an integer representation of the position.
c) The link representation which is the encoded position.
Tables II-4-3 and II-4-4 divide the variables and functions used in the CPR calculations into these three
categories.
The variables used in CPR calculations shall have the type and range restrictions defined in Table II-4-3. [A, B] shall
mean greater than or equal to A [(A, B) A] and less than or equal to B [(A, B) B].
Table II-4-3. Variables used in CPR calculations

External representation
Real Latitude [0,90], [270, 360] The input latitude (arbitrary precision real number).
Real Longitude [0,360] The input longitude (arbitrary precision real number).
Internal representation
Integer type, typelast 0 or 1 The type of CPR (0 = even, 1 = odd).
Integer clatin, clonin [0, MAXC] Latitude and longitude to be encoded.
Integer tmpn [0, MAXC] Temporary variable number n. Only used to make expressions and
functions more readable.
Integer clatref [0, MAXC] Reference latitude for local decoding.
Integer clonref [0, MAXC] Reference longitude for local decoding.
Integer X Any integer.
Integer pos1, pos2 [0, MAXC] A latitude or longitude.
Integer clatdec [0, MAXC] Decoded latitude.
Integer clondec [0, MAXC] Decoded longitude.
Integer Bits 3, 5 or 7 Number of bits in the correction message.
Integer latoffs [0, 2bits – 1] Latitude correction.
Integer slat 0 or 1 Sign of the latitude correction.
bits
Integer lonoffs [0, 2 – 1] Longitude correction.
Integer slon 0 or 1 Sign of the longitude correction.
Integer latp [0, 19] The latitude patch.
Integer lonp (pid) [0, 35] The longitude patch.
Link representation
Integer Cprf 0 or 1 CPR format even/odd
Integer Lat [0, MAXTlat] Encoded latitude.
Integer Lon [0, MAXTlon] Encoded longitude.
Chapter 4. Definitions for Compact Position Reporting (CPR) II-4-3

lat
Integer latref, lat0, lat1 [0, MAXT ] Encoded latitude.
lon
Integer lonref, lon0, lon1 [0, MAXT ] Encoded longitude.
bits +1
Integer lat4, lat6, lat8 [0, 2 – 1] Encoded latitude offset
Integer lon4, lon6, lon8 [0, 2bits +1 – 1] Encoded longitude offset
Integer Pid [0, 719] Encoded patch id (pid).
Note 2.— All CPR computations use integer-valued longitude and latitude (in the range of 0, MAX C , where
360
each step is ≈ 0.1598721155 ×10-12 degrees). The conversion from arbitrary-precision real numbers is
MAX C + 1
detailed in the 4.2.5 to 4.2.6.
4.2.5 Functions
The functions used in CPR shall have the input parameters and return values defined in Table II-4-4.
Table II-4-4. Input parameters and return values for functions used in CPR calculations

Function returns value in internal representation
Number of zones depending on the type (odd/even) of CPR
Integer nz(type) format.
Integer dlat(type) Latitude patch size for type type.
Integer nl(clatin, type) Looks up the value in the transition level table (Table II-4-5).
Integer dlon(clatin, type) Longitude patch size at latitude clatin for type type.
Integer latofs(lat, latref) Latitude zone offset.
Integer lonofs(lon, lonref) Longitude zone offset.
Integer declat(clatref, lat, latref, type) Local latitude decoding.
Integer declon(clatdec, clonref, lon, lonref, type) Local longitude decoding.
Integer latseg(lat0, lat1, typelast) Latitude segment for global decoding.
Integer lonseg(lon0, lon1, clatin, typelast) Longitude segment for global decoding.
Integer globalDeclat(lat0, lat1, typelast) Global latitude global.
Integer globalDeclon(lon0, lon1, clatdec, typelast) Global longitude global.
Integer fix(x) Converts negative coordinates to positive.
The value that corresponds to clatin and type in the transition
Integer lookup(clatin, type) level table.
Integer diff(pos1, pos2) The (shortest) distance between pos1 and pos2.
Integer sign(pos1, pos2) The sign of diff(pos1, pos2).
Integer offsetdeclat(latoff, slat, bits, type) Calculates the true offset for the latitude offset given in bits bits.
Calculates the true offset for the longitude offset given in bits
Integer offsetdeclon(clatdec, lonoff, slon, bits, type) bits.
Integer latp(clatin, type) Calculates the latitude patch.

Integer lonp(clatdec, clonin, type) Calculates the longitude patch.
Integer fullDeclat(lat, latp, type) Decodes full position latitude.
Integer fullDeclon(clatdec, lon, lonp, type) Decodes full position longitude.
Function returns value in link representation
Integer enclat(clatin, type) Returns the CPR encoded value for clatin using type type.
Integer enclon(clatdec, clondec, lat, type) Returns the CPR encoded value for clonin using type type.
The difference between clatin and clatdec expressed using bits
Integer offsetenclat(clatin, clatdec, bits, type) bits.
The difference between lonin and clondec expressed using bits
Integer offsetenclon(clatdec, clonin, clondec, bits, type) bits.
Integer encpatch(latp, lonp) Encode the patch id (pid).
4.2.6 Patch constants
4.2.6.1 Transition table
The function lookup (clatin, type) shall return the value in the number of zones (even or odd, depending on type)
columns in Table II-4-5 for which the clatin value satisfies the restriction in the Range (integer) column.
Table II-4-5. Transition table for lookup function
Number of zones
Range (degrees) Range (integer) Even Odd
< 13.518674176405572 < 84559299976949 35 34
[13.518674176405572,19.162797152134097] [84559299976949,119863286269066] 34 33
[19.162797152134097,23.5247169626056] [119863286269066,147147092426093] 33 32
[23.5247169626056,27.228512609375226] [147147092426093,170314332279771] 32 31
[27.228512609375226,30.51543280332421] [170314332279771,190874016391806] 31 30
[30.51543280332421,33.50899730287358] [190874016391806,209598760787195] 30 29
[33.50899730287358,36.28248037044658] [209598760787195,226946895939473] 29 28
[36.28248037044658,38.883571527761575] [226946895939473,243216719782307] 28 27
[38.883571527761575,41.34536944123708] [243216719782307,258615264457015] 27 26
[41.34536944123708,43.691961273699334] [258615264457015,273293195154609] 26 25
[43.691961273699334,45.941527811563425] [273293195154609,287364232684706] 25 24
[45.941527811563425,48.10819571981785] [287364232684706,300916739329498] 24 23
[48.10819571981785,50.20320392571675] [300916739329498,314021014573143] 23 22
[50.20320392571675,52.23567067731592] [314021014573143,326734093052511] 22 21
[52.23567067731592,54.213116139057256] [326734093052511,339103013392294] 21 20
[54.213116139057256,56.14182888275907] [339103013392294,351167110605961] 20 19
[56.14182888275907,58.02712896497076] [351167110605961,362959661644475] 19 18
Number of zones
Range (degrees) Range (integer) Even Odd
[58.02712896497076,59.87356014060077] [362959661644475,374509087692437] 18 17
[59.87356014060077,61.68503184003544] [374509087692437,385839842234890] 17 16
[61.68503184003544,63.46492412462716] [385839842234890,396973067553844] 16 15
[63.46492412462716,65.2161639281094] [396973067553844,407927071618287] 15 14
[65.2161639281094,66.9412773021877] [407927071618287,418717654880330] 14 13
[66.9412773021877,68.6424192797632] [418717654880330,429358297069654] 13 12
[68.6424192797632,70.32137954962614] [429358297069654,439860192688716] 12 11
[70.32137954962614,71.97955727480327] [439860192688716,450232093501524] 11 10
[71.97955727480327,73.61788995824008] [450232093501524,460479863588517] 10 9
[73.61788995824008,75.23670452702919] [460479863588517,470605547878490] 9 8
[75.23670452702919,76.83542194177753] [470605547878490,480605524480339] 8 7
[76.83542194177753,78.41195676510516] [480605524480339,490466748984332] 7 6
[78.41195676510516,79.9614066817654] [490466748984332,500158557411138] 6 5
[79.9614066817654,81.47284075679195] [500158557411138,509612576768200] 5 4
[81.47284075679195,82.91989876526003] [509612576768200,518663923862256] 4 3
[82.91989876526003,84.22404437738102] [518663923862256,526821353991124] 3 2
[84.22404437738102,84.99999999999986] [526821353991124,531674956009016] 2 1
≥ 84.99999999999986 ≥ 531674956009016 1 1
Note.— The table is symmetrical for latitudes in the range of 3 ⋅ MAX C 4 , MAX C (i.e. [–90, 0] degrees).
This means that for latitude, the range of 0 to 90 degrees is mapped to [ 0 − MAX C 4 ] and [−90 – 0 = 270 – 360] is
mapped to [ 3 ⋅ MAX C 4 − MAX C ].
4.2.6.2 Patch size functions
The size of a latitude and longitude patch shall be:
Latitude: nz (type ) = 4 × LATZ – type
MAX C
dlat ( type ) =
nz (type)
if clat in < MAX C / 2 , then nl (clat in , type ) = lookup (clat in , type )
otherwise , nl (clat in , type ) = lookup (MAX C – clat in , type )
MAX C
Longitude: dlon (clat in , type ) =
nl (clat in , type )
4.3 FIXED DATA FIELD POSITION ENCODING
4.3.1 General
Given an arbitrary position latitude (lat) and longitude (lon) and a desired type (odd or even), the lat, lon and cprf (CPR
format even/odd) subfields in the fixed data field of the synchronization burst shall be set to the value of enclat() and
enclon() computed as defined in 4.3.2.
4.3.2 Input parameters
The input parameters used for fixed data field encoding shall be defined as follows:
latitude = latitude to be encoded (enclat).
longitude = longitude to be encoded (enclon).
type = type of encoding (odd or even).
4.3.3 Calculations
4.3.3.1 Latitude
The encoded fixed latitude component shall be calculated as follows:
( latitude ) ⋅ ( MAX C + 1)
clatin =
360
MAX C
nz (type ) × mod [clatin , dlat (type )] +
2 × MAX Tlat
lat = enc lat (clat in , type ) =
MAX C
MAX Tlat
4.3.3.2 Longitude
The encoded fixed longitude component shall be calculated as follows:
( longitude ) ⋅ ( MAX C + 1)
clonin =
360
MAX C
nl (clat dec , type ) × mod [clonin , dlon (clat dec , type )] +
2 × MAX Tlon
lon = enc lon (clat dec , clonin , type ) =
MAX C
MAX Tlon
Note.— clatdec = declat (latitude, lat, lat, type) as defined in 4.4.3.2.
4.4 FIXED DATA FIELD POSITION LOCAL DECODING
4.4.1 General
When the position report processing state machine (see 4.10.3.2) indicates that local decoding is to be performed, then
the fixed data field position shall be decoded by using a single position report and an unambiguous global reference
location. The calculation shall return the latitude, longitude and type subfields.
Note.— Local decoding uses a single report from the target and a reference location which can be either the
position of the receiver (if only one type of report has been received from a target) or the last decoded position for the
target (if the unambiguous global position of the target is known).
The input parameters used for fixed data field decoding shall be defined as follows:
clatref = reference latitude.
clonref = reference longitude.
lat = CPR encoded latitude to be decoded.
lon = CPR encoded longitude to be decoded.
cprf = CPR format even/odd.
4.4.3 Calculations
Note.— See Table I-2C-9 in Appendix C to Chapter 2, Part I of this manual — Implementation Aspects of the
4.4.3.1 Supporting function
The supporting function for calculating the decoded fixed position field shall be as follows:
if x < 0, then fix ( x ) = x + 1 + MAX C
otherwise , fix ( x ) = x .
4.4.3.2 Latitude
The decoded fixed latitude component shall be calculated as follows:
type = cprf
(
latref = enclat clatref , type )
MAX Tlat
if (lat ref − lat ) > , then latoffs (lat , lat ref ) = 1
2
MAX Tlat
if (lat ref − lat ) < , then latoffs (lat , lat ref ) = –1
2
otherwise lat offs (lat , lat ref ) = 0
clatref
tmp1 = dlat ( type ) ⋅
dlat ( type )
(
+ latoffs lat , latref )
MAX C
× lat
MAX Tlat
clat dec = dec lat (clat ref , lat , lat ref , type ) = fix + tmp1
nz (type )
latitude =
[clat dec + offset lat ]
dec (latoffs , s lat , bits , type ) × 360
(MAX C + 1)
dec (latoffs , s lat , bits , type ) is defined in 4.7.3.1.

Note.— offset lat
4.4.3.3 Longitude
The decoded fixed longitude component shall be calculated as follows:
(
lonref = enclon clatdec , clonref , type )
MAX Tlon
if (lon ref – lon ) > , then lonoffs (lon ,lon ref ) = 1
2
MAX Tlon
if (lon ref – lon ) < , then lonoffs (lon ,lon ref ) = – 1
2
otherwise lon offs (lon , lon ref ) = 0
clon ref
tmp 2 = dlon (clat dec , type ) × + lon offs (lon , lon ref )
dlon (clat dec , type )
MAX C
× lon
MAX Tlon
clon dec = dec lon (clat dec , clon ref , lon , lon ref , type ) = fix + tmp 2
nl (clat dec , type )
longitude =
[clon dec
lon
+ offset dec ]
(clat dec , lonoffs , slon , bits , type ) × 360
(MAX C + 1)
lon
Note.— offset dec (clat dec , lonoffs , slon , bits , type ) is defined in 4.7.3.2.
4.5 FIXED DATA FIELD POSITION GLOBAL DECODING
4.5.1 General
When the position report processing state machine (see 4.10.3.2) indicates that global decoding is to be performed, then
the fixed data field position shall be decoded by using the most recently received odd and even fixed data field
positions. The calculation shall return the latitude, longitude and type fields.
Note.— The global decoding is guaranteed to succeed if the target has travelled less than 8.4 NM between the odd
and even position report and if the target has not crossed any transition latitude between the reports.
The input parameters used for fixed data field global decoding shall be defined as follows:
lat0 = even CPR encoded latitude to be decoded.
lon0 = even CPR encoded longitude to be decoded.
lat1 = odd CPR encoded latitude to be decoded.

lon1 = odd CPR encoded longitude to be decoded.
cprf = type of encoding (odd or even) for the most recent of the two CPR reports.
4.5.3 Transition level straddling
If nl[globalDeclat(lat0, lat1, 1, 0)] ≠ nl[globalDeclat(lat0, lat1, 0),0], then decoding as defined in 4.10.3.3 shall be
computed instead of a global decode.
Note.— This situation occurs when the target has straddled a transition latitude.
4.5.4 Calculations
Note.— See Table I-2C-9 in Appendix C to Chapter 2, Part I of this manual — Implementation Aspects of the
4.5.4.1 Latitude
The globally decoded fixed latitude component shall be calculated as follows:
typelast = cprf
MAX Tlat
lat 0 × nz (1) + 2 × nz (type last ) × MAX Tlat + – lat1 × nz (0)
2
tmp3 =
MAX Tlat
lat seg (lat0 , lat1 , type last ) = mod [tmp 3 , nz (type last )]
tmp 4 = lat seg (lat 0 , lat 1 , type last ) × dlat (type last )
MAX C
× lat type last
MAX Tlat
clat dec = globalDec lat ( lat 0 , lat 1 , type last ) = tmp 4 +
nz (type last )
4.5.4.2 Longitude
The globally decoded fixed longitude component shall be calculated as follows:
MAX Tlon
lon 0 × nl (clat dec , 1) + 2 × nl (clat dec , type last ) × MAX Tlon + – lon 1 × nl (clat dec , 0)
2
tmp5 =
MAX Tlon
lon seg (lon 0 , lon 1, clat dec , type last ) = mod [tmp 5 , nl (clat dec , type last )]
tmp 6 = lon seg (lon 0 , lon 1 , clat dec , type last ) × dlon (clat dec , type last )
MAX C
× lon type last
MAX Tlon
clon dec = global Dec lon (lon 0 , lon 1 , clat dec , type last ) = tmp 6 +
nl (clat dec , type last )
4.6 INFORMATION FIELD OFFSET ENCODING
4.6.1 General
Given a position and its fixed data field position encoding (see 4.3), a high resolution offset encoding of size bits,
together with an additional bit indicating the sign of the offset, shall be computed as defined in 4.6.3. The offset shall
be encoded in the subfields lat4, lon4 (for bits = 3), lat6, lon6 (for bits = 5) or lat8, lon8 (for bits = 7), depending on
which synchronization burst variable part is to be transmitted (see Chapter 3).
The input parameters used for information field offset encoding shall be defined as follows:
clatin = latitude to be encoded.
clonin = latitude to be encoded.
lat = the CPR encoded latitude (see 4.3).
lon = the CPR encoded longitude (see 4.3).
type = type of CPR (odd or even).
bits = number of bits in magnitude of the offset.
4.6.3 Calculations
4.6.3.1 Supporting functions
The supporting function for calculating the information field offset shall be as follows:
if pos 1 > pos 2 + MAX C 2 , then diff ( pos 1 , pos 2 ) = pos 1 – pos 2 – MAX C – 1
if pos 2 > pos 1 + MAX C 2 , then diff ( pos 1 , pos 2 ) = pos 1 – pos 2 + MAX C + 1
otherwise , diff ( pos 1 , pos 2 ) = pos 1 – pos 2
if diff ( pos 1 , pos 2 ) ≥ 0, then sign ( pos 1 , pos 2 ) = 1
otherwise , sign ( pos 1 , pos 2 ) = 0
4.6.3.2 Latitude
The encoded fixed latitude offset shall be calculated as follows:
lat = enclat ( clatin , type )
clatdec = declat ( clatin , lat , lat , type )
MAX C
tmp 7 =
(
2 × nz (type ) × MAX Tlat × 2 bits – 1 )
tmp7
diff (clat in , clat dec ) +
enc (clatin , clat dec , bits , type ) =
offset lat 2
tmp 7
lat 4 (bits 1 to 3) = offset lat

enc (clat in , clat dec , 3, type )
lat 6(bits 1 to 5) = offset lat

enc (clatin , clatdec , 5, type )
lat 8(bits 1 to 7) = offset lat

enc (clatin , clat dec , 7 , type )
(
lat 4 ( bit 4 ) = lat 6 ( bit 6 ) = lat8 ( bit 8 ) = sign clatin , clatdec )
4.6.3.3 Longitude
The encoded fixed longitude offset shall be calculated as follows:
(
lon = enclon clatdec , clonin , type )
(
clondec = declon clatdec , clonin , lon, lon, type )
MAX C
tmp 8 =
(
2 × nl (clat dec , type ) × MAX Tlon × 2 bits – 1 )
tmp8
(
diff clonin , clondec + )
offsetenc (
lon clat
dec , clonin , clondec , bits, type = ) tmp8
2
lon clat
lon4 ( bits 1 to 3) = offsetenc (
dec , clonin , clondec ,3, type )
lon clat
lon6 ( bits 1 to 5) = offsetenc (
lon clat
lon8 ( bits 1 to 7 ) = offsetenc (
(
lon4 ( bit 4 ) = lon6 ( bit 6 ) = lon8 ( bit 8 ) = sign clonin , clondec )
4.7 INFORMATION FIELD OFFSET DECODING
4.7.1 General
To decode the information field latitude and longitude offsets, the offset values defined 4.7.2 shall be added to the
position from the fixed data field position decoding (either local or global) to determine the actual target position.
The input parameters used for information field offset decoding shall be defined as follows:
lat4, lat6, lat8 = received latitude offset.
lon4, lon6, lon8 = received longitude offset.
clatdec = the target’s decoded latitude (see 4.4.3.2)
4.7.3 Calculations
4.7.3.1 Latitude
The decoded fixed latitude offset shall be calculated as follows:
if lat4, lon4 are provided as input, then bits = 3

if lat4, lon4 are provided as input, then latoffs = lat 4 (bits 1 to 3)
if lat6, lon6 are provided as input, then latoffs = lat 6 (bits 1 to 5 )
if lat8, lon8 are provided as input, then latoffs = lat 8 (bits 1 to 7 )
if lat4, lon4 are provided as input, then s lat = lat 4 (bit 4 )
if lat6, lon6 are provided as input, then s lat = lat 6 (bit 6)

if lat8, lon8 are provided as input, then s lat = lat 8 (bit 8)
MAX C
tmp 9 =
(
2 × nz (type ) × MAX Tlat × 2 bits – 1 )
lat
if slat = 1, then offset dec (latoffs , slat , bits , type ) = latoffs × tmp7
if lat
slat = 0, then offset dec (latoffs , slat , bits , type ) = – latoffs × tmp7
Note.— tmp7 is defined in 4.6.3.2.
4.7.3.2 Longitude
The decoded fixed longitude offset shall be calculated as follows:
if lat 4 , lon 4 are provided as input, then lonoffs = lon 4 (bits 1 to 3)
if lat 6, lon6 are provided as input, then lonoffs = lon 6 (bits 1 to 5)
if lat8, lon8 are provided as input, then lonoffs = lon 8 (bits 1 to 7 )
if lat 4 , lon4 are provided as input, then s lon = lon 4 (bits 4 )
if lat 6, lon6 are provided as input, then s lon = lon 6 (bits 6)

if lat8, lon8 are provided as input, then s lon = lon 8 (bits 8)
MAX C
tmp10 =
(
2 × nl (clat dec , type ) × MAX Tlon × 2 bits – 1)
lon
if slon = 1, then offset dec (clat dec , lonoffs , slon , bits , type ) = lonoffs × tmp8
lon
if slon = 0, then offset dec (clat dec , lonoffs , slon , bits , type ) = – lonoffs × tmp8
Note.— tmp8 is defined in 4.6.3.3.

4.8 PATCH ID (PID) ENCODING
4.8.1 General
When a station sends an unambiguous global position in a single message, then it shall transmit the value of encpatch()
as the pid.
The input parameters used for patch ID encoding shall be defined as follows:
clatin = latitude to encode.
clonin = longitude to encode.
4.8.3 Calculations
The encoded patch ID shall be calculated as follows:
MAX C clat in
if 0 ≤ clatin ≤ , then lat p =
4 dlat (type )
MAX C clat in
if clatin > , then lat p = – 16
4 dlat (type )
lat = enc lat (clat in , type )
clat dec = dec lat (clat in , lat , lat , type )
clonin
lon p =
dlon (clat dec , type )
pid = enc patch (lat p , lon p ) = 36 × lat p + lon p
4.9 PATCH ID (PID) DECODING
4.9.1 General
The pid decoding shall use the received pid, latitude (lat) and longitude (lon) subfields and decode the pid to a position
in latitude and longitude which is globally unambiguous.
The input parameters used for patch ID decoding shall be defined as follows:
lat = CPR latitude to decode.
lon = CPR longitude to be decode.
pid = encoded patch id
4.9.3 Calculations
4.9.3.1 Latitude
The decoded latitude component of the patch ID shall be calculated as follows:
pid
if 0 ≤ pid ≤ 359, then lat p =
36
pid
if pid ≥ 359, then lat p = + 16
36
MAX C
× lat
MAX Tlat
fullDec lat (lat , lat p , type ) = + dlat (type ) × lat p
nz (type )
4.9.3.2 Longitude
The patch ID longitude component shall be calculated as follows:
lon p = mod ( pid ,36 )
(
clatdec = fullDeclat lat , lat p , type )
MAX C
× lon
MAX Tlon
fullDec lon (clat dec , lon , lon p , type ) = + dlon (clat dec , type ) × lon p
nl (clat dec , type )
4.10 POSITION REPORT PROCESSING
4.10.1 Services
The Peer Entity Contact Table (PECT) (see 4.10.3.1) shall maintain sufficient history of received targets so that the
unambiguous global position can be determined.
4.10.2 Position report parameters
The position report parameters shall be as defined in Table II-4-6.
Table II-4-6. Position report processing parameters

TR1 Maximum age for use in global decode 1 sec 60 sec 30 sec 1 sec
TR2 Maximum time between global updates 1 sec 240 sec 60 sec 1 sec
4.10.2.1 Parameter TR1 (maximum age for use in global decode)
The parameter TR1 shall be the maximum age of a report for its use in a global decode. The timer shall be started (or
restarted) as defined in Table II-4-7. If it expires, the report shall not be valid for use in a global decode.
4.10.2.2 Parameter TR2 (maximum time between global updates)
The parameter TR2 shall be the maximum time between global updates. The timer shall be started (or restarted) as
defined in Table II-4-7.
4.10.3 Position report processing procedures
4.10.3.1 Position report processing state machine
For each station maintained in the PECT (see 1.5.5.2 of Part II of this document — Manual on Detailed Technical
Specifications for the VDL Mode 4 Digital Link), the station shall maintain the record of the last received position
report and a position report processing state machine with the following states:
a) State 1 shall indicate that no position report has been received and represents the initial state of the position
report processing state machine.
b) State 2 shall indicate that a position report has been received but that no position has been decoded.
c) State 3 shall indicate that a position report has been received and that a local position has been decoded.
d) State 4 shall indicate that a position report has been received and that a global position has been decoded.
4.10.3.2 Position report processing state machine transitions
On receipt of a position report, the station shall update its state machine as defined in Table II-4-7 and report target
position quality to the application.
Table II-4-7. State transitions for CPR processing
In State 1 2 3 4
Received Own Timers (exp =

position posi- expired)
report type tion TR1 TR2
N=4 N = 4, N = 4, N = 4,
Even or odd C = GL C = GL C = GL C = GL
with patch resTR1 resTR1, resTR1, resTR1,
ID n/a n/a n/a resTR2 resTR2 resTR2 resTR2
N=4
C = L2
Not exp resTR1
N=4 N=4 N=4
N=3 N=3 C = GL N=3 C = GL N=3 C = GL
Not C = L1 C = L1 resTR1 C = L1 resTR1 C = L1 resTR1
Even Yes exp Exp resTR1 resTR1 resTR2 resTR1 resTR2 resTR1 resTR2
Not exp N = 4, C = L2, resTR1

N=3 N=3
C = L1 C = L1
N=4
C = L2
Not exp N=4 N=4 resTR1 N=4
C = GL C = GL N=3 C = GL
Not N=2 N=2 resTR1 N=2 resTR1 C = L1 resTR1
No exp Exp C = NO C = NO resTR2 C = NO resTR2 resTR1 resTR2
Not exp N = 4, C = L2, resTR1

N=2
C = L1 N=2
N=4
C = L2
Not exp N=4 N=4 N=4 resTR1
N=3 C = GL N=3 C = GL N=3 C = GL N=3
Not C = L1 resTR1 C = L1 resTR1 C = L1 resTR1 C = L1
Odd Yes exp Exp resTR1 resTR2 resTR1 resTR2 resTR1 resTR2 resTR1
Not exp N=3 N=3 N = 4, C = L2, resTR1

C = L1 C = L1
N=4 N=4 N=4 N=4
Not N=2 C = GL N=2 C = GL N=2 C = GL C = L2
No exp Not exp C = NO resTR1 C = NO resTR1 C = NO resTR1 resTR1
In State 1 2 3 4
resTR2 resTR2 resTR2 N=3
C = L1
Exp resTR1
Not exp N=2 N = 4, C = L2, resTR1

C = L1 N=2
Note 1.— State transitions depend on:
a) the initial state;
b) the type (even or odd) of the last received position report;
c) the type of received position report (even/odd/with patch ID/without patch ID);
d) whether or not the station has knowledge of its own position; and
e) the state of timers TR1 and TR2.
Note 2.— The station carries out the actions defined as “C =” in Table II-4-7:
a) C = GL: carry out global decoding as defined in 4.5 if there is no patch ID, or as defined in 4.9 if there is a
patch ID;
b) C = L1: carry out local decoding using station'

s own position as reference, as defined in 4.4;
c) C = L2: carry out local decoding using the last known position of the transmitting station as reference, as
defined in 4.4;
d) C = NO: no decoding is carried out.
Note 3.— The station restarts timers TR1 and TR2 as indicated in Table II-4-7:
a) resTR1: restart timer TR1
b) resTR2: restart timer TR2
Note 4.— The state machine enters the state indicated as “N =” in Table II-4-7 and reports the target position
quality to the application:
a) if the final state is 1 or 2, the station indicates a target position quality of “none”;
b) if the final state is 3, the station indicates a target position quality of “local”; and
c) if the final state is 4, the station indicates a target position quality of “global”.
4.10.3.3 State machine transitions for transition level straddling
When a position report is received from a station which fulfils:
a) the conditions for the initial state, last received report type, received report type, own position and timer states
defined in Table II-4-8; or
b) the conditions defined in 4.5.3 are met (because the station has crossed a transition latitude),
the receiving station shall update its state machine as defined in Table II-4-8 and report the target position quality to the
application. Otherwise, the station shall process the report as defined in 4.10.3.2.
Table II-4-8. State transitions for CPR processing (transition level straddling)
In State 1 2 3 4
Received Own Timers (exp =
position position expired)
report type TR1 TR2
Even Yes Not exp Not exp See Table See Table N= 3 See Table N= 3 See Table N= 4
II-4-7. II-4-7. C= L1 II-4-7. C= L1 II-4-7. C= L2
resTR1 resTR1 resTR1
exp N=3
C= L1
res TR1
No Not exp Not exp N= 2 N= 2 N= 4
C= NO C= NO C= L2
exp N= 2
C= NO
resTR1
Odd Yes Not exp Not exp See Table N= 3 See Table N= 3 See Table N= 4 See Table
II-4-7. C= L1 II-4-7. C= L1 II-4-7. C= L2 II-4-17.
exp N=3
C=L1
resTR1
No Not exp Not exp N= 2 N= 2 N= 4
C= NO C= NO C= L2
exp N= 2
C= NO
resTR1
— END —
© ICAO 2004
6/04, E/P1/1360
Order No. 9816

Printed in ICAO

Manual On VHF Digital Link (VDL) Mode 4: Doc 9816 AN/448

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual On VHF Digital Link (VDL) Mode 4: Doc 9816 AN/448

Uploaded by

Copyright:

Available Formats

Doc 9816

Approved by the Secretary General

First Edition — 2004

International Civil Aviation Organization

Approved by the Secretary General

First Edition — 2004

International Civil Aviation Organization

RECORD OF AMENDMENTS AND CORRIGENDA

No. Date Entered by No. Date Entered by

Chapter 5, Part I describes potential future applications of VDL Mode 4.

Chapter 3, Part II provides additional material for ADS-B applications.

The Secretary General

PART I. IMPLEMENTATION ASPECTS

List of illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-(i)

Acronyms, abbreviations and symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-(v)

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-1

1.2 Background to the development of VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-1

1.3 Technical context of the functional capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-1

1.4 Overview of VDL Mode 4 services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-3

1.5 Communication services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-3

1.6 Surveillance functions and applications of VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-4

1.7 VDL Mode 4 capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1-11

Chapter 2. Technical description and operating principles of VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1

2.2 Physical elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-1

2.3 Functional design principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-3

2.4 Functional elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-4

2.5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2-51

Appendix A to Chapter 2. Link management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-1

1. Synchronization burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2A-1

Appendix B to Chapter 2. Automatic Dependent Surveillance —

1. Fixed data field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2B-1

Appendix C to Chapter 2. Compact Position Reporting (CPR) encoding algorithm. . . . . . . . . . . . . . . . . . I-2C-1

1. Characteristics of the Compact Position Reporting (CPR) algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2C-1

Chapter 3. Architectures and implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-1

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-1

3.2 Redundancy considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-1

3.3 Aircraft architectures and implementation aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-4

3.4 Ground architectures and implementation aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-12

3.5 Airport and vehicle architectures and implementation aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-20

3.6 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-23

3.7 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-24

3.8 Certification and approval aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-3-24

Chapter 4. Channel management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-1

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-1

4.2 The use of multiple channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-1

4.3 Channel management and channel switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-3

4.4 Airborne equipment for multiple channel use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-8

4.5 Transition aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-8

4.6 Channel management scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-8

4.7 Description of regional definitions for channel management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4-30

Appendix A to Chapter 4. Failure modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4A-1

Appendix B to Chapter 4. ADS-B requirements air-to-air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4B-1

Chapter 5. Potential future applications for VDL Mode 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-1

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-1

5.2 Overview of VDL Mode 4 services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-1

5.3 Functions and applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-2

5.4 Summary of potential future VDL Mode 4 capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5-6

PART II. DETAILED TECHNICAL SPECIFICATIONS

List of illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-(i)

Acronyms, abbreviations and symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-(vii)

Chapter 1. Link layer protocols and services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-1

1.1 General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II-1-1