B-VHF Operational Concept

Transcription

1 REPORT D-07 B-VHF Operational Concept PROJECT NUMBER: PROJECT ACRONYM: PROJECT TITLE: INSTRUMENT: THEMATIC PRIORITY: AST3-CT B-VHF BROADBAND VHF AERONAUTICAL COMMUNICATIONS SYSTEM BASED ON MC-CDMA SPECIFIC TARGETED RESEARCH PROJECT AERONAUTICS AND SPACE PROJECT START DATE: DURATION: 30 MONTHS PROJECT CO-ORDINATOR: FREQUENTIS GMBH (1) (FRQ) A PRINCIPAL CONTRACTORS: DEUTSCHES ZENTRUM FÜR LUFT UND RAUMFAHRT E.V. (2) (DLR) D NATIONAL AIR TRAFFIC SERVICES (EN ROUTE) PLC (3) (NERL) UK LUFTHANSA GERMAN AIRLINES (4) (LH) D BAE SYSTEMS (OPERATIONS) LTD (5) (BAES) UK SCIENTIFIC GENERICS LTD (6) (SGL) UK UNIVERSITEIT GENT (7) (UGent) B UNIVERSIDAD POLITECNICA DE MADRID (8) (UPM) E PARIS LODRON UNIVERSITAET SALZBURG (9) (UniSBG) A DEUTSCHE FLUGSICHERUNGS GMBH (10) (DFS) D UNIVERSIDAD DE LAS PALMAS DE GRAN CANARIA (11) (ULPGC) E DOCUMENT IDENTIFIER: D-07 REVISION: 1.0 DUE DATE: SUBMISSION DATE: LEAD CONTRACTOR: FREQUENTIS DISSEMINATION LEVEL: PU - PUBLIC DOCUMENT REF: 04A02 E Project co-funded by the European Community within the 6 th Framework Programme ( )

2 History Chart Issue Date Changed Page (s) Cause of Change Implemented by All sections New document Frequentis All sections Review within consortium Frequentis Authorisation No. Action Name Signature Date 1 Prepared M. Sajatovic Approved B Haindl Released C. Rihacek Dieses Dokument ist elektronisch freigegeben. This document is released electronically. The information in this document is subject to change without notice. All rights reserved. The document is proprietary of the B-VHF consortium members listed on the front page of this document. No copying or distributing, in any form or by any means, is allowed without the prior written agreement of the owner of the proprietary rights. Company or product names mentioned in this document may be trademarks or registered trademarks of their respective companies. Copyright B-VHF Consortium Page: I

3 Contents 1. B-VHF Project Description Executive Summary Scope ATM Context ATM Concepts of Operations ATM OC by ATM OC by AOC Concepts of Operations Aeronautical Communications Applications and Services Operational Communications Applications Operational Communications Services An Introduction ATS Operational Services Controller Flight Crew ATS Services Voice ATS Services ATC Clearance (ACL) Automatic Controller-Pilot DL Communications (Auto-CPDLC) ATC Microphone Check (AMC) DL only Data Link Taxi Clearance Delivery (D-TAXI) Data Link Surface Information and Guidance (D-SIG) DL only Departure Clearance Service (DCL) Down Stream Clearance (DSC) Pilot Preferences Downlink (PPD) DL only Dynamic Route Availability (DYNAV) DL only Arrival Manager (AMAN) Information Delivery Service (ARMAND) Graphical Enabler for Graphical Co-ordination (GRECO) DL only Common Trajectory Co-ordination (COTRAC) DL only Automated Downlink of Airborne Parameter Services Copyright B-VHF Consortium Page: II

4 Flight Plan Consistency (FLIPCY) DL only Flight Path Intent (FLIPINT) DL only System Access Parameters (SAP) Flight Information Services (FIS) Data Link Operational Terminal Information Service (D-OTIS) Data Link Runway Visual Range (D-RVR) Data Link Operational En Route Information Service (D-ORIS) Data Link Significant Meteorological Information (D-SIGMET) Data Link Automatic Terminal Information Service (D-ATIS) Data Link Flight Updates Service (D-FLUP) Traffic and Surveillance Services Automatic Dependent Surveillance Contract (ADS) Automatic Dependent Surveillance Broadcast (ADS-B) Traffic Information Service Broadcast (TIS-B) Emergency and Ancillary Services Urgent Contact Service (URCO) Data Link Alert (D-ALERT) DL only Communications Management Services Data Link Logon (DLL) DL only ATC Communication Management (ACM) AOC Operational Services AOC Voice Services AOC Data Services Out Off On In (OOOI) NOTAM Request/NOTAMs Free Text Weather Request/Weather Report Position Report Flight Status Fuel Status Gate and Connecting Flight Status Engine Performance Reports Maintenance Troubleshooting Flight Plan Request/Flight Plan Data Load Sheet Request/Load Sheet Transfer Copyright B-VHF Consortium Page: III

5 Flight Log Transfer Real Time Maintenance Information Graphical Weather Information Online Technical Trouble Shooting Real-Time Weather Reports for Met Office Technical Log Book Update Cabin Log Book Transfer Update Electronic Library Software Loading Classification of Operational Communications Services B-VHF Functional Principles and System Architecture B-VHF Functional Principles Introduction to B-VHF Terrestrial System Broadband System Integrated System Cellular System Multi-carrier System CDMA System B-VHF Time Structure B-VHF Protocols Physical Layer (PHY) Data Link Layer (DLL) Link Management Entity (LME) Data Link Services (DLS) Sub-layer B-VHF Special Services (BSS) Sub-layer Medium Access Control (MAC) Sub-layer Sub-network Layer (SN) B-VHF Mechanisms and Procedures B-VHF System Configuration Net Initialisation Initial Net Entry Service Selection Forced Handover Copyright B-VHF Consortium Page: IV

6 Seamless Handover Net Exit Resource Allocation Acknowledged point-to-point data link (B-DA) Not acknowledged (broadcast) FL data link (B-DB) Not acknowledged RL data link (B-DN) Selective voice services (B-VS) B-VHF Architecture Ground B-VHF Subsystem Air Subsystem External Systems Supporting B-VHF Operation B-VHF Communications Services Scope of B-VHF Communications Services Mapping of Operational Services to B-VHF Services B-VHF Voice Services Party-line Voice Service (B-VP) Connection Establishment/Release Using the Service Realisation of CoS Classes Broadcast Voice Service (B-VB) Connection Establishment/Release Using the Service Realisation of CoS Classes Selective Voice Service (B-VS) Connection Establishment/Release Using the Service Realisation of CoS Classes B-VHF Data Services Acknowledged Data Link Service (B-DA) Connection Establishment/Release Using the Service Realisation of CoS Classes Broadcast Data Link Service (B-DB) Connection Establishment/Release Copyright B-VHF Consortium Page: V

7 Using the Service Realisation of CoS Classes Not Acknowledged Data Link Service (B-DN) Connection Establishment/Release Using the Service Realisation of CoS Classes Scenarios of B-VHF System Operational Usage Scenario Communication Allocation between Voice and Data Pre-Departure Phase Departure - Airport Departure in TMA En Route Arrival in TMA Arrival - Airport Arrival Taxi Post Flight Phase Scenario Communication Allocation between Voice and Data Pre-Departure Phase Departure Airport Departure in TMA En Route Arrival in TMA Arrival Airport Arrival Taxi Post Flight Phase Conclusions References Abbreviations Copyright B-VHF Consortium Page: VI

8 Illustrations Figure 1-1: B-VHF Project Work Breakdown Structure Overview Figure 4-1: Airspace Regimes by Figure 6-1: Time-frame structure Figure 6-2: B-VHF Protocol Stack Figure 6-3: Mapping of B-VHF Channels (Airborne View) Figure 6-4: Net Initialisation Procedure Figure 6-5: Content of Decoded PBTCH Channel Figure 6-6: Initial Net Entry Procedure Figure 6-7: Forced Handover Figure 6-8: Seamless Handover Figure 6-9: Net Exit Procedure Figure 6-10: FL B-DA Transmission Figure 6-11: RL B-DA Transmission Figure 6-12: FL B-DB Transmission Figure 6-13: RL B-DN Transmission Figure 6-14: A/C Initiated Link Establishment Procedure for B-VS Service Figure 6-15: GS Initiated Link Establishment Procedure for B-VS Service Figure 6-16: A/C Initiated Link Release Procedure for B-VS Service Figure 6-17: GS Initiated Link Release Procedure for B-VS Service Figure 6-18: B-VHF Ground System Architecture Figure 6-19: Representative B-VHF Airborne Architecture Figure 7-1: B-VHF Services and Interfaces Figure 7-2: Example of Application Technology Mapping Figure 7-3: CoS B-VHF Service Mapping Figure 7-4: B-VP Service - Realisation of CoS v1 and CoS v3 Classes Figure 7-5: B-VB Service - Realisation of CoS v4 Class Figure 7-6: B-VS Service - Realisation of CoS v2, CoS v5 and CoS v_aoc Classes Figure 7-7: B-DA Service - Realisation of CoS D1, D3, D4 and D-AOC Classes Figure 7-8: B-DB Service - Realisation of CoS D6-1 and D3 Classes Figure 7-9: B-DN Service - Realisation of CoS D6-2 and CoS D5 Classes Copyright B-VHF Consortium Page: VII

9 Tables Table 6-1: Example of LME Information Obtained via Scanning Table 6-2: Example of B-ID/PDTCH Mapping Table 7-1: Mapping of Operational ATS/AOC Applications to B-VHF Services Table 8-1: Mapping of ATS and AOC Services to Domains Copyright B-VHF Consortium Page: VIII

10 1. B-VHF Project Description Air transport has been identified as a dominant factor for sustainable economic growth of the European Union. The "Vision 2020" clearly points out the cornerstones of a future air transport system and the Advisory Council for ATM Research in Europe (ACARE) elaborates these requirements in depth in their "Strategic Research Agenda". A/G communication is the key enabler for achieving an Air Transport System that is capable of meeting future demands. The communications in the VHF aeronautical communications (COM) band ( MHz) are particularly attractive as they provide adequate coverage with moderate equipment power and acceptable price. Today, an analogue VHF voice communications system is still used for tactical aircraft separation and guidance. This communications technology has been introduced in the '40s and generally utilises the available VHF spectrum in an inefficient and inflexible manner. A small part of the COM spectrum is used by several types of aeronautical data links (ACARS, VDL Mode 2, and VDL Mode 4) for safety-related data link communications. After 2010, the VHF COM band in Europe is expected to become progressively saturated. This is expected to happen in spite of the recent introduction of the 8.33 khz DSB-AM voice system and the VDL Mode 2 data link that both use the VHF spectrum in a more efficient manner than the "old" solutions. The main reason for the saturation is the traditional ATM operational concept based on the tactical control of aircraft that generates increased demand for voice communications channels proportional to the increase in air traffic itself. The problem can only be solved by adopting new ATM concepts. Strategic European documents and recent studies indicate that a relief after 2010 may be achievable with intensive usage of the aeronautical data link. The tactical Air Traffic Control (ATC) will shift towards strategic Air Traffic Management (ATM), and at the same time the demand for new VHF voice communications channels would be reduced. Today s VHF solutions including VDL Mode 2 data link - cannot fulfil performance and capacity requirements of future data link applications. As there are no plans to deploy VDL Mode 3 system in Europe, VDL Mode 4 remains as the only European option to replace VDL Mode 2 data link in the future. VDL Mode 4 as a pure data link technology without support for voice communications is capable of solving only a part of the congestion problem. In order to provide expected data link capacity, VDL Mode 4 would require multiple VHF channels that are difficult to find and coordinate. As there are still some unresolved architectural issues, there is no guarantee that VDL Mode 4 airborne radio can be operated without interference with analogue VHF voice radios. EUROCONTROL s Communications Strategy clearly points out the need for alternative communications systems. Air Traffic Service Providers (ATSPs) preference is to retain existing ground communications facilities, so an integrated voice-data system in the VHF range would be highly appreciated, being capable of using same physical locations of ground stations and same interconnecting infrastructure as the current VHF system. Therefore, more and more attention in Europe is directed towards broadband VHF technologies. Within the course of the B-VHF project bottom up research on multi-carrier technology (MC) for aeronautical communications is carried out. This work will result in the definition of a new future MC broadband VHF (B-VHF) system, which is able to support Single Copyright B-VHF Consortium Page: 1-1

11 European Sky, Free Flight and other advanced concepts and programmes, leading far beyond 2015 into Vision The B-VHF project is conducted under Priority #4/ Aeronautics and Space of the Sixth Framework Programme (FP6) of the European Commission (EC). The target technology is MC-CDMA, a highly innovative, high capacity technology that is also discussed for fourth generation (4G) mobile communications systems. However, the project will investigate possible implementation outside the VHF range, as well as non- CDMA access schemes. The B-VHF system has the potential to exploit the mobile VHF aeronautical channel better than any currently discussed VHF communication alternative. It increases voice and data capacity and addresses security and safety issues, promising a service level that is today unknown to the aeronautics user. Moreover, it has the potential to preserve the excellent inherent cost-range characteristics of the VHF band. It may eventually be applied as an overlay system and co-exist with the available VHF infrastructure, providing smooth transition and rollout scenarios. The proposed B-VHF system will support both voice and data link communications. The main expected benefits of the future B-VHF communications system are:! High spectral efficiency - the broadband B-VHF system uses VHF spectral resources more efficiently than today's narrowband VHF communications systems! High communication capacity - the total capacity of the B-VHF system is higher than the aggregate capacity of VHF systems deployed today or planned for a near future! Flexibility - the B-VHF system may be easily adapted to provide support for new operational and communications requirements! Security - the B-VHF system is inherently resistant against narrowband jamming and provides mechanisms supporting end-to-end data security! Sound transition path - the B-VHF system uses the knowledge about the current usage of VHF spectrum and may be able to share the VHF spectrum with legacy narrowband VHF systems without adverse interfering effects The high-level goal of the B-VHF project - proving the feasibility of the broadband MC- CDMA technology and demonstrating its benefits to the aeronautical community - requires a series of interrelated tasks that have been encapsulated as five separate workpackages in the B-VHF project:! WP 0 "Project Management and Quality Assurance"! WP 1 "B-VHF System Aspects"! WP 2 "VHF Band Compatibility Aspects"! WP 3 "B-VHF Design and Evaluation"! WP 4 "B-VHF Testbed" Figure 1-1 summarises the detailed work breakdown of the B-VHF project, including main work packages and all sub-work packages: Copyright B-VHF Consortium Page: 1-2

12 WP 0 Project Management and Quality Assurance WP 1 B-VHF System Aspects WP 2 VHF Band Compatibility Aspects WP 3 B-VHF Design and Evaluation WP 4 B-VHF Testbed WP 0.1 Project Management WP 1.1 B-VHF Operational Concept WP 2.1 Theoretical VHF Band Compatibility Study WP 3.1 VHF Channel Modelling WP 4.1 Baseband Implementation WP 0.2 Validation and QM WP 1.2 Reference Environment WP 2.2 VHF Channel Occupancy Measur. WP 3.2 PHY Layer Design & SW Implementation WP 4.2 VHF Frontend Development WP 0.3 Knowledge Management WP 1.3 B-VHF Deployment Scenario WP 2.3 Interference Modelling WP 3.3 DLL Layer Design & SW Implementation WP 4.3 B-VHF Testbed Evaluation WP 3.4 Protocol Design & SW Implementation Project Management Research, technological development and innovation WP 3.5 B-VHF Evaluation Figure 1-1: B-VHF Project Work Breakdown Structure Overview WP 0 "Project Management and Quality Assurance" comprises all activities that are essential to all work packages. It takes care of achieving high quality results throughout the whole project. It covers all management activities on Consortium level, in particular the information exchange and co-ordination with the European Commission and with the partners. A separate sub-work package has been destined for the validation and quality control which reflects the importance of maintaining high quality outputs in all project phases. Another sub-work package is dedicated to manage new knowledge generated within the B-VHF project in terms of intellectual property rights and dissemination strategies. WP 1 "B-VHF System Aspects" establishes the necessary connection between the scope and goals of the B-VHF project and the high-level objectives of the EC, European and global aeronautical community. Starting at the very beginning of the B-VHF project, this work package will produce high-level requirements for the B-VHF system, describe the reference aeronautical environment and produce the B-VHF Operational Concept document. By the end of the B-VHF project, the WP 1 will produce the B-VHF Deployment Scenario document, describing technological, operational and institutional issues of the B-VHF initial deployment, transition and operational usage. WP 2 "VHF Band Compatibility Aspects" assesses by theoretical (modelling) and practical (measurements) means probably the most critical aspect of the future B-VHF broadband channel: its capability to be installed and operated "in parallel" with legacy Copyright B-VHF Consortium Page: 1-3

13 narrowband channels, sharing the same part of the VHF spectrum, but remaining robust against interference coming from such legacy narrowband VHF systems. The investigations will also address the conditions for interference-free operation of the B-VHF system towards legacy narrowband VHF systems. The Theoretical VHF Band Compatibility Study developed in the WP 2 will provide inputs to the WP 1 required for the development of the B-VHF Deployment Scenario. Together with the B-VHF Interference Model developed in the WP 2, the Theoretical VHF Band Compatibility Study will also be used as input for the B-VHF system design and evaluation (WP 3). WP 3 "B-VHF Design and Evaluation" covers B-VHF system design tasks, starting with developing the model of the broadband VHF channel, and proceeding with the development and implementation of the SW representing the physical (PHY) B-VHF layer, DLL layer, higher protocol layers and representative aeronautical applications. The design and implementation tasks will be augmented by the development of detailed evaluation plans and corresponding simulation scenarios. The B-VHF Evaluation Reports produced in the WP 3 will provide necessary feedback to the B-VHF Deployment Scenario task of the WP 1. The WP 3 will also produce as a deliverable a complete set of the B-VHF System Design and Specification documents. The prime objective of the B-VHF project - demonstrating the capabilities of the MC-CDMA technology - will be achieved within the scope of the WP 3 by using intensive and layered simulation trials. This task will start with investigating the capabilities and performance of the B-VHF physical layer and will proceed by adding/integrating the DLL and upper protocol layers, respectively. The "generic" B-VHF technology validation will be concluded by considering specific requirements coming from the aeronautical environment and applications. The WP 3 will develop and implement a SW set of representative communications applications and verifies by simulation means that the B-VHF system can support a mix of such applications under nearly-realistic loading, while fulfilling the Quality of Service (QoS) and other requirements of each particular application. WP 4 "B-VHF Testbed" covers the baseband implementation and evaluation of a first B-VHF testbed for both the forward- and the reverse-link. The implementation is carried out in DSP technology and is restricted to the physical layer, which is the most critical part of the B-VHF development. The B-VHF baseband implementation is interfaced to the low-power broadband VHF frontend, thus, enabling testbed evaluation not only in the baseband but also in the VHF band. Testbed evaluation in the baseband is performed using channel and interference models, which are also implemented in DSP technology. The VHF band evaluation is carried out in the laboratory using actual VHF systems as interference sources and victim receivers, respectively END OF SECTION Copyright B-VHF Consortium Page: 1-4

14 2. Executive Summary The B-VHF deliverable D7 B-VHF Operational Concept describes the concept of operation when the B-VHF technology is used as an aeronautical communications system. Aspects of the B-VHF cell coverage, radio bandwidth, system capacity and performance are out of scope of this document. Similarly, aspects of frequency planning have been excluded. Clarifying these issues will require further detailed work within the B-VHF project, including extensive simulations. For the purpose of this document, it was assumed that the B-VHF system can provide sufficient physical coverage, capacity and performance as required by the operational concept it is introduced to. Above aspects, as well as details of the B-VHF system deployment, including the end-toend communications chain, will be described separately in the B-VHF deliverable D27 B-VHF Deployment Scenario. The B-VHF OC presented in this document was developed for the full-size B-VHF system on a per-service basis, allowing for flexible adding/removal of services, dependent on the deployment concept (that is yet to be developed). High-level ATM OCs that are expected to be in place in Europe within next two decades comprise many different operational issues that rely not only upon communications, but also include many other technologies. The OC for 2011 is based on [CONOPS_2011] and can be seen as an intermediate step in achieving by 2020 the final goal described in [OCD_2.1] - a flexible ATM system, based on information sharing, collaborative and coordinated layered planning, with associated paradigm shift from controlling the air traffic towards management by planning and intervention by exception. Both OCs rely upon gradually increasing air-ground communications capability, in the terms of scope of supported operational services and the overall volume of voice and data link traffic. Specific demands of ATM OCs with respect to mobile (A/G) communications are articulated through operational communications applications. [MACONDO_S] distinguishes between Pilot-Controller (ATCO) dialogue, Pilot-Pilot dialogue, Automated provision of flight information, Automated provision of aircraft information, ATM Automation and Air-air surveillance operational applications. As from the B-VHF project view any new communications system must support AOC communications in order to be accepted by the Airlines and thus easier deployable for ATS communications, an additional class - AOC Operational Applications - has been added. Communications applications can in turn be de-composed into operational communications services, comprising voice and data link services. Examples of operational services are ATC Clearance (ACL), Data Link Runway Visual Range (D-RVR) or ATC Surveillance for radar areas (ADS B RAD). All operational services that appear in the operational scenarios for the years 2015 and 2025, respectively, are described in Chapter 5 of this document. Generally, the operational services have been developed as data link services, but the most of the data link services have been based on voice communications, so the service description is applicable to both voice and data link context. NOTE: Some advanced services cannot effectively be deployed by using voice. Such services have been clearly indicated in Chapter 5. B-VHF is a terrestrial broadband VHF integrated voice/data link cellular system based on multi-carrier techniques and CDMA. The system has been designed to provide a broad Copyright B-VHF Consortium Page: 2-1

15 range of communications services, preferably in the VHF, but possibly also in other aeronautical ranges. Internally, the B-VHF system implements additional system-specific data transfer capabilities and mechanisms (e.g. for configuration data, acknowledgements, voice signalling, channel status indication). Such capabilities are not directly available to external users and are referred to as B-VHF system services. They are described, together with B-VHF system functional principles, time structure, ground and airborne architecture, in Chapter 6 of this document, taking the possible constraints due to the target overlay deployment concept into account. Particular attention during the system design has been taken with respect to the required airborne architecture the participating airline has clearly indicated that any new A/G communications technology would appear as a relatively small part of the entire airborne architecture, that the existing architectures are difficult to adapt, and that changes introduced or mandated by a new communications system should be kept at a necessary minimum. B-VHF technology provides to the external user a set of specific internal communications capabilities (referred to as B-VHF communications services ). Independently or combined together, these capabilities provide communications support for all classes of voice and data operational services identified in the Chapter 5 of this document. B-VHF communications services comprise:! Party-line voice service (B-VP)! Broadcast voice service (B-VB)! Selective voice service (B-VS)! Acknowledged data link service (B-DA)! Broadcast data link service (B-DB)! Not acknowledged data link service (B-DN) Mapping of operational services onto these generic capabilities is provided in Chapter 7, together with detailed description of how each of B-VHF communications services is used in support of existing and emerging operational service classes. As an example, it is described in detail how the current party-line voice feature would be re-built within the B-VHF system. Service descriptions comprise details of user connection/disconnection to the service and indicate/propose required controller s/pilot s HMI modifications when using advanced system capabilities that are not supported by now. Finally, two operational scenarios have been presented, one for the year 2015, another one for the year 2025, based on [CONOPS_2011] and [FCOCR_01], respectively. The emphasis of the description is on air-ground exchanges. Scenarios assume that the ground-ground ATM communications have reached the state where they allow for full CDM and SWIM implementation. Ground-ground exchanges e.g. for the purpose of coordination or update/synchronisation of local data bases are not described. For each scenario a virtual flight has been described with typical per-flight communications events, including voice and data link, ATS and AOC operational communications. This basic information is supplemented by the B-VHF-specific information, describing system-specific events along the virtual flight. Copyright B-VHF Consortium Page: 2-2

16 As the B-VHF system deals only with mobile aeronautical communications, the scenarios cover only flight phases where such communications actually take place (pre-departure, departure taxi, departure in TMA, En-route, arrival in TMA, arrival taxi, and post-flight). The main difference between two scenarios except for different expected B-VHF equipage is that in the first scenario (2015) broadcast surveillance services (ADS-B, TIS-B) and addressed voice communications are not supported. Correspondingly, the B- VHF GSs functionality has been limited to support for party-line and broadcast voice services, ATN-compatible data link, as well as non-atn data link. In the second scenario (2025) these initial restrictions upon the B-VHF system have been removed. Now the B-VHF system provides the full scope of voice and data link services it has been designed for. In particular, the B-VHF system now has more VHF resources available and can provide additional capacity, supporting additionally to the services from the previous scenario - broadcast surveillance data link services (ADS-B, TIS-B) and addressed voice communications END OF SECTION Copyright B-VHF Consortium Page: 2-3

17 3. Scope The B-VHF deliverable D7 B-VHF Operational Concept describes the concept of operation when the B-VHF technology is used as an aeronautical communications system. New communications solutions like B-VHF are important enablers for emerging ATM Operational Concepts (OCs). Such OCs typically assume that the enabling technologies with required features will be there when needed. However, the technological solutions are not perfect each real technology has its internal limitations and will provide maximum benefits only if it is carefully mapped to the OCs it intends to support. Designing such an aligned communications system was an explicit goal of the B-VHF project. This document describes how the specific operational requirements of known ATM operational concepts are supported by the B-VHF system design. The deliverable D7 comprises the following chapters:! 1. Introduction! 2. Executive Summary! 3. Scope! 4. ATM Context! 5. Aeronautical Communications Applications and Services! 6. B-VHF Functional Principles and System Architecture! 7. B-VHF Communications Services! 8. Scenarios of B-VHF System Operational Usage! 9. Conclusions! 10. References! 11. Abbreviations High-level ATM OCs that are expected to be in place in Europe within next two decades comprise many different operational issues that rely not only upon communications, but also include many other technologies. An outline of two OCs envisioned for the years 2011 and 2020 is given in Chapter 4 ATM Context. The OC for 2011 can be seen as an intermediate step in achieving the final goal by a flexible ATM system, based on information sharing, collaborative and co-ordinated layered planning, with associated paradigm shift from controlling the air traffic towards management by planning and intervention by exception. ATM OCs have their specific needs with respect to mobile (A/G) communications that are expressed through operational communications applications that in turn can be decomposed into operational communications services. Chapter 5 provides a classification of communications applications and a brief explanation of voice or data link communications services that will later appear within an operational scenario. B-VHF functional principles and system architecture have been described in Chapter 6 with the scope as required for understanding the B-VHF operational concept. This chapter describes basic principles of the selected system approach, provides a short overview of B-VHF protocols, system architecture and internal mechanisms that effectively enable B- VHF communications services. In this document it was assumed that the performance of ground networks and systems that appear as a segment of the air-ground Copyright B-VHF Consortium Page: 3-1

18 communications chain is non-critical (the challenges related to the ground-ground communications are out of scope of the B-VHF project). B-VHF technology provides to the external user a set of specific internal communications capabilities (referred to as B-VHF communications services ). These services are described in Chapter 7 of this document. Independently or combined together, B-VHF communications capabilities provide communications support for all operational services. Finally, Chapter 8 proposes two scenarios of operational B-VHF system usage for safetycritical aeronautical communications applications. The scenarios operate with the Air Traffic Service (ATS) and Airline Operational Communications (AOC) services described in Chapter 5 of this document. These operational services have been mapped onto B-VHF communications services described in Chapter 7, assuming the B-VHF system architecture described in Chapter 6. The time scales for the selected two ATM scenarios and corresponding communications scenarios will be driven by the regional needs and will depend on the dynamics of the introduction of the general regional ATM concept. The first scenario roughly corresponds to the time of initial introduction of the B-VHF system, while the second scenario addresses the time when the system is expected to be fully deployed END OF SECTION Copyright B-VHF Consortium Page: 3-2

19 4. ATM Context This chapter briefly describes Air Traffic Management (ATM) concepts of operation that may be in place in Europe at the time of initial B-VHF system introduction and when the system becomes fully deployed. The focus within this chapter is put on the required mobile communications support ATM Concepts of Operations The first considered concept of operation is based on [CONOPS_2011]. It reflects the realistic short-term vision and describes the situation around 2011 that may be also well applicable to the estimated time of the B-VHF system introduction (between 2015 and 2020). It represents an intermediate stage in the seamless transition towards the target ATM concept. The communications part is based on the set of known communications technologies. The detailed definitions of operational services with their associated communications requirements are mature as well. The second concept of operation based on [OCD_2.1] is a desired target concept from the current point of view and describes the situation around This concept will remain valid until 2025 and beyond. Within this time-frame, the B-VHF system may become completely deployed on the ground, with high percentage of B-VHF equipped aircraft. The target concept includes a degree of uncertainty (as not all long-term aspects are clear by now) and may have to be refined before it will be operationally introduced. In particular, the exact scope, detailed definition and requirements of the operational communications services that would be applicable in that time frame are not yet completely clear. As this document uses a mapping of operational services onto generic service classes defined in [B-VHF D5], it has been assumed that any new service from the target ATM concept of operation by 2020 will fit into [B-VHF D5] service classification ATM OC by 2011 The following description of the ATM Operational Concept (OC) by the year 2011 is based on [CONOPS_2011]. This OC represents an intermediate necessary step between the current OC and the target OC that is expected to start in Europe from As an intermediate concept, it is well aware of current technological, institutional and other constraints. It operates with a set of mature operational services that may be deployed in the target time-frame by using realistic set of mature communications technologies. The European ATM system is continuously evolving, driven by ongoing initiatives such as the Single European Sky and the Dynamic Management of European Airspace Network. Within the four dimensions of human aspects, procedures, systems and institutional aspects, ATM actors will have to cope with changing requirements on human skills, new and harmonised operational procedures crossing ATM partner business boundaries, changing requirements on their systems and newly implemented rules and regulations. Present ATM organisation and infrastructure have their inherent limitations that cannot be solved by only changing the technology. Until 2011, the main ATM improvement will be achieved due to the optimised layered planning process that involves all ATM actors Copyright B-VHF Consortium Page: 4-1

20 and is based on Collaborative Decision Making (CDM). These actors will have access to the common data repository through system-wide information management (SWIM). The actors will also have their specific obligations and rights with respect to providing and using shared information. The concept assumes that all associated issues like ownership of data, intellectual property rights, data security, access rights and the quality of data have been successfully solved by implementing respective rules and regulations. If necessary, internal procedures of different actors will have to be aligned to be able to take full advantage of CDM. Overall communications security will have to be increased and the corresponding mechanisms have to be implemented. These mechanisms covers user authentication and measures for maintaining privacy of sensitive data. The main CDM mechanism in the 2011 time-frame will be the Network Operations Plan, integrating local data repositories of different ATM actors into a common global data repository that will be used by all actors for their internal planning. As the actors will feed back their decision results into the Plan, the Plan will always contain the most accurate and most up-to-date data. This will increase the overall system safety, will facilitate common situational awareness and will allow for the usage of improved local decisionsupport tools. The layered planning process will end with the Planning Controller who (due to CDM and SWIM) will have additional information available when making his decisions and will be able to flexibly react to user s request. The flexibility will extend to the management of the airspace, because the sector boundaries may start to be dynamically adjusted by that time. The efficiency of the Tactical Controller will be increased as well, as significant part of the traffic should be de-conflicted due to the improved planning. Improved planning, including demand and capacity determination, demand and capacity balancing and re-planning for optimisation, accompanied by the increased common situational awareness of the ATM partners and improved data consistency/quality due to SWIM will allow for the first move from the management by intervention paradigm towards management by planning and intervention by exception paradigm around The airspace structure by 2011 is designed according to the demand, allowing for user preferred trajectories whenever operationally viable and facilitating concepts such as free route operations. Properly equipped A/C will in some cases be able to establish a contract with a ground system, based on the preferred trajectory, and will be effectively exempted from the interventions of the Tactical Controller due to the more precise planning within the entire ATM system. The Flexible Use of Airspace Concept (FUA) will be in use in some areas, where the military authorities are releasing traditionally closed areas for use by civilian flights on a planned basis. Another example for the paradigm change are merging operations where the responsibility for the A/C separation from another A/C may be temporarily delegated to the pilot. This will be enabled by the initial introduction of Airborne Separation Assurance Systems (ASAS) that will increase situations awareness for both airborne A/C and A/C being on the airport surface and thus allow for a kind of real-time CDM between involved A/C. This paradigm shift will be accompanied by the new distribution of actors roles within the ATM system and will require new operational procedures for involved actors, including pilots and controllers. It will also require new or enhanced functionalities of the ATM Copyright B-VHF Consortium Page: 4-2

21 System, including those allowing for more autonomous aircraft operation under adverse weather condition. In particular, collaborative system-wide planning will require increased communications capabilities, including air-ground communications, while ASAS concepts will rely upon airair communications capability. In some cases, communication of real time events will be required, enabling ATM partners to take advantage of changing conditions in real time to achieve their preferences. On the long-term, the submission, processing and dissemination of shared information in the multi-domain ATM environment should become fully automated, delegated to dedicated cross-domain synchronisation systems and networks. This requires increased inter-system interoperability and the implementation of unified access rules to the common information within entire ATM domain. However, in the 2011 time-frame such automated synchronisation mechanisms may only exist on ground, as air-ground communications technologies (with known bandwidth and performance constraints), airborne and ground communications architectures and communication services that may be operationally available by then do not comprise full automated data synchronisation across an air-ground interface [FCOCR_01]. Therefore, only manual synchronisation mechanisms, articulated as dedicated operational communications services, will be available by The major challenge in Europe until 2011 with respect to mobile A/G communications will be related to the initial introduction of the ATS data link and the initial surveillance data link via LINK2000+ and CASCADE programmes. Existing voice communications solution (combination of 25 khz- and 8.33 khz DSB-AM systems) will remain in use in parallel to the data link. Most of the operational improvements in that time-frame will happen on the ground side (CDM, SWIM), aiming to improve the planning process ATM OC by 2020 The following description is based on [OCD_2.1] that represents a high-level description of the European ATM Operational Concept around the year It reflects the progress already achieved since the ATM Strategy has been published and can be seen as a further development of the ATM OC for 2011 described in the previous section. The main objective of ATM OC for 2020 is to provide a collaborative and co-ordinated layered planning framework for ATM operations in a gate-to-gate context based on the principles of Collaborative Decision Making and System Wide Information Management. A new operational concept is required due to the inherent inability of the ATM concepts and infrastructure to absorb the further forecast growth in demand. Even the intermediate achievements of the ATM OC for 2011 will not be sufficient additional conceptual upgrades are required to meet the users expectations in terms of improved flexibility, punctuality and reduced costs, and to fully exploit current and emerging technologies, while improving safety. However, methods to improve the operational productivity and safety of the overall ATM network cannot come at the expense of either ATC or cockpit workload. Because of the uncertainties inherent in forecasting some longer-term events, not all of the issues surrounding the target concept are, or can be, fully explored or resolved at this stage. Copyright B-VHF Consortium Page: 4-3

22 The ATM OC for 2020 is well aware of the limitations present in the real world, including those related to the technology. It is intended to be introduced as seamless, evolutionary process, providing benefits in an incremental way. As the OC for 2011, the target concept for 2020 is predicated on collaborative and coordinated layered planning, proposing a strategically-derived Operations Plan' (OP). It is based on collaborative decision-making amongst the involved parties with common rules and procedures for the ground and air elements - supported by a system-wide information management. The initial CDM/SWIM environment deployed around 2011 will further evolve, becoming a true global solution, resulting in another change to managing resources as well as the demand. It includes collaborative and integrated airspace planning and management for the whole European region that involves both military and civilian planners. There will be a continuing need for a ground based ATM element, but significant changes are expected in air-ground communication techniques (such as data-link for non-time critical transmissions) and surveillance (satellite based networks providing high quality global coverage and data). Improved communications will allow for full air-ground integration, intensive use of support tools, leading to an increase in sector capacity, reduced controller workload and improved safety. By 2020 the ATM system will rely on layers of planning and flight monitoring. This will create a kind of a closed-loop, where any non-conformance between actual and planned trajectory will easily be detected and corrected without reducing the system safety margin. The planning process extends over airspace management and design, flow and capacity management, multi-sector planning, as well as over co-ordinated actions of controllers and pilots. Clearly, this must be supported by advanced air-ground communications systems and solutions. The available airspace has a complicated structure aligned along national boundaries and fragmented by special use and military requirements. To make technical changes effective, it is necessary to first rationalise national interests with actual traffic patterns and to harmonise the rules applied, while respecting the airspace requirements of military users. The OC for 2020 envisions a system that combines total flexibility in areas of lighter traffic with a more structured routing system in busier areas. The airspace will be optimised up to the level where all European airspace can be considered to be a common useable ATM resource. Such pan-european airspace will be re-designed to provide the best service to the user instead of following traditional national boundaries. However, every State will continue to have complete and exclusive sovereignty over the airspace above its territory. This also requires adequate support by the new air-ground communications system. It will have to provide more flexibility, capacity and performance than the previous one. The ATM OC for 2020 concept incorporates a mix of fixed route structuring, free routings and autonomous aircraft operations (Figure 4-1). The Flexible Use of Airspace concept has evolved into the Dynamic Management of Airspace concept which will permit suitably equipped aircraft to select the most advantageous routing to destination (free route). Specific parts of airspace (e.g. Temporary Segregated Area TSA) may be approved for civil use if allowed by the current situation. Traffic structuring will still be required in Managed Airspace (MAS), in particular around major traffic centres. Incrementally increased A/C autonomy needs increased A/C capability. As it typically takes long time until all A/C are properly equipped, the future European ATM system must be capable of continuing to accommodate a broad mix of aircraft capability. Copyright B-VHF Consortium Page: 4-4

23 Autonomous Operations Free Route Operations TSA MANAGED AIRSPACE (MAS) MAS MAS Danger Area MAS MAS Restricted Area UNMANAGED AIRSPACE (UMAS) Figure 4-1: Airspace Regimes by 2020 Air Traffic Services, comprising ATC, FIS and alerting services, will continue to be the most important element of ATM due to the safety implications of the services provided. However, other ATM components will become more important. It is anticipated that the objectives of ATS will not change in general terms. On the other hand, the daily operation, corresponding procedures and particular roles will have to evolve, particularly in order to be able to respond promptly to real-time scenario variations. The role of the controller must be re-defined to take the existence of computer-based support tools into account. The human element will remain paramount in the ATM system of 2020, but the controller s role will evolve to management by planning and intervention by exception, whilst the pilot will share some of the tasks for separation. ICAO flight plan is clearly within the scope of the shared information, but for accurate traffic planning, additional data that is not currently included in the flight plan is required. Decisions regarding routings, airport capacity, wake vortex spacing requirements and the potential provision for traffic interruptions as a result of severe weather cannot be made without precise and reliable weather information. By 2020, the ATM system shall be able to utilise all available capacity at maximum efficiency regardless of weather, on a daily or even hourly basis. The availability of accurate weather information is therefore an essential ingredient of a safe and efficient ATM system. The development of an integrated information system is an essential component of the 2020 concept. It will provide accurate and current information on airspace and airport availability, user-preferred trajectories, traffic (both current and forecast), weather and Copyright B-VHF Consortium Page: 4-5

24 navigation restrictions. It will be accessible to all users and shall support both strategic and tactical decision making, so the continuous management of the quality, integrity and interoperability of the shared information will be essential. The concept of information sharing will be extended to the airborne segment, including air-air information sharing via set of advanced ADS-B applications. Full air-ground integration shall be enabled by 2020, comprising automated exchanges (synchronisation) between airborne and ground data systems that will remove need for human-intensive current communications procedures, while providing an increased level of data accuracy and consistency AOC Concepts of Operations It proved in the past that the Airlines acceptance of any new ATM concept is an extremely important issue. In particular, new communications technologies must be able to support existing and future AOC communications demands to be found acceptable by the Airlines. Once accepted for AOC purposes, the technology becomes easier deployable for ATS communications. Predictability of operations and safety improvement are permanent Airlines goals. But to convince them of the new concept, overall benefits that are expected from the new ATM concept, must be demonstrated to the Airlines, e.g. via Cost Benefit Analysis (CBA). ATM concepts of operation often consider Airline Operational Communications (AOC) to be en external issue (details of AOC aspects are not covered by [CONOPS_2011] or [OCD_2.1]). This is easily understood, as no common OC exists that would be applicable to all airlines. AOC applications involve voice and data transfer between the aircraft and the Aeronautical Operations Control centre, company or operational staff at an airport. AOC voice communications with operational coverage similar to today s coverage will be still required in the future, but the voice traffic volume will decrease with time. By now, most of AOC traffic is performed via data link. The amount of data link traffic will rapidly evolve as a result of both the increase in number of data link equipped aircraft as well as messages per aircraft and increased message content. AOC data link services may be roughly classified as either short-term services that will be in operation by the year 2011 and long-term services that will only be applicable within the target ATM concept for 2020 and beyond. Such advanced AOC data link services will require increased bandwidth and QoS because of the service nature. Such services cannot be effectively deployed by using today s communications resources and will have to wait for a better air-ground technology to come END OF SECTION Copyright B-VHF Consortium Page: 4-6

25 5. Aeronautical Communications Applications and Services This section provides an overview of operational mobile air-ground and air-air aeronautical communications applications, comprising Air Traffic Services (ATS), Airline Operational Communications (AOC), as well as Surveillance applications that are supported through a specific surveillance data link. Airline Passenger Correspondence (APC) communications are not considered, as these are non-safety communication services that should not be operated in the VHF band allocated for aeronautical mobile communication services. The description of operational services is based on [FCOCR_01] supplemented by [ODIAC], [CASCADE_S] and [OATA_CDS] Operational Communications Applications ATM Operational Concepts have their specific needs with respect to mobile (A/G) communications. Communications demands of a particular OC are articulated through operational communications applications that in turn can be de-composed into operational communications services. Operational communications applications and services impose specific requirements upon underlying communications technologies that must be fulfilled in any practical implementation for safety reasons. Regardless of whether voice or data link is used as underlying technology, six generic classes of operational ATS communications applications [MACONDO_S] cover all safety communications needs:! Pilot-ATCO Dialogue - communication between two entities (the aircrew and the ATCO) for ATC service. Message exchanges include a set of message elements (clearance/information/request), which corresponds to the current voice phraseology and could be extended to support further operational needs.! Pilot-Pilot Dialogue - communication exchanges between the aircrew of two different aircraft, in flight or eventually on ground (airport surface), for ATC service purpose (mainly co-ordination transactions).! Automated provision of flight information (ground-to-pilot communication) - based on automatic sending of ground-available information about aircraft environment.! Automated provision of aircraft information (aircraft-to-ground communication, mainly used for surveillance), allows ATCO and ground systems to obtain position data and other information from equipped aircraft.! ATM automation - automatic exchange of ATM-related data between the airborne system (mainly the FMS) and the ground system. Exchanged messages principally include trajectory and flight intent data.! Air-air surveillance (also used to enhance ground surveillance) - periodic transmission of data derived from on-board equipment to be used by other (close) aircraft or ground facilities. Operational AOC applications were out of scope of [MACONDO_S]. Within the B-VHF project it is assumed that these can be represented by a single generic class: Copyright B-VHF Consortium Page: 5-1

26 ! AOC Operational Applications - all communications exchanges between an aircraft and the Airline Operations Control centre, company or operational staff at an airport. The operational communications applications listed above are technology-independent and can in principle be deployed by using voice and/or data link (currently, most of ATS A/G communications needs are covered by using voice, while all major airlines use data link for AOC communications) Operational Communications Services An Introduction Detailed communications needs of different ATM concepts are realized in form of operational communications services. An operational ATS communications service refers [ODIAC] to the defined set of transactions with the clearly defined operational goal that begins and ends on an operational event. An operational communications application may comprise single or several operational communications services. In turn, a given operational service may be used in support of several operational applications. The operational communications services have been defined and developed for data link purposes, but most of them are already in use by using voice communications. The voice communications system is traditionally used in a transparent way. The system itself does not have to take care about the content of the voice exchanges. It just provides generic communications services like uplink broadcast or party-line voice channels. As the data link aims to provide automated support for data exchanges, it is used, but not directly controlled by human beings. In order to remain interoperable and reliable under safety-critical conditions, the data link systems must implement additional internal features that are not known within the voice context. In consequence, operational communications services, including the associated procedures, protocols, operational timers and messages must be precisely defined. As stated before, almost all kinds of communications demands can today be covered by using solely voice. Voice can therefore be used as a back-up for a significant number of data link operational communications services, but some newly developed data link services may not really be successfully deployed or alternatively provided by using the voice system. This has lead to the situation where the scope of defined operational data link services is broader than the scope of traditional voice services (that have never been formally defined as operational services, but are well used for the same purpose as their data link equivalents ). Within this document the acronyms for data link services (e.g. ACL, D-FIS, ACM,) will be used for both voice and data link services. In cases where it is anticipated that voice cannot be seen as an adequate equivalent for data link, this will be explicitly indicated by the DL only suffix ATS Operational Services The following classification and description of operational ATS services is based on [FCOCR_01] and was supplemented where appropriate by [CASCADE_S] and [OATA_CDS], respectively. Copyright B-VHF Consortium Page: 5-2

27 Controller Flight Crew ATS Services Voice ATS Services This class comprises all legacy ATS voice services that cannot be covered by other classes listed in the following sections ATC Clearance (ACL) The ACL service specifies the A/G dialogue exchanges between an A/C (pilot) and the controller. ACL can be voice, data link, or a combination of voice and data link communications. The content of ACL exchanges comprises A/C reports and requests, as well as ATSU clearances, instructions and notifications Automatic Controller-Pilot DL Communications (Auto-CPDLC) The Auto-CPDLC service provides automation support to controllers for the preparation and transmission of CPDLC, but also other non-tactical messages to multiple aircraft (multicast) ATC Microphone Check (AMC) DL only The CPDLC-based AMC service provides controllers with a means of contacting aircraft via data link, with an instruction for aircraft to check that they are not blocking the voice channel. The AMC service is a one-way uplink and requires no response Data Link Taxi Clearance Delivery (D-TAXI) D-TAXI service is a specific use of CPDLC/ACL on ground. It provides automated assistance to controllers and flight crews to perform data link communications for all ground movements operations (e.g. push back clearance, taxi routes) Data Link Surface Information and Guidance (D-SIG) DL only The D-SIG service provides to the aircrew a current static graphical airport map with an updated and integrated representation of all airport elements (e.g., taxiway closures, runway re-surfacing) that are relevant for ground movements, to be displayed on the cockpit graphical display. D-SIG service may be further improved by using the D-TAXI service to add to the graphical map the visual representation of taxi routes Departure Clearance Service (DCL) A flight due to depart from an airfield must first obtain departure information and clearance from the responsible ATS Unit (ATSU). The DCL Service provides automated assistance for requesting and delivering departure information and clearance via data link Down Stream Clearance (DSC) The DSC service enables flight crews to request and obtain downstream clearances or information from downstream ATSU (D-ATSU, i.e. ATSU that will assume the control of the flight in the future, but is not responsible for it yet). The DSC service is a specific instance of CPDLC/ACL with D-ATSU and can only be initiated by the aircrew. Copyright B-VHF Consortium Page: 5-3

28 Pilot Preferences Downlink (PPD) DL only PPD service automates the provision of selected flight crew preferences to controllers via data link. The main objective is to provide the ATSU controllers with updated information (pilot preferences) that was not available in the filled flight plan (e.g. maximum flight level, minimum speed, etc.). The pilot may also request modification of some flight plan elements (e.g., requested flight level). The information should be available to the controllers during all phases of the flight, even before the aircraft reaches a particular sector Dynamic Route Availability (DYNAV) DL only The objective of the DYNAV service is to automate the provision of route changes to the aircrew, if alternative routings can be offered by the ATSU (e.g. military airspace has been made available for civil use) - even before the flight is under their control. An automated ground system develops 2D route changing proposal and sends it to the selected aircraft. Once accepted by the aircrew, the route proposal becomes a clearance Arrival Manager (AMAN) Information Delivery Service (ARMAND) ARMAND service uses the data link to automatically transmit relevant arrival manager advisories with target, expected or revised approach-time advisories relevant to the destination airport directly to flight crews that are already within the optimum horizon of the AMAN, but may still be beyond the limits of the ATSU that contains the flight s destination airport. This exchange may subsequently be followed by an ACL transaction. If COTRAC service becomes available, it will supersede ARMAND service for the equipped aircraft Graphical Enabler for Graphical Co-ordination (GRECO) DL only GRECO service will provide a structured in-flight negotiation method for establishing and re-planning trajectory-based contracts/clearances between aircrew and controllers by using CPDLC and graphical interfaces. Both the flight crew and controller can initiate the coordination and are supported by their local automation, in particular the FMS. Flight crews can freely choose how they would meet ATC constraints by creating single new constraint eventually they are returning to the planned route Common Trajectory Co-ordination (COTRAC) DL only The purpose of COTRAC is to provide a structured in-flight negotiation method for establishing and re-planning 4D trajectory contracts in real time by using graphical interfaces and automation systems, in particular the FMS. Opposite to GRECO, COTRAC service will allow new trajectory contracts that involve multiple constraints (latitude/longitude, altitude, airspeed, etc.) and will replace GRECO service for equipped A/C Automated Downlink of Airborne Parameter Services Flight Plan Consistency (FLIPCY) DL only FLIPCY service detects inconsistencies between the flight plan used by the ATSU and the one that was activated in the aircraft s Flight Management System (FMS). The FLIPCY service uses a demand ADS contract to retrieve relevant portion of the 2D flight route (a number of waypoints) from the avionics (FMS). Copyright B-VHF Consortium Page: 5-4

29 Flight Path Intent (FLIPINT) DL only FLIPINT service is similar to FLIPCY, however, it returns a more comprehensive set of data items (enhanced 4D trajectories, aircraft state, additional data) and is based on the ground-initiated event- or periodic update ADS contract. The trajectory predicted by the FMS is downlinked each time a set of criteria defined in the contract request is met System Access Parameters (SAP) SAP service enhances ground surveillance by making specific, tactical flight information (instantaneous indicated heading, air speed, vertical rate, and wind vector) available to the controller or ground automation by extracting/downlinking the relevant data obtained from the airborne system. The SAP Service can be periodic or event driven and is available during all phases of flight Flight Information Services (FIS) NOTE: FIS delivery can be implemented through local broadcast, addressable point-topoint ground/air communications or both Data Link Operational Terminal Information Service (D-OTIS) The D-OTIS service supports pilot s decision making process by providing compiled meteorological and operational flight information derived from ATIS, METARs, NOTAMs, SNOWTAMs and PIREPs specifically relevant to the departure, approach and landing phases of flight Data Link Runway Visual Range (D-RVR) The D-RVR service can be used by the flight crew at any time to request and get up-todate RVR information related to any airport s runway(s) Data Link Operational En Route Information Service (D-ORIS) The D-ORIS service provides flight crews with compiled meteorological and operational flight information, derived from en-route weather information, from NOTAMs, as well as from other sources. The information is specifically relevant to an area to be over-flown by the aircraft or any area of interest in the en-route domain Data Link Significant Meteorological Information (D-SIGMET) The D-SIGMET service advises Flight Crews of the occurrence or expected occurrence of weather phenomena that may affect the aircraft safety. SIGMET information messages are distributed to aircraft in flight - on ground initiative - through associated ATS units Data Link Automatic Terminal Information Service (D-ATIS) D-ATIS provides terminal information (weather, active runways, approach information, NOTAM information) relevant to a specified airport(s) by using data link. This service is available during any phase of flight Data Link Flight Updates Service (D-FLUP) The D-FLUP Service provides all ATM-related operational data and information (e.g. information related to the departure sequence, CDM agreements, de-icing, slot-time Copyright B-VHF Consortium Page: 5-5

30 allocations, as well as to airborne target approach times) aimed at the optimization of the flight preparation supporting punctual departure Traffic and Surveillance Services Automatic Dependent Surveillance Contract (ADS) Unlike ADS-B, ADS (Contract) service downlinks aircraft position reports to an ATSU based on a contract (on-demand, periodic and event-triggered). Parallel contracts to several ATSUs are supported. The service is also used as a carrier for some other services (e.g. FLIPCY) Automatic Dependent Surveillance Broadcast (ADS-B) With ADS-B, an aircraft or a surface vehicle operating within the surface movement area periodically broadcasts (reports) its state vector (horizontal and vertical position, horizontal and vertical velocity) and other information. The broadcasted information can be received by other equipped users within range and used for different air-to-air and air-to-ground surveillance tasks. These include [CASCADE_S] but are not limited to:! ADS B NRA (ATC Surveillance in non-radar area) service, providing basic ATC surveillance in en-route and terminal phases of flight in airspaces where radar surveillance does not exist. The main objective is to enhance controller s traffic situational awareness (by providing accurate traffic position) in a cost effective way, providing benefits in terms of capacity, efficiency and safety.! ADS B RAD (ATC Surveillance for radar areas) service, comprising ADS-B TMA and ADS-B ACC sub-services, designed to enhance existing ATC surveillance in en-route and terminal phases of flight. The objectives are to improve safety and, on a longer term, to reduce surveillance infrastructure related costs by replacing some of the SSR radar sensors with ADS B.! ADS B APT (Airport surface surveillance) service, providing ATC for ground movement control (aircraft and airport vehicles). The main objective is to enhance safety and efficiency on the ground in darkness and low visibility conditions.! ADS B ADD (Aircraft derived data) service that will automatically provide additional aircraft data to ground systems and controllers through the means of ADS B. The objective is to enhance the performance of the ground applications (e.g. MTCD, AMAN, etc).! ATSA SURF (Enhanced traffic situational awareness on the airport surface) service, enhancing traffic situational awareness of flight crews by providing information about surrounding traffic during taxi and runway operations. The objectives are to improve safety (e.g. at taxiways crossings, before entering an active runway, before take-off, etc) and to reduce taxi time in particular during low visibility conditions and by night.! ATSA AIRB (Enhanced traffic situational awareness during flight operations) service, enhancing the traffic situational awareness of flight crews during flight by displaying surrounding traffic position in the cockpit. The objectives are to improve traffic awareness and safety of flight in all airspace.! ATSA VSA (Enhanced visual separation on approach) service, comprising ATSA- S&A (See and Avoid) and ATSA-SVA (Successive Visual Approaches) sub-services that will display the surrounding traffic position and speed in the cockpit. The main Copyright B-VHF Consortium Page: 5-6

31 objective is to facilitate successive approaches for aircraft cleared to maintain visual separation from another aircraft on the approach.! ASPA S&M (Enhanced sequencing and merging) service that will allow pilots to identify another aircraft and to maintain an instructed spacing with that flight. The main objective is to assure more consistent aircraft spacing, potentially increasing capacity in en-route and TMA environments by transferring the spacing task from the ATSU to the cockpit Traffic Information Service Broadcast (TIS-B) TIS-B service allows for broadcasting sensor-based traffic information and/or rebroadcasting ADS-B information in some areas and for some users (such as GA), in particular where mixed equipage is possible. Traffic information is displayed on an aircraft display. TIS-B update rates may be less frequent than ADS-B update rates, some surveillance services, such as ATSA AIRB, which do not rely on high update/transmission rates, could be implemented through TIS-B Emergency and Ancillary Services Urgent Contact Service (URCO) The Urgent Contact (URCO) service provides assistance for establishing urgent contact (via voice or data link) with flight crew that may or may not be under the control of ATSU imitating the service Data Link Alert (D-ALERT) DL only The objective of the D-ALERT service is to enable flight crews to notify, by data link, appropriate ground authorities when the aircraft is in a state of emergency or abnormal situation (with or without declaring emergency). The objective is to enable the transmission of more accurate, precise and complete data regarding the concerned aircraft, in a fast and reliable way, through data link, to interested parties. The D-ALERT information will be disseminated to ATC and appropriate Airport Authorities (e.g. fire and rescue, medical services, etc.) Communications Management Services Data Link Logon (DLL) DL only DLL service encompasses data link (logon and contact) exchanges between an aircraft and ATSU that are required to enable other data link services. DLL service takes place automatically (without direct flight crew involvement) after the crew has activated the data link system ATC Communication Management (ACM) When a flight is about to be transferred from one sector/atsu to another, the flight crew is instructed to change to the voice channel to that of the next sector/atsu. The ACM service comprises air/ground exchanges between an aircraft and its transferring ATSU (T- ATSU) and receiving ATSU (R-ATSU) that aim to establish and maintain voice and data link communications for the control of the flight. Copyright B-VHF Consortium Page: 5-7

32 5.4. AOC Operational Services AOC Voice Services This class comprises all kinds of legacy AOC voice communications (OPC channels) AOC Data Services NOTE: AOC DL services with required global coverage and automatic procedures cannot easily be substituted by AOC voice communications. AOC data services are very airline specific and tailored to the individual needs of an airline. The following is a short list of applications which tend to be common among all AOC data link users Out Off On In (OOOI) This service is an automatic one-way downlink from the aircraft to the AOC Movement Control System, aiming to report significant points in the flight s progress: OUT (off block), (take-) OFF, ON (landing), IN (block) NOTAM Request/NOTAMs NOTAM service delivers Automatic Terminal Information Service (ATIS) that includes any immediate NOTAMs available. This service is activated manually by the flight crew from a menu list displayed on the cockpit Control and Display Unit (CDU) Free Text Free Text service includes miscellaneous uplinks and downlinks via textual messages between the cockpit and AOC/other ground based units. Free text can also be used to append standard pre-formatted downlink response messages such as in Oceanic Clearances Weather Request/Weather Report Weather Request service includes flight crew requests for airport weather. Weather reports include Meteorological Aerodrome Reports (METARs) and Terminal Area Forecasts (TAFs) which are provided via downlink messages. The AOC Flight Planning System replies by delivering the requested weather information to the cockpit Position Report Position Report service includes automatic downlink of aircraft position during the climb, cruise and descent portions of the flight. The primary purpose is delivery of position reports at required waypoints for use in AOC tracking systems. During all phases of flight, but principally en route, the aircrew can also manually initiate the Position Report service Flight Status The Flight Status service includes, for example, malfunction reports to maintenance including fault reporting codes that allows maintenance and spares to be pre-positioned at plane side after landing. Fault reporting can be done manually, or the reports can be automatically sent when triggered by an event. Copyright B-VHF Consortium Page: 5-8

33 Fuel Status Fuel Status service downlinks fuel state en-route and prior to landing. This service allows ground services to dispatch refuelling capability promptly after landing. The aircrew also reports the fuel status upon specific AOC request Gate and Connecting Flight Status This is an AOC service directed to passengers and includes manual and automatic uplink of connecting flights, ETD, and gate before landing. Information about rebooking may also be included in case of late arrival or cancelled flights Engine Performance Reports Aircraft Condition Monitoring System (engine and systems) reports are downlinked automatically and on request. This is usually done in all phases of flight Maintenance Troubleshooting Through this service, maintenance personnel and aircrew are able to discuss and correct technical problems while the aircraft is still airborne. Although voice is customarily used for the discussion, this service may be used to provide the instructions for problem resolution in a textual format Flight Plan Request/Flight Plan Data This service provides the operators with the ability to request and receive the AOCdeveloped flight plan for comparison to that assigned by ATC and for loading into avionics (FMS). AOC flight plans contain more information than flight plans filed with ATS Load Sheet Request/Load Sheet Transfer Upon downlink request, the Load Sheet Control System uplinks planned load sheet and cargo documentation. Prior to departure, the final load sheet, including actual weight and balance data is automatically uplinked to the cockpit while the aircraft is at the gate or while waiting for takeoff. The minimum equipment list (MEL) can also be confirmed at this time Flight Log Transfer This service for the aircrew delivers next flight assignment, estimated time of departure, and gate information. Flight log information may be manually requested by the flight crew or automatically uplinked Real Time Maintenance Information This service allows aircraft parameters to be sent to the airline maintenance base in realtime to monitor the operational status of the aircraft. Information could include engine data, airframe systems, etc. This service allows information to be obtained more quickly than the normal maintenance-data acquisition via on-board recorders. It is typically event driven, triggering a flow of information until resolution is achieved Graphical Weather Information Weather information is sent to the aircraft in a form that is suitable for displaying graphically on displays in the cockpit, e.g., vector graphics. This service supplements or Copyright B-VHF Consortium Page: 5-9

34 replaces the textual weather information available in current AOC services. Graphical weather information is expected to be more strategic in nature, and will supplement onboard tactical weather radar which has inherent range and display limitations Online Technical Trouble Shooting This service allows airline ground maintenance staff to request information from on-board systems so that a diagnosis of problems can be undertaken at locations away from the aircraft s base Real-Time Weather Reports for Met Office Information derived by the aircraft on the environment in which it is flying (e.g., wind speed and direction, temperature) can be sent automatically in real-time to weather forecasting agencies to help improve predictions Technical Log Book Update This service allows the flight crew to complete the aircraft s technical log electronically and send the updated log to the maintenance base. Information regarding the technical status of the aircraft can therefore be obtained much quicker hence any remedial action can be taken at an early stage Cabin Log Book Transfer This service allows the cabin crew to complete the aircraft s cabin-equipment log electronically and send the updated log to the AOC. Information regarding the status of the cabin equipment can therefore be obtained much quicker hence any remedial action can be taken at an early stage Update Electronic Library The Electronic Library will replace many of the paper documents currently required to be carried in the cockpit (e.g., Aircraft Manual and AICs). Invoking this service causes that electronic information becomes automatically updated. The transmitted information will be used to update various avionic systems, e.g., an Electronic Flight Bag (EFB) device Software Loading This service allows new versions of software to be uploaded to non-safety related aircraft systems Classification of Operational Communications Services Operational communications services- including voice and data link services - can further be grouped [MACONDO_S] into Classes of Service (CoS). The classification has been performed as an aggregation of the requirements of known and emerging operational communications services. Each CoS class captures operational communications services with similar common purpose, mode of operation, communications topology and QoS requirements. In [B-VHF D5], these CoS classes have been used for the definition of the requirements for the B-VHF system. It has been assumed that defined CoS classes can accommodate any new (not yet known) ATS or AOC operational communications service that may be developed until the year 2025 and beyond. Copyright B-VHF Consortium Page: 5-10

35 The classification has yielded six voice- and eleven data link Classes of Service : 1. CoS v1-1 Controller-Pilot Party Line Service- Voice Tactical Exchanges 2. CoS v1-2 Controller-Pilot Party Line Service- Voice Full-system DL Backup 3. CoS v2 Controller-Pilot Selective Voice Service - Selective Aircraft Backup 4. CoS v3 Pilot-Pilot Voice Service 5. CoS v4 Broadcast Service 6. CoS v5 Interactive Voice Service As [MACONDO_S] does not cover AOC voice services, seventh generic voice service class has been defined specifically for the purposes of the B-VHF project: 7. CoS v-aoc Voice AOC services With respect to the data link services, [MACONDO_S] provides 14 classes of service: 1. CoS D1-1 Pilot-Controller Emergency Dialog 2. CoS D1-2 Pilot-Controller Tactical Dialog 3. CoS D1-3 Pilot-Controller Strategic Dialog 4. CoS D1-4 Pilot-Controller Information Dialog 5. CoS D2 Pilot-Pilot Dialog 6. CoS D3-1 Medium Flight Information Exchanges 7. CoS D3-2 Large Flight Information Exchanges 8. CoS D4-1 ATM Tactical Exchanges 9. CoS D4-2 ATM Strategic Exchanges 10. CoS D5-1 Downlink of Tactical Aircraft Data 11. CoS D5-2 Downlink of Strategic Aircraft Data 12. CoS D6-1 Ground to Air Surveillance Broadcast 13. CoS D6-2 Air Surveillance Broadcast As [MACONDO_S] does not cover AOC data link services, another AOC-specific data service class has been defined for the purposes of the B-VHF project: 14. CoS D-AOC AOC Data Link END OF SECTION Copyright B-VHF Consortium Page: 5-11

36 6. B-VHF Functional Principles and System Architecture This chapter is based on [B-VHF D6], [B-VHF D11], [B-VHF D19] and [B-VHF D20], as well as on the information gained from several workshops dedicated to the detailed B-VHF system design. It contains selected information required for understanding the overall B-VHF system concept of operation. This information is based on the current status of the B-VHF project and does not preclude further design modifications, dependent on the outcome of an ongoing detailed system analysis. The preferred way of operation of the B-VHF system is based on an overlay deployment concept. This chapter describes basic principles of the selected system approach, provides a short overview of B-VHF protocols, system architecture and internal mechanisms that effectively enable B-VHF communications services. These services themselves are described in the Chapter 7 of this document B-VHF Functional Principles Introduction to B-VHF B-VHF is a terrestrial broadband VHF integrated voice/data link cellular system based on multi-carrier techniques and CDMA Terrestrial System The B-VHF system concept is based on a centralized net system with the ground station acting as the network controller which controls the network configuration, network timing, net entry and exit, and user access for voice and data communications. A possible future extension (not planned to be done within the current B-VHF project) is the operation without a ground station, where one special master A/C would provide functions currently provided by the terrestrial B-VHF GS. It would allow the B-VHF system to be operated in the B-VHF mode in areas without ground infrastructure (B-VHF avionics would anyway comprise multi-mode radios capable of operating in the DSB-AM mode in such geographical areas) Broadband System The B-VHF system uses a number of broadband radio channels to provide its services. The exact channel bandwidth has not been defined yet, current working hypotheses are 1 MHz and 500 khz RF bandwidth. The ongoing B-VHF work relies upon the fact, that the main system parameters can be defined independently of the selection of the channel bandwidth. The preferred spectrum range for the B-VHF system is VHF COM band ( MHz), however the system design allows for the implementation in other aeronautical bands as well, up to and including the DME band Integrated System The B-VHF integrated system has been designed to provide simultaneous support for almost all known classes of safety-related communications services, including all kinds of ATS, general ATM and AOC voice and data link communications. Copyright B-VHF Consortium Page: 6-1

37 B-VHF is a full-duplex system based on Time-Division Duplex (TDD). It supports point-topoint (PP) voice and data A/G communications between an A/C and the GS where the GS uses specific implicit/explicit discrete aircraft addresses. The system is also capable of supporting unidirectional unacknowledged (GS to A/C) voice/data broadcast/multicast (BC/MC) services. NOTE: Voice party-line functionality within the B-VHF project will be realized as a rebroadcast on a specific communication transport channel dedicated to a given user group. Each such group corresponds to a single ATC sector, an AOC voice channel or ATS function. NOTE: Full-duplex voice operation of a B-VHF system is perceived as a major improvement by the participating airline. All aircraft Reverse Link (RL) transmissions are always PP, directed to the single controlling GS. An airborne user can directly exchange air-ground voice and data traffic only with the GS that currently controls that particular user. In cases where an airborne user effectively communicates with another airborne user, the B-VHF GS acts as a relay, re-transmitting aircraft RL transmissions on the Forward Link (FL) so that they can be received by other A/C within the cell. The relay mode is used for implementing the partyline feature of the legacy DSB-AM voice system, but also for all other types of communications that would normally require direct air-air connectivity Cellular System Airport services are currently typically provided [B-VHF D8] within 25 nm from an airport, the coverage for terminal services is approximately 60 nm, while en-route coverage may even exceed 175 nm. B-VHF is a cellular system oriented towards new operational concepts, e.g. the concept of dynamic airspace usage. B-VHF cells will generally provide similar operational coverage as existing VHF Airport, TMA and En-route GSs. Each cell operates from a single location on its dedicated RF frequency (uses its dedicated broadband RF channel) and is capable of providing to airborne users multiple voice and data services that were previously provided by using a number of narrowband VHF channels. One B-VHF cell may provide voice circuits for several ATC sectors while simultaneously providing data link services to A/C without being affected by the sector boundaries. In most cases it will be possible to use existing GS infrastructure with the B-VHF system. However, new B-VHF GSs may be deployed as well, dependent on the required operational service coverage. Wide-area voice and data link B-VHF coverage is realised by implementing ( cloning ) a given voice or data service at an appropriate number of cells. When an A/C is about to cross the cell boundary, a handover procedure must be executed, as the new cell uses another broadband RF channel. Opposite to the inter-sector handovers that still remain human-controlled, the seamless handover between cells involved with the provision of the wide-area service is a B-VHF system-internal issue. It is transparent to the airborne user and fast enough not to cause any disruption of ongoing voice and data services. This removes a need to implement traditional wide-area coverage mechanisms like CLIMAX. Large B-VHF cells are still required, e.g. for off-shore En-route ATC sectors. Copyright B-VHF Consortium Page: 6-2

38 Multi-carrier System The B-VHF system uses in FL direction Orthogonal Frequency Division Multiplexing (OFDM). With OFDM, user s data are transmitted over several so-called sub-carriers scattered within the broadband RF channel, instead of using a single carrier. These subcarriers are orthogonal to each other and therefore cause no Inter-Carrier Interference (ICI). The main advantage of the B-VHF system is that it can use non-contiguous groups of sub-carriers. This in turn allows to intentionally exclude (not use) known narrowband channels operating within the VHF range and opens a way for the B-VHF overlay deployment concept. The overlay concept assumes that, dependent on the current position of the B-VHF receiver, only a fraction of all narrowband VHF channels those being used close to the victim B-VHF receiver - will be received as real interference, while the rest coming from distant sources will fall below the receiver noise floor. Assuming that the B-VHF receiver is robust enough to cope with the remaining interference, the transmitting B-VHF system may locally re-use distant narrowband channels for its own transmissions. As the B-VHF transmitter power density is restricted to a specified limit (sufficient to achieve desired B-VHF coverage), interference-free operation of victim narrowband receivers located outside of some minimum distance around the B-VHF transmitter can be guaranteed. With an overlay concept, dependent on the current location of the B-VHF radio within the cell, only a percentage of all NB channels lying within the B-VHF RF bandwidth are effectively available for re-use within the B-VHF system. Detailed constellation of available channels will vary within the cell. The number of carriers available to an airborne B-VHF station varies (decreases) with the increasing Flight Level. NOTE: Location- dependent resource allocation would offer the possibility to use for RL transmissions on lower flight levels or on the ground additional OFDM sub carriers that cannot be used on higher flight levels, thus increasing system capacity. However, it obviously introduces additional complexity due to the need to update the specific configuration information about available RL resources as an A/C moves within the cell. Within the ongoing B-VHF project exactly the same set of sub-carriers has been considered to be available on FL and RL within entire B-VHF cell, independent on the A/C current location within the cell. This option is restrictive with respect to the achievable system capacity, but significantly simplifies the handling of resources - OFDM subcarriers within the B-VHF cell (an A/C gets its RL resources during the entry into the B- VHF cell assigned and regards the same set of carriers as available within an entire cell). The location-oriented resource allocation within a cell remains possible, but has been delegated to a follow-on project. The detailed configuration of the available sub-carriers becomes an attribute of each B-VHF cell (it must be exactly known to the B-VHF ground station and communicated to the A/C entering the corresponding cell). This configuration is obtained for each GS by applying B-VHF frequency planning criteria and detailed worst-case analysis of the GS local environment (constellation of narrowband VHF channels and service volumes within some distance from the GS). In RL, different voice or data link services provided to airborne users are separated by OFDMA. Optionally, with sufficient RL resources CDM spreading can be applied, in order to increase system robustness. Two ATC sectors or two A/C using data link e.g. use on RL disjoint sets of OFDMA carriers, so the A/C RL transmissions coming from different sectors/users do not overlap and can easily be distinguished by the B-VHF GS. Copyright B-VHF Consortium Page: 6-3

39 CDMA System CDMA is a multiple-user access technique that is applied on top of available OFDM subcarriers and used for B VHF system FL. In an MC-CDMA system the information of several users is spread (by applying Code Division Multiple Access - CDMA) over several common OFDM sub-carriers that have been selected from the pool of locally available sub-carriers. Even if one of these FL sub-carriers is faded or dynamically jammed, it is in most cases possible to recover the information received through other sub-carriers (diversity) B-VHF Time Structure The B-VHF system is a full-duplex system, using Time-Division Duplex (TDD) for voice and data transmissions between the ground station and the mobile stations (aircraft). The B-VHF time-frame structure is shown in Figure 6-1. SF1 SF2 SF3 SF4 SF5 SF6 SF7 SF8 Hyper-frame, 1920 ms BC MF1 MF2 MF3 MF4 Super-frame, 240 ms FL RA RL FL sra1 sra2 RL Multi-frame, ~54 ms Odd-numbered multi-frame Even-numbered multi-frame BC BC-slot, ~24 ms Figure 6-1: Time-frame structure Hyper-frames are the largest units in the B-VHF time structure. Hyper-frames have been introduced to allow for more flexibility when scheduling/allocating scarce resources to the users. Each hyper-frame (HF) is 1920 ms long and consists of 8 super-frames (SFs). Each B-VHF super-frame is 240 ms long and consists of 4 multi-frames (MF), each being about 54 ms long. Additionally, a Broadcast (BC) slot (~24 ms) appears at the beginning of each SF. It carries FL broadcast transport channel 1 (BCH) with information broadcasted by the GS necessary for net-entry and handover. Each B-VHF multi-frame consists of three time slots separated in time from each other:! Forward Link slot (FL) appears in each multi-frame and may contain different types of FL transport channels (FCH, UFCH, SFCH). 1 B-VHF transport channels (BCH, RACH, srach, FCH, UFCH, SFCH) are described later on. Copyright B-VHF Consortium Page: 6-4

40 ! Random Access (RA) slot in odd numbered multi-frames carries an unsynchronised random access channel (RACH), in even numbered multi-frames it carries two synchronised random access channels (srach). Random access channels are used for the RL transmission of net entry requests, resource request messages and other system messages.! Reverse Link slot (RL) appears in each multi-frame and may contain different types of RL transport channels (FCH, UFCH, SFCH) B-VHF Protocols The B-VHF data system basically covers the three lowest layers of the ISO-OSI model (Physical Layer PHY, Data Link Layer DLL, Sub-network Layer SN). Very simplified diagram of the B-VHF protocol stack (applicable to both B-VHF GS and an airborne unit) is shown in Figure 6-2. SN Layer Data SN Functions Voice Unit LME DLS DLL Layer BSS MAC-B MAC-S MAC-D MAC-V PMU PHY Layer PBTCH PRTCH PDTCH PDTCH Figure 6-2: B-VHF Protocol Stack By this model, B-VHF voice services share the underlying Physical Layer services with the data services and internal system services. The roles and functions of different B-VHF protocol layers, sub-layers, functions and entities within each (sub-) layer are described in the following sections. Copyright B-VHF Consortium Page: 6-5

41 Physical Layer (PHY) The multi-carrier PHY layer of the B-VHF system is based on OFDM, but has different characteristics in the Forward Link and Reverse Link directions. The basic OFDM principle is to split a serial high-rate data stream into a number of parallel lower rate streams that are transmitted simultaneously over a number of N c sub-channels. Each of these sub-streams is modulated on one of the Nc sub-carriers. In practice, OFDM sub-carriers are not modulated individually, instead they are modulated by applying the Inverse Fast Fourier Transform (IFFT) and using just one RF carrier frequency f c. Transmitting B-VHF GS (FL) always uses all OFDM carriers that are available within that cell. An A/C considers exactly the same set of available FL carriers to be available on RL. In FL, CDMA is applied on top of OFDM, leading to the MC-CDMA. While in a pure OFDM transmission each data symbol is transmitted on an individual sub-carrier, the data symbol in an MC-CDMA transmission is distributed i.e. spread, over several sub-carriers. Since now one data symbol occupies more than one sub-carrier, the data throughput rate of the physical link would decrease. This is circumvented by spreading several data symbols over the same group of sub-carriers. MC-CDMA with the M&Q-Modification provides additional flexibility. With the M-modification, for each user, M symbols are transmitted in parallel over N c carriers. The number of required carriers in this case is N c =ML and an additional OFDM component is introduced into the MC-CDMA system. Setting the number of sub carriers N c =QL (Q being an integer) enables the so-called Q-modification where different groups of users use different sets of sub-carriers. Thus, an additional FDMA component is introduced into the transmission system. If adequate frequency interleaving is applied prior to the OFDM encoding, short spreading sequence lengths of L=4, 8, or 16 can achieve a large diversity gain. Combining the M- and the Q-modification results in the M&Q-modification for which N c =MQL is valid. The MC-CDMA with M&Q modification provides basic building blocks for the B-VHF FL, because M&Q groups can be allocated in a very flexible way. In particular, short spreading codes can be re-used in different M&Q groups. NOTE: According to the current B-VHF system design, CDMA does not apply to the FL broadcast transmissions in the BC slot. OFDMA has been selected as a multiple-access solution for the B-VHF RL. Only in the case of unsynchronised random access via RACH or srach channels all available OFDMA carriers are used, in all other cases different users/services are assigned different nonoverlapping RL sub-carrier groups (user /service discrimination is done by FDMA). NOTE: An OFDMA option is also possible for RL synchronised access (via srach channel). Its feasibility and performance when compared with the baseline without OFDMA user separation will be investigated within the project. OFDMA separation allows for multiple airborne users to transmit simultaneously, without causing a collision at the GS receiver. Moreover, it is possible that two or more airborne B-VHF radios built in the same A/C transmit towards the same GS without collision, as long as these radios use separated OFDMA carrier groups. NOTE: In order to exploit frequency diversity of the fading channel and increase robustness against narrow-band interference, it is possible to apply CDM on top Copyright B-VHF Consortium Page: 6-6

42 of OFDMA also in RL, i.e. to multiplex data symbols of one user utilizing different spreading codes. As shown in Figure 6-2, B-VHF PHY layer comprises a so called Physical Management Unit (PMU) and provides to the layer above (DLL, in particular to the MAC sub-layer) a set of so called Physical Transport Channels (PTCHs):! Physical Broadcast Transport Channel (PBTCH): Supports the broadcast channel (BCH) which is only available in the FL.! Physical Random access Transport Channel (PRTCH): Supports random access channels (RACH, srach) that are only available in the RL! Physical Data Transport Channel (PDTCH): Conveys five types of B-VHF transport channels, super slow channel (SSCH), slow channel (SCH), fast channel (FCH), super fast channel (SFCH) and ultra fast channel (UFCH). PDTCH is available both in FL and RL. Multiple PDTCHs are simultaneously used for the transmission of user voice, user data or internal B-VHF system data. Within the DLL (MAC sub-layer) there are corresponding MAC entities (MAC-B, MAC-S, multiple instances of MAC-V, MAC-D) that are user of the underlying PTCHs. The A/C PMU acquires and maintains the reference timing from the FL transmissions of the current GS and from other GSs broadcast transmissions in the BC slot. It maintains the relative timing of the current GS to all other GSs and is capable to rapidly adjust this timing during handover when an A/C switches between two GSs. NOTE: Dependent on the maximum designed range for a given B-VHF cell, all RL transmissions of all A/C within that cell must be time-aligned (to several µs), as seen by the controlling GS, as otherwise the received OFDM symbols would overlap. Such an alignment means that the RL transmissions of close A/C must be intentionally delayed to arrive at the GS at the same time as transmissions of a distant A/C at the cell boundary. The PMU is also in charge of measuring the received signal strength, both for the FL transmissions of the controlling GS and broadcast transmissions of other GSs in the BC slot. Another important PMU function is performing the mapping of PTCHs onto detailed constellation of underlying physical resources. Generally, a PTCH can be described by! Spreading code and spreading length L; currently the spreading length is L=4 in the FL, whereas no spreading is applied in the RL! Number M of modulation symbols per OFDM-symbol; normally M=4 is used (FCH), whereas M=8 is used for SFCH and M=16 for UFCH! Used sub-carrier set consisting of M*L OFDM sub-carriers! Modulation type! Code rate (FEC type) This detailed information is, however, kept transparent to the layers above the PHY layer. All available OFDM carriers are enumerated and organised into groups of 16 carriers. Each such group provides capacity for four FCHs, two SFCHs or one UFCH. Fixed agreed rules define the mapping of PDTCHs onto underlying PHY resources. By this way, a given B-VHF service may be selected by selecting the proper PDTCH, without having to take care about the constellation of underlying PHY resources. Copyright B-VHF Consortium Page: 6-7

43 The resources for other on-demand services are invisible to the human users. They are explicitly requested by an A/C or external ground system and allocated by the GS. The detailed constellation of such on-demand PDTCHs can be precisely described within the GS response to the external resource request. Remaining configuration information is maintained by the A/C LME that in turn has obtained this information from the GS LME (e.g. details of mapping of the PTCHs onto abstract voice/data link services visible to the users). The A/C LME also provides parts of the configuration information to the A/C PMU and maintains the configuration information that was received from its local PHY layer (e.g. OFDM carrier constellation, as autonomously detected at the PHY layer via the symbol discovery algorithm), as the LME needs this information for its own purposes. In all cases, the true repository of all B-VHF configuration data is the ground LME (implemented in the Ground Station Controller, GSC), it reports this information to the A/C LME by using system-internal mechanisms. It will be shown later on, that the scope of the information that has to be exchanged between the ground LME and the A/C LME can be significantly reduced by applying fixed a-priori agreed rules. Further important PHY functions within the B-VHF system are acquiring and maintenance of frame synchronisation, timing of particular slots within the frame, OFDM carrier modulation/demodulation, applying/resolving of CDMA codes (FL only), FEC handling (separately for the BSS frame headers and the BSS frame payload), management of OFDM resources (including carrier interleaving to achieve frequency diversity), rapid switchover to another B-VHF channel and/or another PDTCH Data Link Layer (DLL) The B-VHF Data Link Layer consists (Figure 6-2) of the link management entity (LME) and three sub-layers:! Data Link Services (DLS) sub-layer! B-VHF Special Services (BSS) sub-layer! Media Access Control (MAC) sub-layer Within a DLL, the notion of so called communications channels is used. A logical channel is an information stream dedicated to transferring a specific type of information via the radio interface. In B-VHF, logical channels carry the information associated with the LME, DLS or BSS entities. Six types of B-VHF logical channels are defined (BCCH, CCCH, DCCH, LRACH, LsRACH, TCH). A transport channel defines the characteristics how data are transported via the air interface. Generally, logical channels are mapped onto transport channels, with different possible mappings. Six types of B-VHF transport channels exist (BCH, RACH, srach, FCH, SFCH, UFCH, SCH, SSCH). NOTE: FCH can be further TDMA-divided into Slow Transport Channels (SCH) that appear once per SF or Super-Slow Transport Channels (SSCH) that appear once per hyper-frame. Logical DCCH channel is normally mapped onto SSCH transport channel. The SCH and SSCH are allocated and managed by the DLL (LME), as seen by the PHY layer, these channels do not differ from the FCH. Copyright B-VHF Consortium Page: 6-8

44 Finally, MAC entities use so called physical transport channels (PBTCH, PRTCH, PDTCH) that are provided by the PHY layer and carry different kinds of transport channels. The DLL entities act as sources and sinks of information exchanged with their peer entities in the form of control frames and traffic frames. Control DLL frames comprise:! Broadcast Data Frame (BDF), sent by the GS LME to the A/C LME via BCH transport channel and PBTCH physical channel that appears exclusively in the BC slot in each B-VHF super-frame. The entire BDF frame must be transmitted within a single FL BC slot. During background scanning, the characteristics of physical bursts transmitted in the BC slot will be used for synchronisation of A/C to the GS, discovery of available OFDM carriers, power measurements of neighbouring GSs, while the decoded BDF frames will provide information about the GS identity, operating frequency as well as detailed mapping of abstract user s services onto PDTCHs.! Control Data Frame (CTRL), sent by the GS LME to the A/C LME via either a CCCH or FL TCH and an adequate transport channel (SSCH, SCH, FCH, SFCH, UFCH) that is mapped onto the corresponding Fixed FL PDTCH that appears in the FL slot in each multi-frame. Within the addressed Fixed FL PDTCH, CTRL frames will be sent by the GS either to the broadcast address that is monitored by all A/C (in that case only the A/C that recognises its own ICAO address will further process specific information - Net Entry Response - contained within the CTRL frame) or to the A/Cspecific address (Local ID).! Control Data Frame Reverse Link (CTRLRL), containing control information sent by the A/C LME to the GS LME via DCCH logical channel or via reserved TCH resource in RL direction. The DCCH is mapped onto an adequate transport channel (SSCH: transmitted in a RL physical slot once per hyper-frame). The entire CTRLRL transmission must fit into a single RL physical slot.! Random Access Data Frame (RADF), sent by the A/C LME via LRACH logical channel, RACH transport channel and PRTCH physical transport channel, used for Net Entry Requests. RACH channel only exists in reverse link, in RA physical slots in odd-numbered multi-frames. Entire RADF frame must fit into a single RL RA slot.! Channel Request Data Frame (CRDF), containing e.g. Resource Reservation messages, sent by the A/C LME via LsRACH logical channel and srach transport channel that exists only in reverse link, in PRTCH physical channels mapped to RA physical slots in even-numbered multi-frames. CRDF can also be sent via a TCH, if such TCH should exist when needed (was previously allocated). If transmitted in srach, entire CRDF frame must be transmitted within one synchronous RA sub-slot (either in sra1 or in sra2). Traffic DLL frames:! Traffic Data Frame (TDF), mapped onto a traffic channel (TCH) and further onto different transport channels (SSCH, SCH, FCH, SFCH, UFCH), carrying users voice or data as well as system data. The TDF transmission is not limited to the single FL or RL frame and may extend over several FL/RL slots opportunities. TCHs are specified in both the forward and reverse link, several TCHs can be combined through the MAC protocol for one type of service to increase throughput. FCH channel is used for all voice services and data services with high traffic volumes and high QoS requirements and is transmitted in each multi-frame in successive physical FL and RL slots separated by 60 ms. SFCH/UFCH channels are used only Copyright B-VHF Consortium Page: 6-9

45 for system and user data services with very high QoS expectations and are transmitted once in each multi-frame. SCH/SSCH channels apply internal TDMA mechanism via an FCH and are transmitted once per SF (SCH) or once per hyperframe (SSCH), respectively. The complete mapping of B-VHF logical channels, transport channels and physical transport channels to physical slots within the B-VHF super-frame (as seen by an airborne B-VHF system) is shown in Figure 6-3. The arrows indicate flow of information (FL and/or RL direction). Among all PDTCHs one so called Fixed FL PDTCH is of particular importance for the B-VHF system. The B-VHF GS uses this dedicated physical transport channel in a sequential way to selectively address A/C in FL and transmit to it either management frames (e.g. logical CCCH channel) or user data frames. Fixed FL PDTCH channel is instantiated at each B-VHF GS and monitored by all B-VHF radios that are connected to that GS. When monitoring the Fixed FL PDTCH, an A/C radio actually monitors two addresses in parallel, its specific Local ID and another special Local ID (e.g ) that represent the broadcast address for that channel. This broadcast address is e.g. used to provide Net Entry Responses to the A/C entering the B-VHF cell. After a successful Net Entry, the Local ID is used for selective A/C addressing via Fixed FL PDTCH. Dependent on the scope of currently available resources, the GS may allocate for that purpose an FCH, SFCH or UFCH. Moreover, it is optionally possible that several such Fixed FL PDTCHs are allocated (A/C would have to monitor all of them in parallel). As Fixed FL PDTCH is just another TCH, its configuration must be known to the A/C prior to its first usage. During the Net Initialization procedure this information is passed to the A/C in the PBTCH channels, which are transmitted in the BC slots. The same applies to the case where several Fixed FL PDTCH exist. Copyright B-VHF Consortium Page: 6-10

46 Control Channels Traffic Channels Logical Channels BCCH LRACH LsRACH CCCH DCCH TCH Transport Channels BCH RACH srach FCH SCH SSCH SFCH UFCH Physical Transport Channels PBTCH PRTCH PDTCH FL Physical Slots BC RA RL FL RL Figure 6-3: Mapping of B-VHF Channels (Airborne View) Link Management Entity (LME) The B-VHF LME is responsible for establishing, maintaining, and terminating links between an A/C radio and the controlling GS. In the B-VHF context, an A/C LME is considered to take care about A/C connections to multiple GSs. This includes the management of short-living uni-directional connections at the PHY layer (e.g. A/C capability to synchronise to multiple GSs during background scanning or cell handover). Airborne LME is handling the Net Initialisation procedure by applying an appropriate scanning algorithm and forcing the PHY layer PMU to execute required tasks (e.g. frequency switching, frame synchronisation, power measurements). Aircraft LME itself is the direct recipient of the configuration information transmitted by different GSs via PBTCH channels in the BC slots (e.g. local mapping of the PHY resources onto abstract voice/data services). Airborne LME handles the Initial Net Entry/Net Exit procedure by exchanging corresponding messages with the GS LME (Net Entry Request, Net Entry Response). It transmits to the GS LME the information obtained from the local PMU (e.g. results of the power measurements). It also initiates the Forced Handover procedure and supports ground-initiated transparent Seamless Handover between cells (e.g. if B-VHF system is providing voice or data services over wide-areas that cannot be covered by a single B- VHF cell). Copyright B-VHF Consortium Page: 6-11

47 Airborne LME is involved with Resource Allocation procedure for on-demand data link services, as well as with Link Establishment/Link Release procedure for on-demand voice services (including link maintenance). It is responsible for backup scenarios and Recovery procedure from failure scenarios. The most critical potential failure scenario for a B-VHF system is a GS failure. The LME will be in charge of coordinating the scheduled re-entrance of all A/C within the cell and reestablishing all ongoing services. An A/C LME is maintaining A/C timing states:! SS 0 Unsynchronised! SS 1 Synchronised on FL! SS 2 Synchronised on FL and RL The attributes of each synchronisation state will be described later on, when describing the B-VHF internal procedures. In the voice context, the A/C LME handles voice signalling, in particular the status of the party-line voice channel (idle, occupied by the controller, occupied by another pilot) that is currently monitored by the aircrew. In the ATN context the LME is responsible for informing the sub-network layer about connectivity changes (it reports to the sub-network layer if an A/C enters or leaves the B-VHF cell). This information is in turn used by the sub-network layer to issue Join Event and Leave Event to the ATN Sub Network Dependent Convergence Facility (SNDCF). In order to support required B-VHF communication procedures LME protocol messages are defined which will be exchanged between the peer LMEs of the communication partners (GS LME and A/C LME). Corresponding LME control frames BDF, CTRL, CTRLRL, RADF, and CRDF - will be sent either as system-specific messages or similar to normal user s data traffic through DLS and BSS sub layer. The most important LME messages are:! Broadcast (FL, periodically)! Physical Channel Control (RL, periodically)! Net Entry Request (RL, during net entry procedure)! Net Entry Response (FL, during net entry procedure, responding to Net Entry Request)! Net Entry Complete (RL, during net entry and forced handover)! Net Exit Request (FL/RL, during net exit procedure)! Net Exit Response (RL, during net exit procedure)! Net Exit Complete (FL/RL, closing net exit procedure)! Resource Request (RL, requesting resources for on-demand RL traffic)! Resource Granted (FL, responding to Resource Request)! Link Establishment Request (RL, requesting resources for on-demand voice)! Link Setup (FL, allocating resources for on-demand voice)! Link Establishment Reject (FL, rejecting request for on-demand voice) Copyright B-VHF Consortium Page: 6-12

48 ! Link Setup Complete (RL, completion of allocation procedure)! Handover Command (FL, GS indicates the handover time)! Handover Access (RL, A/C contacts another cell)! Disconnect Request (RL, for air-initiated disconnect of on-demand voice)! Disconnect Command (FL, for ground initiated disconnect of on-demand voice)! Disconnect Completed (RL, confirming disconnection of on-demand voice) The purpose of each message will be described later on, when describing the B-VHF internal procedures Data Link Services (DLS) Sub-layer B-VHF DLS sub-layer provides a data transfer service for the transport of acknowledged or non-acknowledged data frames between two communications systems. The basic services provided are connection-oriented or connection-less and acknowledged or unacknowledged. Connection-less acknowledged bi-directional binary data transfer is required e.g. by ATN, connection-less unacknowledged uni-directional data transfer is required for FL data broadcast and some addressed RL data services. The B-VHF system optionally offers the opportunity to use connection-oriented data transfer. The B-VHF Data Link Service (DLS) sub-layer is responsible for:! DLS Frame error detection (by means of CRC)! DLS Frame error correction (by means of retransmission request)! Calculation of Cyclic Redundancy Check (CRC)! Adding DLS Header! Bit stuffing and setting delimiters DLS sub-layer is not involved with B-VHF voice transfer, except for the support of a connection-oriented resource allocation procedure for on-demand voice services (Link Establishment/Release). Different types of DLS frames are used to transfer different kinds of data within the B-VHF system. Information (I) frames carry the actual data, supervisory (S) frames are used for error and flow control, while unnumbered (U) frames are used for link management. DLS frames are secured by means of a CRC checksum. Calculation and evaluation of the CRC will be performed by the DLS. In case of a wrong CRC the backward error correction function will trigger the re-transmission of a damaged DLS frame. The backward error correction uses a protocol, which is similar to HDLC. The DLS header is added by the transmitting unit and is evaluated at the receiving DLS sub-layer. Additionally, delimiters and bit stuffing shall be performed at DLS. The maximum size of a DLS frame and the size of the DLS frame header are to be defined yet.. The DLS Header consists of an address field, a control field, and a type of service class field. NOTE: The sub-network layer shall take care that the maximum DLS frame size is not exceeded. Copyright B-VHF Consortium Page: 6-13

49 The address field contains the address of the DLS frame recipient. The control field indicates the type of command or responses, and contains sequence numbers, where appropriate. The type of service class (TOSC) field is related to dedicated resources (fixed or reserved resources). Each TOSC represents within the B-VHF system external applications with similar requirements upon the DLL functionality (e.g. similar acknowledgement requirements, data rate, etc.). The TOSC attribute will be used to determine the priority level of a DLS frame to be transmitted B-VHF Special Services (BSS) Sub-layer The BSS sub-layer provides a flexible approach to allow maintaining high system throughput, low probability of collision (in case of random access protocols) and low transit delays. The BSS sub-layer provides the following services:! Adjusting incoming (DLS) data frames to the PHY burst capacity! Re-assembling incoming (PHY) data to DLS frames! Indicating resource needs to LME! Priority scheduling The BSS and the DLS are connected via logical channels (TCHs). Via this connection DLS frames are passed to the BSS which then submits the BSS frames to the local MAC layer via different types of transport channels (SSCH, SCH, FCH, SFCH, UFCH). Transport channels can occur up to n-times and are characterized through different data rates. All transport channels originating from the BSS are directly connected to the MAC-D entity, except for control channels RACH and srach that are connected to the MAC-S entity. BSS sub-layer is not involved with B-VHF voice transfer, except for the support of a connection-oriented resource allocation procedure for on-demand voice services (Link Establishment/Release). The BSS sub-layer will co-ordinate the priorities between different data applications (optionally, this may include requests for on-demand voice applications) and schedule outgoing BSS frames, dependent on the actual available resources. The DLS always passes a complete DLS frame to the BSS sub-layer. If multiple DLS frames are simultaneously passed to the BSS, they are buffered in a priority queue, according to the priority of each DLS frame. Before transmission, possibly long DLS data frames are split by the underlying BSS sublayer into smaller units - BSS frames, each such frame having its specific BSS header. BSS frames may have different sizes, as they should match (generally variable) the capacity provided by different PHY layer Transfer Units (these define the amount of external data that fit into single PHY burst transmitted at an appropriate slot within the B-VHF frame structure). Dependent on the DLS frame type, the payload of each BSS frame is secured (at the Physical Layer) by an adequate forward error correction code (FEC) that is specified by the DLS (Type Of Service - to be inserted in the TOS field of the BSS header). As FEC alone may not be sufficient in all situations, the DLS will additionally protect the outgoing DLS frames with a cyclic redundancy code (CRC). The B-VHF system distinguishes three different types of BSS frames:! Data Frame (D frame), used for data transfer Copyright B-VHF Consortium Page: 6-14

50 ! Voice Frame (V frame), used for voice traffic! Management Frame (M frame), used for exchange of management data NOTE: BSS V-frames have been defined only formally. Voice traffic does not really use the BSS layer services, but will use similar header format as the BSS frames. The BSS selects the proper transport channel for data coming from the upper layers and entities (DLS, LME) and is also responsible for transfer scheduling. At the receiver side, the BSS frames will be re-combined into a DLS frame and each DLS frame can be checked for data integrity as a result of CRC. Dependent on the outcome of the CRC check the re-transmission of entire DLS frame may be required by the receiving DLS entity Medium Access Control (MAC) Sub-layer The B-VHF Medium Access Control (MAC) sub-layer provides access to the Physical Layer by an appropriate algorithm under control of the DLL. The MAC sub-layer is responsible for mapping the BSS data frames to the correct physical frame. Separate MAC entities handle different kinds of exchanges. MAC-V entity is dedicated to voice services, MAC-D handles both user s data and system data when transmitted via normal transport channels, MAC-B entity handles uni-directional FL broadcast of system data, while MAC-S entity deals with RL transmissions in RA channels (RACH, srach). BSS frames received from the BSS sub-layer are addressed towards the proper MAC entity. These frames already have the proper size and are handed over by the corresponding MAC entity to the Physical Layer. Similarly, MAC entities forward data packets received via different PHY slots, demodulated and FEC-processed by the PHY layer, to the next higher layer (BSS), including their time of arrival. Dependent on the type of the voice/data service, B-VHF system provides three different kinds of access methods to the transmission channel:! Fixed Access, where reserved (permanent) transport channel exists at the PHY layer for a considered service within a given B-VHF cell. Examples of such services comprise party-line or broadcast voice channels, but also system-internal channels like DCCH. NOTE: The PTT access algorithm - under human control will in all cases be used for B-VHF voice communications, in both directions (forward and reverse link). Therefore, B-VHF MAC sub-layer is not directly involved with the user s access to the voice channel, but is well involved during the resource allocation procedure for on-demand voice services.! Reserved Access, where transport channel is allocated by the GS following an explicit request (coming from an A/C or from a ground user). The GS BSS sub-layer is responsible for merging such requests and managing resources for all A/C within its range, each A/C manages the usage of currently allocated resources for its own user data. After the data transfer has been finished, previously allocated resources are withdrawn by the GS and can be re-used for another user/service.! Random Access, where all A/C may access B-VHF RL in an uncoordinated way, with possible collisions. Within the B-VHF system, random access is basically only needed until reserved access is granted by the GS. There are 2 different types of Random Access: Copyright B-VHF Consortium Page: 6-15

51 ! Unsynchronised Random Access, where an A/C is not yet synchronised with the GS on RL, so only one A/C can transmit in the RA slot in order to prevent collisions at the GS receiver! Synchronised Random Access, where an A/C has already received its timing advance information from the GS, thus two A/C can simultaneously transmit towards the GS in two separate sub-slots (sra1, sra2). Unsynchronised random access (via RACH) is used for net entry, while synchronised random access (via srach) is used for resource requests, management messages and user s emergency messages Sub-network Layer (SN) NOTE: Within the B-VHF project, only rough guidelines for the development of B-VHF Layer 3 will be provided. There will be no specification concerning detailed protocol design on this layer, but the interface to the DLL will be kept similar to that provided by the VDL Modes specified by ICAO B-VHF Mechanisms and Procedures The integrated B-VHF system has its specific configuration requirements. This is particularly true under overlay conditions where only parts of the broadband RF channel are available to the B-VHF system, while the remaining part is occupied by legacy narrowband systems. In order to operate without interference to legacy VHF systems, B-VHF transmitter and receiver shall have exactly the same view about the constellation of available OFDM carriers and the way they are used within a given cell. Internal B-VHF mechanisms have been developed that successively reduce the initial uncertainty, providing exactly the information that is required at each particular step between an A/C initial entry into the first B-VHF cell and the exit from the last one. In the following sections, Net Initialisation, Initial Net Entry, Service Selection, Forced Handover, Seamless Handover and Net Exit procedures are described, with particular emphasise on the provision of the configuration information required for the B-VHF operation. These procedures are strongly associated with the A/C internal timing states (SS 0 Unsynchronised, SS 1 Synchronised on FL, SS 2 Synchronised on FL and RL). Further, the Resource Allocation procedure for data link services and Link Establishment/Link Release procedures for on-demand voice and connection oriented data services are described B-VHF System Configuration A full description of the B-VHF system - particularly under overlay conditions - involves many parameters, including the detailed constellation of available OFDM carriers within a given area. The B-VHF GS uses a high-capacity broadband channel to provide multiple services. When the B-VHF system provides a wide-area service, this involves several cells operating on different broadband RF channels. In order to get access to such a service, the B-VHF system user would normally have to specify both the required service AND the GS (RF channel) where this service is available. Services requiring wide-area coverage are today provided from multiple GSs that all operate on the same narrowband channel (e.g. CLIMAX voice stations, VDL Mode 2 Copyright B-VHF Consortium Page: 6-16

52 stations). The pilot just selects the channel associated with the wide-area service without a need to specify the GS that currently provides that service. The preferred B-VHF system approach also avoids the need for the pilot to manually preselect the operating RF frequency (manually specify the B-VHF cell) in case where multiple B-VHF cells have been configured to provide a wide-area service. This approach has been selected as it is transparent to the users (does not change the operational procedures). It is based on an automated Net Initialisation procedure that starts with the scanning of B-VHF RF channels, autonomous detection of active B-VHF GSs that operate within the range of an airborne B-VHF radio, and proceeds with subsequent stepwise provision of remaining configuration information. However, the price for such autonomy is the extended time required for the Net Initialisation. This time could in many cases be significantly reduced if the pilot could (optionally-) enter the broadband B-VHF RF channel identifier prior to the selection of the operational voice/data link service. This option may be well available in all cases where the pilot knows his current position and can unambiguously identify the B-VHF cell that can provide required operational service at that position (e.g. an A/C being on the airport surface). With that option, RF frequencies of multiple GSs providing the wide-area service (e.g. an equivalent to the CLIMAX operation) could be pre-selected by the pilot, based on static data bases (e.g. AIPs). Therefore, it is recommended to consider in the future work the operational impact of the (additional step-) of manual pilot s selection of the B-VHF RF channel prior to the actual operational service selection and, if found acceptable, modify existing procedure in order to optimise the Net Initialisation performance. The basic automated Net Initialisation procedure described in the following has been developed to allow for such an overlay procedure Net Initialisation The procedure of Net Initialization (Figure 6-4) describes the synchronisation status change from SS0 to SS1. The B-VHF radio that was just turned ON at the airport surface or a radio that has suddenly been switched in the B-VHF mode after previously being in DSB-AM mode does not yet know the operating frequencies and other parameters of close B-VHF GSs. Such a radio is initially in the state SS0, not synchronised with the GS (not even aware of the B-VHF GS existence), so it can neither receive nor transmit anything. The B-VHF Net Initialisation concept assumes that an A/C can be within coverage of several B-VHF GSs. Such an A/C shall automatically establish an initial contact to at least one B-VHF GS this GS should in turn provide initial timing and detailed configuration information about itself and (optionally) about all other GSs in the vicinity. In order to detect the first active GS, the radio performs background scanning of BC slots that are regularly transmitted by each B-VHF GS within the B-VHF super-frame. Each GS sends on its own assigned B-VHF RF channel, but all GSs within a region are frame-synchronised up to the sufficient tolerance. Due to the synchronisation of the GSs the BC slots of all active GSs are virtually transmitted at the same time, with at most ± 1,3 ms tolerance as seen by an airborne radio - due to the maximum propagation time difference. Copyright B-VHF Consortium Page: 6-17

53 An A/C radio starts the scanning from the lowest RF channel. It has to tune to the corresponding RF frequency, monitor that frequency and try to acquire the synchronisation with the GS, based on the reception of specific synchronisation symbols within the BC physical burst. The A/C radio has to dwell on the first RF channel for a time that is slightly longer than the SF duration (240 ms), otherwise, the BC slot may have just been passed without having been seen by the scanning A/C. If no active GS was detected on the first RF channel (no synchronisation via BC slot was possible), A/C radio re-tunes to the second RF channel and repeats the procedure. Such blind scanning continues until the first active B-VHF GS has been detected. NOTE: In the worst case, the highest RF channel may be the only active channel within a region, so the blind scanning described above would have to continue until this channel has been detected. When the first active B-VHF GS (GS1) has been detected (implying that synchronisation via BC slot was successful), the frame timing becomes a reference for all subsequent scans. NOTE: If, as previously noted, the pilot were allowed to directly enter the RF frequency of the B-VHF GS, the scanning would in the Net Initialisation phase immediately be suspended and the A/C radio would immediately jump to the proper RF channel, synchronise to the GS and perform the rest of the configuration task, as described below. Nevertheless, continuous scanning is still required for other purposes as long as an A/C remains within the B-VHF system area. Now the A/C radio looks at the BC slot and tries to acquire further information from there. The first important task is to discover these OFDM symbols that are actually used by that GS (the remaining parts of the broadband RF channel may be used by the legacy narrowband systems). Additionally, the radio measures GS received signal power and attempts to decode the content of the broadcast PBTCH channel. The physical burst sent by each GS in the BC slot contains special Subcarrier Discovery Symbols (SDS) which are used for an autonomous detection of the exact OFDM carrier constellation used by that GS for all FL transmissions. The same constellation of OFDM carriers is considered as available to be used for RL transmissions within that cell. NOTE: Alternatively, detailed OFDM carrier availability information for all B-VHF GSs of interest as seen by a given flight could be captured in an airborne data base. Assuming the current A/C position is known, the OFDM carrier constellation and other B-VHF configuration data applicable to that area could be extracted from this data base. Like pilot s RF channel selection, the airborne data base and the connection of an airborne B-VHF system with the navigation system is considered to be a backup option. This approach is not absolutely necessary but, if available, could significantly enhance the basic blind approach. Copyright B-VHF Consortium Page: 6-18

54 GS1 A/C GS2 BCH (periodical): GS power, OFDM constellation, GS ID, PDTCH_IDs for own supported services, List of adjacent GSs (GS_ID, RF channel) Net Initialisation Blind Scanning SS0 SS1 Figure 6-4: Net Initialisation Procedure The Broadcast message sent on PBTCH contains the GS ID as well as the complete system configuration of the corresponding B-VHF cell, in particular the mapping of the abstract identifiers of fixed voice and data link services available at that cell onto physical transport channels and the list of GS IDs and operating frequencies of all other GSs operating in the neighbourhood. The content of the information obtained by scanning the BC slot of a particular B-VHF GS would correspond to a single row in Table 6-1. The table itself is maintained by the A/C LME, but some of its contents (e.g. carrier constellation) are internally communicated to and used by the local PMU. The number of rows corresponds to the number of B-VHF RF channels (as this is required for the worst-case initial blind scanning scenario, where the last RF channel would be the first detected active B-VHF channel), but under typical circumstances the number of relevant rows may be significantly lower than the number of channels, due to the scanning restrictions described in the Initial Net Entry procedure. In Table 6-1, CH denotes the B-VHF RF channel, while ACT denotes the active GS that currently controls an A/C radio (radio is nominally tuned to this GS and can communicate with it between background scans of other GSs BC slots). PWR denotes measured power on the particular RF channel in abstract units, Offset to ACT is timing offset (in parts of an OFDM symbol duration) between the BC frame of the just scanned GS and the BC frame of the controlling ACT GS. OFDM Const. represents the detailed constellation of available OFDM carriers within the broadband RF channel derived from the SDS symbols. CH ACT PWR Offset to ACT OFDM Const. Decoded PBTCH (512-bit word) GS_ID RES_1 RES_2 RES_ N/A N/A N/A N/A N/A 2 X N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Table 6-1: Example of LME Information Obtained via Scanning At the beginning of the scan procedure, no GS is marked as active (no entry in the ACT column exists). When the first GS is detected, it will be marked as active one. The ACT Copyright B-VHF Consortium Page: 6-19

55 marking will change with each inter-cell handover, but remains the same during background scanning. Scanned channels where either no synchronisation with the GS was possible, measured PWR was below a threshold (TBD) or no valid OFDM constellation could be detected via SDS remain marked as N/A in Table 6-1. The rest of the Table 6-1 contains several fields derived independently for each GS from the decoded PBTCH (Figure 6-5). FR_NR is the number of the current super-frame within the hyper-frame, while GS_INFO field contains detailed information about this particular GS. Within the GS_INFO field, the GS_ID sub-field contains the identifier of the currently scanned GS, NN denotes the number of neighbouring GSs for this GS, RES_1 field describes the total number of voice channels provided by that GS and (in tabular form) the mapping of the abstract voice service identifiers ( B-IDs ) to the underlying PDTCHs. The RES_2 field provides exact description of all fixed data channels, while the RES_3 field contains for each GS a list of its neighbouring GSs IDs and their RF channels. This list is used to restrict the scanning, after the first active GS was detected, to just relevant adjacent GSs, instead of scanning all RF channels. Finally, optional SDS field contains the constellation of OFDM carriers for each concerned GS. When this information is successfully decoded for the first active GS, the A/C radio enters the SS1 state where it can receive/decode all FL transmissions of the currently controlling GS. Additionally, in that timing state an A/C is allowed to send in the RACH channel to the GS (with possible collisions with other A/C). The A/C is now able to start the Initial Net Entry procedure. This GS RES_4 = Other GSs (Option) FR_NR GS_INFO GS_INFO GS_ID NN GS1_ID/CH GSN_ID/CH N_V V_Mapping N_D D_Descript. SDS RES_3 = GS_Neighbours RES_1= Nr. And Mapping of Voice Channels RES_2= Nr. and Description of DL Channels Figure 6-5: Content of Decoded PBTCH Channel Initial Net Entry After the Net Initialisation procedure, the A/C radio remains on the RF frequency of the first B-VHF GS (GS 01 in Table 6-1), but continues to cyclically scan BC slots of other active GSs. According to the list of IDs and RF frequencies used by other active GSs in the vicinity - provided by GS1 in the RES_3 field of its PBTCH, - further restricted scanning is limited to just RF channels that have been indicated as relevant by GS1 Copyright B-VHF Consortium Page: 6-20

56 and are actually used in GS1 neighbourhood. In most cases, this shortens the scanning cycle and improves the Initial Net Entry performance. During such restricted scanning, an airborne radio nominally operating (locked) on GS1 RF channel must, following the scanning cycle, switch to another B-VHF RF channel just in front of the BC slot, synchronise to the new GS, determine OFDM constellation, measure the power and decode PBTCH fields in the BC slot. Then it returns to the RF channel of GS1 for the rest of the SF. Restricted background scanning continues as long as an A/C remains within the area served in the B-VHF mode. Being synchronised to GS1, the airborne B-VHF radio now performs the Initial Net Entry procedure to GS1 (Figure 6-6), with the aim to achieve full FL/RL synchronisation with GS1 and obtain for the first time its timing correction, Local ID and other necessary information. NOTE: The current proposal is that Initial Net Entry procedure is executed with the first active GS in order to shorten the time of operational service non-availability for critical voice services after the radio has been turned ON or its mode has been changed to B-VHF. In order to access such service without restrictions, an A/C must be assigned its specific timing correction (to avoid overlapping RL transmissions at the GS). Such a correction can be obtained from the first active GS and autonomously re-calculated by an A/C radio for any other GS that has already been scanned. When the pilot subsequently selects the voice service that is provided by the first GS, service becomes immediately available, if the service is provided (only) by some other adjacent GS, the service becomes available after very short time required for Forced Handover that is described in the next section. An A/C sends a Net Entry Request message to GS1 via RACH channel. The carrier constellation for RACH is known to both the A/C and the GS, as RACH uses exactly the same OFDM carrier constellation that the GS has used for transmitting the SDS symbols in the BC slot. Similarly, the modulation type and FEC coding for RACH is also a-priori known. The Net Entry Request contains the A/C ICAO address and optionally the GS ID (as it is known from the scanning procedure). NOTE: It is proposed to include GS ID into Net Entry Request/Response and HOV Access messages to avoid any mistakes due to anomalous propagation conditions. Without such a discrimination, some remote B-VHF GS legally operating according to frequency planning - on the same RF channel as the close GS may be able to receive and falsely respond to the A/C Net Entry Request. The Net Entry Response message from the GS to the requesting A/C radio will include timing correction information, A/C Local ID mapped onto A/C ICAO address, optionally also GS ID and DCCH resources allocated to the A/C. This message is transmitted in the CCCH over Fixed FL PDTCH that is allocated by each B-VHF GS for FL data transmissions. As at this time the entering A/C is not yet aware of its Local ID (it will be assigned with the Net Entry Response message), the GS will use the broadcast address. All A/C monitor the broadcast address (in parallel to the dedicated A/C address defined by the Local ID) and will decode the Net Entry Response message, but only the entering A/C that has launched the Net Entry Request will recognise its ICAO address that is returned together with newly assigned Local ID and the timing correction. NOTE: Current B-VHF system design allows for 1024 Local IDs to be assigned within any B-VHF cell. Copyright B-VHF Consortium Page: 6-21

57 If the data link mode was activated for the concerned airborne radio (in addition to the voice functionality), after the reception of the Net Entry Response an A/C LME will inform its local sub-network layer about the just established B-VHF connection. If no data link was established via this radio so far, the connectivity change will be reported to an external network layer entity in order to establish network layer connectivity. After the Net Entry Response was sent by the GS and the Net Entry Complete message received from an aircraft, the GS also informs its local SN layer, the SN layer forwards this information in form of a Join event to the ground ATN router. An A/C will apply the timing correction to its local time base. From now on, the timing correction will be applied to all RL transmissions of that A/C it may use the RL slot and synchronised RA slots without any further restrictions. The timing of an airborne radio is updated each time, when it receives a FL burst or a BC burst from the controlling GS. This mechanism does not require any additional data transmission between an A/C and the GS. The GS also enters the ICAO address and the Local ID of entering A/C into its local data base and propagates this information to the GNI and other GSs in the vicinity. By this way, these entities are informed that this particular A/C is now within an area of this particular GS. This completes the Initial Net Entry procedure. The entering A/C has reached the timing state SS2 now. In this state voice and FL data link services can be used without any restrictions and RL resource requests for on-demand voice and data services are issued via srach channels. NOTE: The actual availability of voice and data services also depends on the progress of the scan cycle. As no particular service has yet been selected by the pilot, it is possible that the pilot selects ANY service that he considers according to the published information to be available in a given region. Therefore, the full information about the mapping of abstract services onto PDTCHs must be obtained via scanning of BC slots for all GSs in the vicinity prior to the actual service selection. In the SS2 state, an A/C regularly submits the results of the power measurements to the currently controlling GS in order to prepare seamless B-VHF cell handover to the next cell. These data are regularly sent to the controlling GS as the Physical Channel Control LME message that is transmitted either in the DCCH or in srach channel. Copyright B-VHF Consortium Page: 6-22

58 GS1 A/C GS2 SS1 LRACH: Net Entry Request (ICAO A/C address, GS ID) Initial Net Entry Restricted Scanning CCCH/Fixed FL PDTCH: Net Entry Response (ICAO A/C address, GS ID, A/C Local ID, timing advance) SS2 LsRACH/DCCH: Net Entry Complete (A/C Local ID) BCH (periodical): GS power, OFDM constellation, GS ID, PDTCH_IDs for own supported services, List of adjacent GSs (GS ID, RF channel) Figure 6-6: Initial Net Entry Procedure Service Selection After an Initial Net Entry procedure and a completed scanning cycle through relevant GSs around the first one, an airborne B-VHF radio knows the exact local configuration for each voice service provided by all B-VHF GSs within the coverage range (as the first GS contacted by the A/C has provided information about the identity and RF frequencies of all other GSs to be included into scanning cycle). The A/C is now in the SS2 timing state and no restrictions apply with respect to the usage of B-VHF services. As no operational voice service has yet been selected by the pilot, the next step is pilot s service selection via cockpit HMI. The following descriptions assume that airborne B-VHF radios are used in a voice or data link mode. Today, pilot selects fixed voice services (party-line, broadcast) by selecting the VHF channel (one voice service is provided per VHF channel). With B-VHF, multiple services are provided on the single RF broadband channel. A given voice service may be implemented at several cells on different RF frequencies, in order to avoid the need for inter-cell co-ordination, each cell should be allowed to use different PDTCH IDs for the same voice service. When the pilot actually selects the B-VHF voice service, the A/C LME already has to know:! which cells can provide the selected service,! on which RF channels! on which PDTCH, AND! which GS is the best one (has offered the strongest signal during scanning). Copyright B-VHF Consortium Page: 6-23

59 All this information is retrieved during Net Initialisation procedure from the scanned BC slots. Most of the information is derived from the decoded PBTCH channels of scanned cells, the decision which cell is the best one for a given service is based on the power measurements performed by the PHY layer and internally submitted to the A/C LME. According to the preferred B-VHF approach, the pilot should be able to select the voice service without having to know the B-VHF RF frequency or the PDTCH_ID that is used within a given cell for the desired service. Taking into account that another cell may provide the same wide-area service by using completely different PDTCH_ID, it becomes apparent that PDTCH_ID is not a good choice to be presented to the users as a means of service selection. Instead, an abstract B-VHF service ID (B-ID) should be used for service selection, comprising party-line, broadcast and selective voice channels and possibly also fixed broadcast data link channels. Such abstract B-IDs should (like the VHF channel IDs today) be globally known, published in the AIPs and selectable via pilot s HMI. This means, instead of 125,750, the pilot will find in AIPs something like B-7 as an identifier of e.g. party-line voice service provided in an ATC sector within a given area. NOTE: Due to the required description of the mapping of B-IDs to PDTCHs that must fit into the PBTCH, the number of B-IDs is limited. Current B-VHF system design allows for 512 abstract B-IDs selectable on the pilot s HMI. This, however, is only a preliminary choice and is open to further discussions Forced Handover When the pilot selects after an Initial Net Entry procedure (in the SS2 state) a desired voice service, the airborne LME is informed about the selected B-ID. The LME will inspect the mapping of the abstract B-IDs onto PDTCHs for the currently controlling GS, but also for all other relevant GSs in the neighbourhood. This information is provided during the scan procedure in the PBTCH RES_1 field (Table 6-2). Provided by PHY PMU Decoded PBTCH CH ACT PWR SDS GS_ID B-1 B-2 B-3 B-4 B-76 B-77 B-78 B-189 B-190 B-191 B-510 B-511 B-512 <-- B-ID (globally known) "3" <-- PDTCH_ID (GS 23) "2" <-- PDTCH_ID (GS 17) 12 X "1" <-- PDTCH_ID (GS 5) Table 6-2: Example of B-ID/PDTCH Mapping In this example, GS1 is the currently controlling station (it was the first one that was detected during blind scanning procedure and is marked as active in the ACT column). If the pilot should have selected e.g. any of the services B-3, B-78 or B-191 (all being provided only by GS1), the selected service will become immediately available, as the timing correction has already been received from GS1, so an unrestricted RL operation is allowed. Should the pilot have selected B-76 service that is not provided by GS1, but is according to Table 6-2 available at GS2, the B-VHF PMU would immediately after the service selection adjust and activate GS2 RF frequency (CH3), correct the RL timing between GS1 and GS2 and pre-set detailed PHY parameters of PDTCH_13 (as this PDTCH is used Copyright B-VHF Consortium Page: 6-24

60 at GS2 for the B-76 service). At the same time, A/C LME sends in srach channel a Net Entry Request to GS2 (basic voice service is already available at that time). This procedure is shown in Figure 6-7 and is referred to as Forced Handover. It generally applies if the pilot selects the B-ID that is not supported by the currently controlling GS1. Exactly the same procedure would apply to the case where the pilot has selected a service that is supported by more than one GS (e.g. GS1, GS2 and GS3 all provide wide-area B-189 service). In that case the LME would additionally inspect the PWR column of Table 6-2 and find that GS2 is the best candidate to provide the B-189 service, as it has provided the strongest signal during the scan procedure. The PMU would immediately activate GS2 RF frequency (CH3), correct the RL timing between GS1 and GS2 and pre-set detailed PHY parameters of PDTCH_22 (that is use at GS2 for the B-189 service). Forced Handover is air-initiated and is completely different than the ground-initiated Seamless Handover that is used for seamless transfer of wide-area voice and data link services between cells. The basic voice service associated with the selected B-ID is available from GS2 immediately after the service selection, the A/C becomes addressable within the new cell (and can use advanced voice features) after small delay when the Net Entry Response message is received from GS2. If the data link mode was (optionally) activated for the concerned airborne radio (in addition to the voice functionality), the connectivity change is additionally reported towards an airborne SN layer. After the Net Entry Response was sent and the Net Entry Complete message received, the GS also informs its local SN layer, the SN layer eventually forwards this in the form of a Join event to the ground ATN router. The Forced Handover procedure is very similar to an Initial Net Entry, the major difference is that an Initial Net Entry starts from the synchronisation state SS1 (an A/C must use RACH transport channel when launching Net Entry Request message), while Forced Handover starts from the state SS2 and ends with an SS2 state (An A/C is already synchronised to GS1. It can autonomously adjust its timing to GS2 and therefore can use srach transport channel instead of RACH for the Net Entry Request message). NOTE: More precisely, the A/C was in the SS2 state with GS1 before forced handover. After the forced handover the A/C is in the SS2 state with GS2. Forced Handover is completed (from an A/C point of view) when the A/C receives from GS2 a Net Entry Response message with the A/C ICAO address, the new Local ID and an update of the timing correction. GS2 considers the Forced Handover to be completed when it receives the Net Entry Complete message from the aircraft. GS2 additionally sends the HOV Completed message to the GNI and all other GSs (including GS1), informing them that the A/C has now logged on GS2. Thus, GS1 (or any other GSs) may remove this A/C from its data base and assign this Local ID to another entering A/C. After the Forced Handover, the A/C radio remains locked to GS2 RF channel, but continues to scan other active GSs, according the updated list of active GSs provided by GS2. NOTE: Each GS provides such a list during scanning, but as different GSs have different neighbourhood, these lists are not identical for different GSs. If an A/C radio locks onto some GS (after either automated or forced handover), the list of the currently controlling GS becomes relevant for further scanning. Copyright B-VHF Consortium Page: 6-25

61 GS1 A/C GS2 SS2 (A/C GS1) TCH: Normal FL/RL voice exchanges between A/C and GS1 Rapid RF frequency change, calculation of new timing correction, adjustment of PDTCH parameters for the new voice service at GS2 Pilot selects a new voice service not available at GS1 Basic voice service available SS2 (A/C GS2) LsRACH: Net Entry Request (ICAO A/C address, GS ID) Forced Handover Enhanced voice features available GND-GND: HOV Completed (A/C ICAO address) TCH: Normal FL/RL voice exchanges between A/C and GS2 CCCH/Fixed FL PDTCH: Net Entry Response (ICAO A/C address, GS ID, A/C Local ID, timing advance) LsRACH/DCCH: Net Entry Complete (A/C Local ID) Figure 6-7: Forced Handover Seamless Handover Seamless Handover between cells is required for the transfer of wide-area voice and data link services in case where several cells implement the same service and an A/C is already using (the pilot has selected) this wide-area voice or data service. All GSs are assumed to be interconnected to each other via the ground B-VHF network. Within each cell a local aircraft population (other aircraft) may exist that already uses this particular party-line service. Therefore, the local PDTCH for the wide-area service must already have been allocated within each cell (permanently, regardless of the seamless handover status of a particular single aircraft). Dependent on the type of the currently selected service, each of airborne B-VHF radios may prior to the handover be connected to either the same or different GS. Two voice airborne B-VHF radios may simultaneously participate in two voice user groups that are supported by different constellations of GSs. The conditions for handover may not be simultaneously fulfilled for both radios, so each voice radio may have to be handed-over independently, at different time and possibly to a different next cell. Opposite to voice services, multiple data link services are running by assumption via separate B-VHF radio unit. Assuming that all such data link services are implemented at each B-VHF cell, all running data links can be handed-over to the next cell at the same time. Copyright B-VHF Consortium Page: 6-26

62 In order to keep the wide-area voice operation transparent to the users, Seamless Handover must be performed as an automated procedure, initiated by the GS without human involvement. Similar applies to the handover of ongoing data link connections. The handover decision will be taken by the LME of the GS. It is based on measurements of the signal quality and signal strength performed both in the GS but also in the A/C (involving PHY and MAC layer). During each scan, the A/C LME collects the information about relative received signal powers and timing offsets of all concerned GSs, building up the slowly changing picture about the GS constellation and the services they can provide. An airborne LME submits the signal quality data to the GS LME via a Physical Channel Control message that is defined on the LME sub layer and periodically transmitted in the RL direction via srach or DCCH channel. The GS LME will restrict potential next cells for the handover just to the cells capable to provide the same wide-area service that is currently provided via the corresponding airborne radio unit. Other cells that possibly provide stronger signals, but do not support the currently selected service will be ignored. NOTE: The identifier of the ongoing wide-area service should be made known to the GS LME via the Physical Channel Control message. In addition, the super-frame structures of all GSs in the B-VHF system are assumed to be synchronised to the same reference with sufficient precision to keep the handover procedure simpler. Another assumption used in the following description of the handover procedures is that all GSs are interconnected to each other. The messages relevant for this procedure are shown in Figure 6-8. The Seamless Handover starts from the SS2 timing state and ends with the same state (however, the controlling GS has changed from GS1 to GS2). The current GS1 checks whether handover condition is fulfilled for the ongoing service, selects the next GS2 and forwards to the next GS2 (ground-ground HOV Request message) the A/C ICAO address (to be used when GS2 allocates a new Local ID to that A/C) and the service parameters of an ongoing service that shall be handed over. GS2 responds (ground-ground HOV Response message) by returning the new Local ID correlated with the A/C ICAO address, also indicating the preferred handover time and the PDTCH ID for the ongoing service. NOTE: In case of a wide-area voice service, service parameters, including PDTCH_IDs, are already known in each cell, as the service is instantiated in each cell. The above description is generally also applicable to the handover of data links, where this condition is not fulfilled. After having received the HOV Response message, GS1 schedules the exact handover time when the handover shall be executed and sends the HOV Command message to the A/C LME. This message is sent via Fixed FL PDTCH that is instantiated at each B-VHF GS. HOV Command message contains the scheduled handover time. The requesting A/C radio must stick to it and executes the handover exactly at the pre-defined slot within the B- VHF frame structure (this is of particular importance for seamless handover of ongoing voice conversations). Copyright B-VHF Consortium Page: 6-27

63 GS1 SS2 (A/C GS1) A/C GS2 TCH: Normal FL/RL voice/dl exchanges between A/C and GS1 LsRACH or DCCH (periodical): Physical Channel Control message (PWR, BER) BCH (periodical): GS power, OFDM constellation, GS ID, PDTCH_IDs for own supported services, List of adjacent GSs (GS_ID, RF channel) Automated Handover Decision at GS1 GND-GND: HOV Request (A/C ICAO address, service parameters) GND-GND: HOV Response (A/C ICAO address, new A/C Local ID, HOV time, PDTCH IDs for DL services) CCCH/Fixed FL PDTCH: HOV command (new Local ID, HOV time, PDTCH IDs for DL services) Fast RF frequency change, calculation of new timing correction, adjustment of PDTCH parameters for the new voice service at GS2 Basic and enhanced voice features available SS2 (A/C GS2) LsRACH: HOV Access (ICAO A/C address, new A/C Local ID, GS ID) TCH: Normal FL/RL voice/dl exchanges between A/C and GS1 Automated Handover GND-GND: HOV Completed (A/C ICAO address) Figure 6-8: Seamless Handover When specifying the handover time for wide-area data link services, GS1 should consider that any ongoing data exchange (DLS frame) shall preferably be finished prior to the handover. GS1 would not send the HOV Command message until the current DLS frame has been acknowledged. GS1would suppress its own FL data transmissions to that A/C and reject any further A/C requests for RL resources. The Seamless Handover procedure also covers that case where an airborne B-VHF radio provides a wide-area voice service and (several) DL services at the same time. Assuming sufficient overlapping operational coverage of involved GSs, the actual moment of voice Copyright B-VHF Consortium Page: 6-28

64 service handover is not critical (may be adjusted according to the specific DL demands). However, when the handover is initiated by the GS, it must be executed by an A/C radio extremely fast (between successive FL/RL B-VHF frames) in order to prevent any loss of voice information. The handover is executed when the A/C LME has received the HOV Command message. The LME then locally issues the handover commands to the local MAC sub-layer and PHY layer. RF carrier frequency switching, timing adjustment and the OFDM carrier constellation change itself is performed in the PHY layer, managed by the PMU. Immediately after the handover was executed, unrestricted wide-area voice and/or data link service become available via GS2. If the data link mode was activated for the concerned airborne radio (in addition to the voice functionality), the connectivity change is reported towards an airborne SN layer. However, as in this case a previous data link already existed on a different RF frequency with another GS, the connectivity change is not further reported (an existing SN connection is preserved). After the HOV Access message was received, the GS2 also informs its local SN layer. The SN layer will suppress this message (will not send a Join event to the ground ATN router). At the same time, the A/C LME sends in the srach channel a HOV Access message to GS2, containing the A/C ICAO address, new Local ID valid within GS2 range, as well as an optional GS2 ID. Seamless Handover is completed when GS1 receives from GS2 a HOV Completed message, informing GS1 that the A/C with a specified ICAO address has now logged on GS2. Hence, GS1 (or any other GS) may remove it from its data base and may assign its Local ID to another entering A/C Net Exit The Net Exit procedure applies if an aircraft leaves the coverage range of the B-VHF system (it is not reachable any more by any B-VHF GS). Its purpose is to make different entities residing within different protocol layers of the ground B-VHF system in particular the sub-network layer aware of the connectivity loss to the particular A/C. NOTE: Both B-VHF SN layers will in that case issue a Leave event towards the local ATN router. Disconnection from the B-VHF network may be optionally used on the airborne side to automatically re-configure multi-mode airborne B-VHF radios for the usual DSB-AM voice operation and/or VDL Mode 2 data operation. An explicit Net Exit procedure can be either GS or A/C initiated, triggered by the corresponding LME. An A/C LME can make a Net Exit decision based on periodical measurement reports concerning signal quality (e.g. signal quality of the controlling GS becomes too low and there is no other known active B-VHF GS within the range). The GS LME can make its decision based on the similar criteria. The Net Exit procedure may also be implicit, if the last controlling GS recognises that an A/C does not send periodical measurement reports concerning signal quality (therefore this A/C is considered to be outside range of that GS). The Net Exit procedure (A/C initiated and GS initiated) with corresponding messages is shown in Figure 6-9. NOTE: A/C Net Exit Requests and Net Exit Responses may be combined with the RL Resource Request message. Copyright B-VHF Consortium Page: 6-29

65 GS1 A/C LsRACH or DCCH: Net Exit Request (A/C Local ID, GS ID) SS2 Fixed FL PDTCH: Net Exit Completed (A/C Local ID, GS ID) SS0 GS1 A/C Fixed FL PDTCH: Net Exit Request (GS ID) SS2 LsRACH or DCCH: Net Exit Response (A/C Local ID, GS ID) Fixed FL PDTCH: Net Exit Completed (A/C Local ID, GS ID) SS0 Figure 6-9: Net Exit Procedure Resource Allocation Dependent on the local spectrum occupancy situation, each B-VHF cell will have different amounts of resources available for the services it provides. The B-VHF system considers exactly the same pool of OFDM carriers as available on both FL and RL within an entire B-VHF cell. When the GS transmits (BCH) in the FL BC slot, it uses all available OFDM carriers. Full carrier constellation is also used when an A/C transmits (RACH, srach) in RL RA slot. The B-VHF resources for B-VHF (operational) communications services provided via transport channels in FL and RL slots will be divided into:! Fixed resource pool for party-line (B-VP) and FL broadcast (B-VB) voice services! Fixed resource pool for broadcast (connectionless, FL) data link services (B-DB)! Additional resource pool to be used for on-demand services " Selective voice services (B-VS, connection-oriented) " Acknowledged data link service (B-DA, connectionless/connection-oriented) " Not acknowledged data link service (B-DN, connectionless) NOTE: B-VP, B-VB, B-VS, B-DB, B-DA and B-DN are the acronyms for the B-VHF communications services that are used in the following chapter. This classification does not cover system-internal B-VHF communications. Copyright B-VHF Consortium Page: 6-30

66 B-VHF system uses a centralized resource allocation approach for all FL/RL transport channels. In all cases, the GS is responsible for allocating necessary physical resources for FL/RL transport channels for all A/C within its coverage range. FL/RL resources for party-line voice, voice broadcast and data broadcast services are fixed, the PDTCH IDs of the corresponding physical transport channels are communicated to the A/C during the Net Initialisation procedure and can be used without an explicit request, according to the valid existing procedures. The GS always allocates one so called Fixed FL PDTCH for its own FL data transmissions. The PDTCH parameters for this channel (PDTCH_ID, MID, CDMA code, TCH type, TCH slot number) are communicated to the A/C (via the PBTCH, RES_2 field). NOTE: The GS may allocate either a single Fixed FL PDTCH or several such PDTCHs. An A/C is always informed about parameters of all fixed FL PDTCHs and monitors all such PDTCHs. When allocating dynamic TCHs, the GS may only use the remaining OFDM carriers available in the resource pool after all fixed FL/RL resources have been allocated. In order to balance-out static and dynamic FL/RL cell demands, the purpose and capacity of each cell has to be carefully planned in advance. The GS planning procedure comprises determining the exact number of required permanent FL/RL TCHs and estimating the maximum simultaneous number of dynamic TCHs that may be requested by the users. RL resources for on-demand services must be explicitly requested by an A/C B-VHF system. The remainder of this section describes the allocation procedure for different types of on-demand voice and DL services Acknowledged point-to-point data link (B-DA) This type of DL comprises CoS D1, D2, D3, D4 and D-AOC [B-VHF D5] classes. The underlying B-DA service has been configured as a connectionless acknowledged service. Optionally, it is possible to use connection-oriented acknowledged mode that is also used for selective voice services. An airborne radio always monitors the Fixed FL PDTCH channel. The GS will (Figure 6-10) schedule, merge and successively send FL DLS frames via the Fixed FL PDTCH to the A/C within its range, according to the local priority rules. Each DLS frame will be received and further processed only by that A/C that was explicitly addressed in the header of the FL DLS frame. Prior to the actual FL DLS frame the Resource Grant message is sent to the selected A/C, specifying the RL ACK_TCH to be used when A/C acknowledges the subsequent FL DLS frame. Resource Grant message is sent via the same Fixed FL PDTCH that will be used for the FL transmission of GS DLS frames (this message may even be combined with the first DLS frame). If there are several scheduled FL DLS frame transmissions to the same A/C, the same RL ACK_TCH may be used to acknowledge all such FL DLS frames. This RL PDTCH automatically expires after the A/C has acknowledged all DLS frames sent on FL. Copyright B-VHF Consortium Page: 6-31

67 GS1 Fixed FL PDTCH: Resource Granted (ACK_TCH ID) A/C SS2 Fixed FL PDTCH: FL DLS Frame ACK_TCH: ACK for the FL DLS Frame SS2 Figure 6-10: FL B-DA Transmission An A/C has to explicitly request the RL resources for its own DLS frames. Following the external request passed by the SN layer, an airborne B-VHF LME generates the Resource Request message (Figure 6-11) that is forwarded in the srach transport channel to the GS LME. GS1 LsRACH: Resource Request (DLS Frame priority, length) A/C SS2 Fixed FL PDTCH: Resource Granted (RL TCH ID) RL TCH: RL DLS Frame Fixed FL PDTCH: ACK for the RL DLS Frame SS2 Figure 6-11: RL B-DA Transmission NOTE: Two types of Resource Request messages either for time-limited or unlimited RL resources (PDTCHs) are possible with the B-VHF system. Time-limited reservations are used for B-DA services (the resources are requested and will be granted only for a single RL DLS frame). This corresponds to the reservation of a number of RL slots sufficient to transfer the current A/C DLS frame. Unlimited resource requests are used for on-demand voice services (B-VS) and may in the future optionally be used for long RL data link transmissions within the scope of the B-DA service. The GS responds to the A/C Resource Request message with the Resource Grant message transmitted in the Fixed FL PDTCH. The Resource Grant message specifies the RL TCH (PDTCH_ID, MID, TCH type, TCH slot number within the current hyper-frame) to be used when A/C sends the RL DLS frame. The GS acknowledges received RL DLS frame via Fixed FL PDTCH. Copyright B-VHF Consortium Page: 6-32

68 Not acknowledged (broadcast) FL data link (B-DB) The GS allocates a (number of) PDTCHs for unacknowledged FL broadcast transmissions (e.g. CoS D6-1). The PDTCHs may be SCH, FCH, SFCH or UFCH and their parameters (PDTCH_ID, MID, CDMA code, TCH type) are communicated to the A/C (separately for each PDTCH) and associated with the broadcast FL data link (via the PBTCH, RES_2 field). If the broadcast FL DL service has been selected by the pilot, an airborne B-VHF radio associated with that service will permanently monitor the FL PDTCH_ID associated with that service. As this type of service is not acknowledged, no RL resources are required (Figure 6-12). GS1 Broadcast FL TCH: FL Broadcast Frame A/C SS2 SS2 Figure 6-12: FL B-DB Transmission Not acknowledged RL data link (B-DN) Such data link is used for RL-only transmissions that are all directed towards the same GS, but do not require FL acknowledgement (e.g. CoS D5, CoS D6-2). Currently, the same reservation-based procedure is foreseen as for the point-to-point RL DLS frame transmissions. More sophisticated reservation algorithms like pre-scheduled RL access to SCH and SSCH are delegated to a follow-on project. GS1 LsRACH: Resource Request (DLS Frame priority, length) A/C SS2 Fixed FL PDTCH: Resource Granted (RL TCH ID) RL TCH: RL DLS Frame SS2 Figure 6-13: RL B-DN Transmission Selective voice services (B-VS) In addition to party-line (B-VP) and broadcast (B-VB) services, B-VHF system also offers selective point-to-point voice service (B-VS). This category comprises CoS classes V2, V5 and V-AOC. Resources for the B-VS service have to be explicitly reserved in a circuit switched mode, creating a dedicated link between an A/C LME and the GS LME. Copyright B-VHF Consortium Page: 6-33

69 Both Link Establishment and Link Release procedure may be initiated by either the A/C or the GS. GS1 A/C Call Request Ind. LsRACH: Link Establishment Request (with embedded operational Call Request) SS2 Call Request Call Accept Fixed FL PDTCH: Link Setup (dedicated FL/RL FCH ID & embedded operational Call Accept) OR Link Establishment Reject (reason for rejection) Dedicated FL/RL FCH: B-VS Voice frames Call AcceptInd. SS2 Figure 6-14: A/C Initiated Link Establishment Procedure for B-VS Service GS1 A/C Call Request Fixed FL PDTCH: Link Setup (dedicated FL/RL FCH ID & embedded operational Call Request) SS2 Call Request Ind. Call Accept Call Accept Ind. Dedicated RL FCH or LsRACH: Link Setup Completed (& embedded operational Call Accept) Dedicated FL/RL FCH: B-VS Voice frames SS2 Figure 6-15: GS Initiated Link Establishment Procedure for B-VS Service If a selective voice service (B-VS) was requested by an A/C, Resource Request message is accompanied by the Call Request message with the address of the called ground user. NOTE: Call Request message is an operational message generated by the pilot (intended to be accepted/rejected by the ground human recipient). This message in turn triggers the Link Establishment Request (system) message that is invisible for human system users. Both messages shall be transmitted (combined) during the same srach access. The GS forwards the Call Request message to the called ground user for acceptance. After the Call Request message has been accepted by the ground user (user has sent the Call Accepted message to the GS), the GS responds to the calling A/C by the Link Setup Copyright B-VHF Consortium Page: 6-34

70 message, containing the PDTCH_ID of a FL/RL FCH pair that will be from now on allocated for the B-VS voice service, and by the operational Call Accepted message. Both messages are sent in the Fixed FL PDTCH that was allocated for GS FL transmissions. A copy of the Link Setup message is also sent to the ground user. After an A/C has received the Link Setup message and the Call Accepted message has been indicated to the pilot, the pilot can immediately start to use the RL FCH associated with the B-VS service. As the call was air-initiated, the called controller or other ground staff will normally wait for the pilot starting to speak, but they may also themselves starting to speak after they have received the copy of the Link Setup message. For any other voice service, the pilot/controller would press the PTT key and start to speak (PTT procedure is retained for continuity reasons). If the ground user makes the voice call to the selected A/C, the GS spontaneously sends in the Fixed FL PDTCH the Link Setup message (specifying the FL/RL PDTCH pair that will from now on be allocated for the on-demand voice service) and the operational Call Request message. The ground user can start to use the FL selective voice channel immediately (if the call acceptance is implicit, as required for some B-VS services) or wait that the called pilot acknowledges the Call Request by sending the Call Accepted message (in srach or just allocated RL voice FCH). The pilot may use the RL selective voice channel after the Call Request has been indicated (if implicit service acceptance), otherwise after he has triggered the Call Accepted message. NOTE: As the pilot and not the B-VHF system operationally accepts the call (after an undefined, unpredictable time), the GS cannot pre-schedule RL resources for Call Accepted message, so srach or RL voice FCH must be used for that purpose. On-demand voice channels must be explicitly operationally released by either the pilot or the ground user. This is accompanied by the B-VHF internal disconnection procedure. Pilot s Call Release operational message (Figure 6-16) triggers a RL Disconnect Request management message. Both messages are forwarded to the GS in the dedicated RL FCH that was allocated for the B-VS service. After having received the Disconnect Request message, the GS forwards the Call Release message to the external ground user. Triggered by the external Call Release Accept message, the GS sends the Disconnect Command message together with the Call Release Accept message in the Fixed FL PDTCH to the A/C LME and considers the B-VS service to be terminated. The A/C LME forwards the Call Release Accept message to be indicated on the pilot s HMI, notifying the pilot that the B-VS service is not operationally available anymore. Based on the reception of the Disconnect Command message, the airborne LME issues the Disconnect Completed message to the GS LME in the RL FCH that was previously used for RL B-VS voice transmissions and considers the previously allocated FL/RL FCHs as non-available (will prevent any subsequent transmission on the RL FCH). After having received the Disconnect Completed message, the GS LME also considers the B-VS service to be terminated and may now re-allocate FL/RL FCH for another B-VS service or other use. Copyright B-VHF Consortium Page: 6-35

71 Call Release Ind. GS1 Dedicated RL FCH: Disconnect Request (with embedded operational Call Release) SS2 A/C Call Release Call Release Accept Fixed FL PDTCH: Disconnect Command (Dedicated FL/RL FCH ID & embedded operational Call Release Accept) Call Release Accept Ind. Dedicated RL FCH: Disconnect Completed (dedicated FL/RL FCH ID) SS2 Figure 6-16: A/C Initiated Link Release Procedure for B-VS Service Call Release GS1 Fixed FL PDTCH: Disconnect Command (Dedicated FL/RL FCH ID & embedded operational Call Release) A/C SS2 Call Release Ind. Call Release Accept Ind. Dedicated RL FCH: Disconnect Completed (dedicated FL/RL FCH ID & embedded operational Call Release Accept) Call Release Accept SS2 Figure 6-17: GS Initiated Link Release Procedure for B-VS Service If the ground user terminates the B-VS temporary connection, his Call Release message is (Figure 6-17) sent to the GS. After having sent this message, the ground user is immediately disconnected from the FL voice FCH. The GS transmits both the Call Release and Disconnect Command messages in Fixed FL PDTCH to the specified A/C. If the service release acceptance is implicit by procedure (e.g. CoS V-2 service), the Call Release message is just indicated to the pilot. The B-VHF airborne system itself responds to the Disconnect Command message (no Call Release Accept message is generated) by the Disconnect Completed message sent to the GS LME in the RL FCH that was temporary allocated for the B-VS service. The airborne B-VHF LME considers the B-VS service to be terminated and prevents any further access to the RL voice FCH. The GS considers the connection as terminated after it receives the Disconnect Completed message, otherwise it will attempt to re-transmit Disconnect Command with the Call Release message. Copyright B-VHF Consortium Page: 6-36

72 If the release acceptance is explicit, the pilot clears the indicated Call Release message by the Call Release Accept message. This message triggers the B-VHF Disconnect Completed management message. Both Call Release Accept message and Disconnect Completed message are sent in the RL FCH that was temporary allocated for the B-VS service. In both cases, the GS waits until it receives the Disconnect Completed message, then it (optionally) passes the Call Release Accept message to the ground user and removes the voice FL/RL FCH (considers the connection as terminated). The GS will attempt to retransmit Disconnect Command with the Call Release message if no Disconnect Completed message was received within the specified time B-VHF Architecture The B-VHF system is capable of providing different voice and data link services to its users, comprising both human beings and automated data systems. These users may be located on the ground or within an A/C and access the B-VHF services via defined external air/ground abstract voice and data interfaces, as described in [B-VHF D6]. In practice, each of the B-VHF external interfaces may dependent on the application - comprise a combination of dedicated voice/data/discrete signalling interfaces. The detailed interface composition will be described later on, when describing B-VHF communications services. The B-VHF system is developed to become an A/G sub-network. Moreover, it should be integrated within the global ATN framework. With respect to data operation, the B-VHF system comprises the two lowest layers of the ISO-OSI model (Physical Layer and DLL) and specific parts of the Network Layer (Subnetwork layer). The Physical Layer and the MAC-sub-layer of the DLL also provide necessary support for basic voice functionality, while advanced voice functions require more extensive support, including LMEs and other DLL components and functions. The B-VHF system end-to-end architecture comprises airborne and ground B-VHF subsystems Ground B-VHF Subsystem The expected network architecture and ground B-VHF system components are shown in Figure The meaning of the B-VHF functional blocks is the following:! G_TX (ground B-VHF transmitter)! G_RX (ground B-VHF receiver)! GSC (ground station controller)! GNI (ground network interface) Figure 6-18 also depicts external functional blocks that interface with the B-VHF system:! DLS (ground data link system) with the corresponding HMI! VCS (ground voice communications system) with the corresponding HMI NOTE: DLS represents all ground data link components that are external to the B-VHF system, including ground ATN routers, ATN end-systems and data link applications processors. Copyright B-VHF Consortium Page: 6-37

73 NOTE: A Ground Voice Unit is necessary for the B-VHF voice sub-system operation, but is not illustrated in Figure 6-18, as it may, dependent on the selected GND Network architecture, be integrated into the GSC or GNI within the B-VHF system but also within the external VCS. The exemplary B-VHF ground infrastructure comprises a number of B-VHF Ground Stations (GS), which are organised into clusters. Each GS comprises physical B-VHF radio units (G_TX, G_RX) and the Ground Station Controller (GSC) that is connected to the Ground Network Interface (GNI). The GNI acts as a cluster concentrator and provides interfaces to the VCS, ATN and non-atn ground data link systems and networks. NOTE: In Figure 6-18 an ATN Air/Ground Router supporting a cluster of GSs is a part of the DLS block. For practical implementation it may be a separated component, interconnected with an ATS provider s ATN end system via GND data network. The same or different GND data network may be used to connect the ground ATN router with remote data systems of other users (AOC). A/C1 A/C2 A/C3 G_RX1 G_TX1 G_RX2 G_TX2 Cell 1 GSC1 GSC2 Cell 2 GND Network GNI1 GNI2 Subnetwork Interfaces GND Voice/Data Networks B-VHF Mgmt. DLS1 HMI1 VCS1 VCS2 HMI2 DLS2 Figure 6-18: B-VHF Ground System Architecture Copyright B-VHF Consortium Page: 6-38

74 The physical radio units (G_TX, G_RX) comprise the Physical Layer and the parts of the DLL layer (MAC sub-layer) of the B-VHF protocol stack. Due to the required close cooperation between the PHY layer and the MAC sub-layer, it is not advisable to separate these entities. They should instead be both kept within the single physical unit. Physical radio units are directly involved with the management of the underlying physical resources (OFDM carriers), modulation, interleaving, frame synchronisation, Forward Error Correction (FEC) coding, provision and maintenance of the system timing and other PHY aspects. In order to support seamless handover between cells, B-VHF GSs must be precisely synchronised to each other. The G_TX acts as timing master for entire A/C population within a cell and will have to implement either a precise internal timing source or to provide an interface to an external timing source (e.g. GPS or other equivalent source). The G_TX may also need to provide reference timing to its associated G_RX. Both G_TX and G_RX are connected to their local GSC via a local connection. The GSC implements the DLL layer components above MAC sub-layer and provides local support for voice operation (e.g. local re-transmission within a party-line). As a minimum, GSC has to implement the BSS sub-layer and a part of the LME entity that is required for the operation of the B-VHF system on single RF channel. The required LME functionality comprises support for the Net Initialisation, Initial Net Entry, Forced Handover, Seamless Handover procedures, as well as for reservation-based resource requests, including support for on-demand voice services and circuit-mode data link services (Link Establishment/Release). NOTE: These procedures are described in the previous sections. The GSC takes care about the logon/logoff of an A/C within a given cell (during Initial Net Entry or handover procedures) and notifies the GNI about any A/C connectivity changes. The GSC also manages ground party-line re-transmission for user groups (ATC sectors) that are completely in the space of the cell. The GSC maintains a local data base with ICAO address and Local IDs of all A/C that are connected to that GS. This information is updated after each new A/C entry/exit to/from the cell, as well as after handover to/from another cell. The unique ICAO addresses are used e.g. when mapping the external selective voice calls directed to an ICAO A/C address to the Local IDs, which are used by that particular GS. The GNI implements the LME part dealing with multiple cells and multiple frequencies and is therefore particularly involved with the GS switchover during handover procedures. As each cell operates on a single frequency, this LME part cannot be put into the GSC. In particular, the GNI part of the LME will be involved with handover between B-VHF cells. It will co-ordinate, schedule and re-direct existing voice and DL connections between a given cell and the specific A/C to another cell operating on different frequency, without loss of voice or data frames. The GNI has a central repository with ICAO addresses (and Local IDs) of all A/C that have logged at any of the attached GSs. This information is updated after each new A/C entry/exit to/from the local B-VHF system, as well as after handover between cells. The repository of unique ICAO addresses is used in all cases where a unique A/C B-VHF system identifier is required, e.g. when co-ordinating handovers with other GSCs or mapping the external selective voice calls directed to an ICAO A/C address to Local IDs that is valid only within the domain of a particular GS. Copyright B-VHF Consortium Page: 6-39

75 NOTE: The mapping of ICAO addresses to Local IDs may be implemented independently at each GSC, centrally at the GNI, or both. The best option for the B-VHF system is yet to be selected. The GNI implements the B-VHF sub-network layer functions and interfaces with an external ATN router. The B-VHF sub-network layer is responsible for preserving the subnetwork data link connections during handovers. As long as the next B-VHF cell is within the current GNI, the GNI will just re-direct the existing connections to another cell, but will not report the connectivity change to the ATN router. This will avoid unnecessary management exchanges between an airborne and the ground ATN router. A further option for reducing such handover overhead is further GNI clustering and a co-operation between adjacent GNIs. The GNI will also provide support for non-atn data link services (e.g. FL broadcast, RL regular transmission of A/C parameters) and will implement interfaces to the (local) ground DLSs that are sources/users of such data. The GNI is particularly responsible for managing multiple GSs, which provide wide-area services and supports on the ground side rapid switching of voice circuits between cells during Seamless Handover. In order to facilitate this operation, ground network delays between the GNI and each GS involved with wide-area voice service shall be both minimised and aligned to each other. The GNI optionally may offer separate RL voice circuits from different cells participating in the wide-area voice coverage to the external VCS, or may implement internal conferencing. NOTE: The GNI may also be involved with routing of party-line circuits between multiple cells during re-transmission, but it can also configure involved GSCs to autonomously perform such routing during the GND B-VHF network. The GNI may comprise Voice Units (vocoders) for B-VHF voice operation, but these may alternatively be implemented outside the B-VHF system (e.g. within the VCS). In any case, GNI interfaces with external VCS and accepts both traditional PTT and extended signalling. Finally, the GNI will implement necessary B-VHF management functions, including the central repository of available VHF resources within an entire region. Global ground access to the dial-in B-VHF voice service (e.g. CoS v-aoc class) is possible via the local VCS (alternatively, remote voice access could be made available directly within the GNI or even GSC). NOTE: Fully deployed B-VHF system provides an internal capability for global provision of AOC voice service. Details of the operational concept for such a service provision are beyond the scope of the B-VHF project Air Subsystem Airborne integration of a new communications system is not a trivial issue and is constrained e.g. by the existing wiring and other existing systems. Details of B-VHF system airborne integration must be carefully investigated in the future work. The following description should be understood as an initial attempt to define an exemplary airborne B-VHF architecture and will have to be supplemented by a careful detailed work in the future. It is heavily based on existing airborne architecture and does not preclude other implementations and concepts. Airborne B-VHF sub-system comprises the following generic functional blocks:! A_TRX (airborne B-VHF transceiver) Copyright B-VHF Consortium Page: 6-40

76 ! ANI (airborne network interface) These entities logically interact with external avionics components:! Radio Management Panel (RMP)! Audio Management System (AMS)! Communications Management Unit (CMU)! Airborne Data Link System(s) These logical blocks, however, do not imply any particular physical implementation. Several functional blocks may be combined within a single physical unit, single function may be implemented through multiple units. In particular, airborne network interface (ANI) does not exist as a physical entity, its functions are distributed between the physical radio unit and the (external) CMU. To facilitate equipment certification, two physical units existing CMU and the new B-VHF multimode transceiver shall be sufficient for the B-VHF operation. NOTE: Airborne Voice Unit is expected to be integrated within the airborne B-VHF transceiver (A_TRX). The roles of airborne B-VHF components are similar to their ground counterparts. The physical radio transceiver (A_TRX) comprises the Physical Layer and the parts of the DLL layer (MAC sub-layer) of the B-VHF protocol stack. Each A_TRX autonomously maintains reference timing obtained from its controlling GS (as precise alignment with the GS timing is required for synchronous RL transmissions). A_VU (vocoder) should also be integrated within the physical multimode VHF airborne transceiver (it shall provide an external interface to the Audio Management System). The A_TRX also implements DLL layer functions above MAC sub-layer that are required in support of voice operations. As a minimum, A_TRX has to implement the BSS sub-layer and the LME entity, as this is required for autonomous operation of this particular B-VHF radio. The required LME functionality comprises support for the Net Initialisation, Initial Net Entry, Forced Handover, Seamless Handover procedures, as well as for reservationbased resource requests, including support for on-demand voice services and circuitmode data link services (Link Establishment/Release). The A_TRX LME takes care about the logon/logoff within a given cell (during Initial Net Entry or handover procedures) and notifies the B-VHF SN layer (in the CMU) about A/C connectivity changes. The SN layer decides whether to forward these reports to the airborne ATN router (also implemented within the CMU) or not (in case that the changes can be made transparent to the router). The A_TRX LME maintains a local data base with B-VHF system configuration information that is relevant to that radio. The information is submitted by the GS LME during the Net Initialisation procedure and regularly updated. In particular it is updated before and after an A/C handover to another GS. The unique A/C ICAO address must be made available to the A_TRX as it is used during the Net Initialisation procedure. The A_TRX (LME) is directly involved with all types of handover between B-VHF cells, in case of a seamless handover it will co-ordinate the handover with the GS and issue command to the PHY layer to re-direct existing voice and DL connections to another cell operating on different frequency, without a loss of voice or data frames. The A_TRX has to maintain at least its ICAO address and at least two Local IDs (as these may be different before and after handover). Copyright B-VHF Consortium Page: 6-41

77 The representative detailed airborne architecture that was assumed for the initial B-VHF implementation closely follows the existing A/C VHF communications architecture for a modern large A/C (shown in Figure 6-19). The following description is based on the description of existing airborne equipment and procedures provided by the Lufthansa (DLH). NOTE: In Figure 6-19, three A_TRXs have been shown as physical VHF1, VHF2 and VHF3 radio units, respectively. In order to allow for the A/C operation in non-b-vhf areas, physical B-VHF transceivers would have to be backward compatible to the current VDR (ARINC 750) specification. The B-VHF sub-network functions that are required only for the data link operation (e.g. DLS sub-layer, entire B-VHF sub-network layer) may be delegated to the (already existing) CMU. CMU is connected to various other systems like FMS, Central Maintenance Computer (CMC), Aircraft Condition and Monitoring System (ACMS) etc. CMU acts as an end system for ATS and AOC data link services and as an airborne router for other onboard end systems like Flight Management System (FMS). NOTE: In some airborne architectures CMU remains as a router, while FMS may implement an end system for AOC or ATS services. CMU has direct interfaces to Printer and Multi-purpose Control and Display Units (MCDU) and on new Airbus aircraft in addition to Dedicated Control and Display Units (DCDU). MCDU is used to communicate with multiple systems such as CMU, FMS, SATCOM etc. one at a time. NOTE: MCDU may eventually be used as an extended HMI for B-VHF services, e.g. selective voice, providing similar functionality as for SATCOM sub-network. This may however require wiring modifications at the airborne side. The Airborne B-VHF sub-network layer within the CMU will be responsible for preserving the sub-network data link connections during handovers. As long as the next B-VHF cell is contained within the current GNI, the airborne A_TRX unit will just re-direct the existing connections to another cell and report the connectivity change to the CMU, but the B-VHF SN layer implemented within the CMU will not report the connectivity change to the ATN router. The CMU may not be able to provide support for non-atn data link services (e.g. FL broadcast, RL regular transmission of A/C parameters). These operational services (that are functionally outside the B-VHF system) may eventually be implemented within the FMS. New transport aircraft carry 3 VHF radios (VHF1, VHF2, and VHF3). All three radios can be independently used for different purposes at the same time. Two of them (VHF1, VHF2) are used for voice communications, the third radio (VHF3) system is dedicated for data link, but can also be used for voice communications in case of VHF1 or VHF2 failure. Each radio is directly connected to its dedicated antenna. Typical aircraft have two top and one bottom antennas. Switching or coupling of antennas is not foreseen in ARINC characteristics. Per procedure, VHF1 radio is normally used for ATC communications, while VHF2 is used to monitor emergency channel during cruise flight. In terminal area VHF2 is also frequently used for AOC voice communications and may be used to listen to ATIS on routes where ATIS information is not available via data link. The aircrew members use VHF2 radio for these purposes at their own discretion (no controller s permission is required). Copyright B-VHF Consortium Page: 6-42

78 Both pilots are always listening to VHF1, VHF2 (and/or VHF3, if required), but normally only one pilot (not flying) is responsible for communications. In TMA where the pilot not flying may be busy with non-atc communications, the pilot flying directly communicates with ATC. RMP 1 RMP 2 RMP 3 MCDU DCDU V D V D V D ARINC 429 ARINC 429 ARINC 429 FMS VHF1 VHF2 VHF3 ARINC 429 ARINC 429 Audio/PTT ARINC 429 Audio/PTT ARINC 429 AMS CMU1 CMU2 (optional) ARINC 429 Audio/PTT Audio/PTT ARINC 429 COM 1 COM 2 COM 3 T T T T R R R R COM 1 COM 2 COM 3 ASP 1 ASP 2 ASP_3 T T T T R R R R COM 1 COM 2 COM 3 T T T T R R R R Figure 6-19: Representative B-VHF Airborne Architecture Clearances will be received by both pilots. The pilot flying will e.g. select the new altitude and the pilot not flying will readback what has been selected by the pilot flying (and not what he has directly heard from the controller). When switching from one sector to another, the pilot that is responsible for the communications adjusts the new VHF frequency on the Radio Management Panel (RMP). RMPs are located in cockpit and VHF radios are installed in electronic bay (both connected via ARINC 429 interface). NOTE: This interface is uni-directional. Current ARINC specification does not foresee any possibility for a VHF radio to send anything back to the RMP(s). Each RMP has access to VHF1/2/3 radios, but also to other communication/radio navigation systems. RMP is used to tune one of the HF/VHF transceivers and radio navigation receivers. Additionally an RMP indicator annunciates when a transceiver that is Copyright B-VHF Consortium Page: 6-43