UAS C3 Channel Saturation Study Final Report. Deliverable 5

Transcription

1 EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION EUROCONTROL UAS C3 Channel Saturation Study Final Report Deliverable 5 Edition Number : 0.6 Edition Date : March 2010 Status : final report Intended for : General Public EUROPEAN AIR TRAFFIC MANAGEMENT PROGRAMME

2 UAS C3 Channel Saturation Study Final Report Deliverable 5 DOCUMENT CHARACTERISTICS TITLE UAS C3 Channel Saturation Study Final Report Deliverable 5 EATMP Infocentre Reference: Document Identifier Edition Number: 0.7 Edition Date: March 2010 Abstract This report describes the work undertaken on a study of the spectrum required to support Unmanned Aircraft System (UAS) in the future. The Command and Control (C2), and Communication link (C3) between the UA and the remote pilot is vital for the safe and efficient operation of the UA. The C3 link requires adequate spectrum to enable it to support reliable communication. By use of fast time simulations of UAS operation in uncontrolled and controlled airspace in the timeframe of 2020, 2030 and 2050, the communication requirements have been determined and from these the spectrum required based on use of representative technologies. The results are compared with those produced by EUROCAE Working Group 73. Keywords UAS C3 C2 Spectrum EUROCAE WG73 ITU S&A Contact Person(s) Tel Unit Holger MATTHIESEN STATUS, AUDIENCE AND ACCESSIBILITY Status Intended for Accessible via Working Draft General Public Intranet Draft EATMP Stakeholders Extranet Proposed Issue Restricted Audience Internet ( Released Issue x Printed & electronic copies of the document can be obtained from the EATMP Infocentre (see page iii) Path: ELECTRONIC SOURCE Z:\projects\EUROCONTROL\C3 channel saturation\wp5 Host System Software Size Windows_NT Microsoft Word Kb Page ii Final report Edition Number1

3 EATMP Infocentre EUROCONTROL Headquarters 96 Rue de la Fusée B-1130 BRUSSELS Tel: +32 (0) Fax: +32 (0) Open on 08:00-15:00 UTC from Monday to Thursday, incl. DOCUMENT APPROVAL The following table identifies all management authorities who have successively approved the present issue of this document. AUTHORITY NAME AND SIGNATURE DATE Please make sure that the EATMP Infocentre Reference is present on page ii. Project Officer MATTHIESEN Holger March 2010 Edition Number: 1 Page iii

4 DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document. EDITION NUMBER EDITION DATE INFOCENTRE REFERENCE REASON FOR CHANGE PAGES AFFECTED /3/10 Original All Page iv final report Edition Number;1

5 CONTENTS 1. Introduction Background Objective Structure of Report Terminology Study Context and Approach Context Approach Simulation Tools FLAME (FLexible Airspace Modelling Environment) Traffic Pattern Traffic Sample Generator Trajectory Generation Aircraft Modelling Event Analysis FLAMENCO Data Communication Requirements for a Single Unmanned Aircraft Command and Control ATC Communications Voice Communications Data Communications Data Link Performance Requirements Sense and Avoid Aircraft target track message Resolution advisory message Weather Radar Message Terrain Avoidance Real time video...26 Edition Number: 1 Page v

6 4.4 Priorities Overheads Uplink Messages Downlink Messages Overall Requirement for a Single UA UAS Deployment Scenario Scenario Creation Methodology Scenario Workshop Outputs UAS Categories Simulation Volume of Interest UAS operating in VOI Simulation Scenarios Aggregate Bandwidth Requirements for Control and Non-payload Communications of Unmanned Aircraft FLAME simulation Communication Events C2 events See and Avoid events video: See and avoid events proximity to other aircraft ATC messages in controlled airspace ATC messages in uncontrolled airspace Events Results Throughput requirements Uplink Calculation Method Downlink Calculation Method Throughput rate results Spectrum Requirement Analysis Introduction L-DACS Spectrum Calculation Theoretical Terrestrial Data link Technology Assessment Bandwidth Required per Cell Frequency Management Spot beam Satellite Technology Assessment...38 Page vi final report Edition Number;1

7 7.5 Spectrum Requirements Comparison of Work with WG Approach Single UAS Modelling WG-73 Data Transfer Requirements for a Single UA Comparison of Single UA Data Transfer Requirements UAS Deployment Scenario Analysis WG-73 UAS Deployment Scenario Comparison of UAS Deployment Scenarios Bandwidth Calculations WG-73 Bandwidth Calculations Radio Technology and Network Factors Frequency Management Bandwidth Calculation Model Comparison of Approaches Conclusions and Recommendations Overall Comparison with WG-73 methodology Spectrum results Video Satellite Emerging technologies Recommendations References...38 A. FLAME DESCRIPTION...38 A.1 Introduction...38 A.2 Trajectory Generator with ATC...38 A.3 Flow Manager...38 A.4 Traffic Sample Generator...38 A.5 Traffic Display...38 A.6 Aircraft Modelling...38 A.7 Airspace Structure Modelling...38 A.8 Conflict Resolution...38 B. UAS Deployment Scenarios...38 B.1 Draft Scenarios...38 Edition Number: 1 Page vii

8 B.2 Workshop Meeting Minutes...38 C. Data Communication requirements for a single UA...38 C.1 Airport surface...38 C.2 Approach...38 C.3 Cruise...38 C.4 Event driven airport surface...38 C.5 Event Driven - Approach...38 C.6 Event Driven - Cruise...38 D. Aggregate Bandwidth Requirements for Control and Non-payload Communications of Unmanned Aircraft...38 D.1 Generic Communication Events...38 D.2 Events per UA Category...38 E. Abbreviations...38 Page viii final report Edition Number;1

9 UAS C3 Channel Saturation Study Final Report Deliverable 5 1. INTRODUCTION 1.1 Background Currently Unmanned Aircraft Systems (UAS) operate only in specifically reserved areas of segregated airspace. However, considerable interest and effort is being expended world-wide into the development of technologies, procedures and standards to allow UAS to become fully integrated into the Air Traffic Management (ATM) environment in non-segregated airspace. The aim within industry is for UAS to operate as legitimate airspace users within the context of the Single European Sky (SES), SES ATM Research (SESAR) and beyond. Aviation is, justifiably, a risk-averse and safety-conscious industry. The introduction of a new form of aviation into this domain is slow and difficult since it must be introduced in such a way as to have no detrimental impact on the overall safety, security, capacity and efficiency of the ATM system. It is therefore important that all these factors are proved before UAS are allowed unrestricted access to the ATM environment. The UAS will represent new challenges as well as new opportunities for the design of the ATM of the future in the context of both the Single European Sky (SES) and in other parts of the world. Although consideration has been given as to how the UA will integrate into non-segregated airspace it is important to consider the impact that multiple UAS will have on the communications channel. The communication link between the Unmanned Aircraft (UA), remote pilot and Air Traffic Control (ATC) is an important element of the UAS system to ensure safe and efficient operation. The Control and Control (C2) of the UAS has to be supported by this communication link. In addition sense and avoid (S&A) information must also be conveyed in a timely manner to the remote pilot. Lastly, ATC communication, if relayed through the UAS, must also be conveyed over the communication link. Consequently the three main functions that the communication link must support are: Command and Control (C2); Sense and Avoid (S&A); ATC relay (voice and data). This communication link is designated the Command and Control and Communication link (C3) and is vital to the safe operation of the UAS. To ensure high integrity and availability of the C3 link, it must operate in protected spectrum. The spectrum requirements will be the subject of the next World Radio Conference in and preparation work is underway to support this topic. EUROCAE Working Group 73, developing standards for UAS, has undertaken as a study on spectrum requirements for the C3 link in the timescale of This work was carried out in parallel with 1 Item To consider spectrum requirements and possible regulatory actions, including allocations, in order to support the safe operation of unmanned aircraft systems (UAS), based on the results of ITU R studies, in accordance with Resolution 421 [COM6/8] (WRC 07). Edition Number: 1 final report Page 1

10 similar work by the International Telecommunications Union (ITU) Working Party 5B. The conclusion of this work is that the total UAS global spectrum requirements are: 34 MHz for a terrestrial LOS system, 49 MHz for a spot-beam satellite system. These conclusions were reached based on a set of assumptions and theoretical considerations on the operation and deployment of UAS. 1.2 Objective The objective of this study was to adopt a complementary approach using three timeframes for UAS deployment scenarios in representative high density airspace in as realistic environment as possible A fast-time simulator and a communications model was then used to determine spectrum requirements to support the C3 requirements for each of the scenarios. The simulations performed considered three timeframes of 2020, 2030 and 2050 each bringing increasing levels of manned and UA traffic. The study undertook modelling and analysis of these multiple UAS operational scenarios so as to: Assess the overall UAS spectrum requirement and communication performance (such as latency and reliability) and associated rules of use which would be required to support unconstrained UAS operations into the medium to long term (2020, 2030 and 2050); Assess the ability of the EUROCAE WG73 defined UAS C3 spectrum requirement to fulfil the C3 data transmission requirements for the modelling scenarios used within this study; The fast time model used was the FLexible Airspace Modelling Environment (FLAME) model which generated all the manned and unmanned aircraft traffic within the volume of interest based on realistic traffic patterns. Following traffic creation the simulated area will generate a communication load based on operations occurring within the area and simulated timeframe. Once all communication traffic for each of the scenarios, the communication model, FLAMENCO, was used to assess the communication requirement against three possible technology implementation options to assess channel saturation and generate a global spectrum requirement. In addition a review was undertaken on the EUROCAE WG73 methodology and compared and contrasted with that used in this study. 1.3 Structure of Report The report is structured as follows: Page 2 final report Edition Number;1

11 Section 1 provides a brief background to the project Section 2 provides a context to this study with an explanation of UAS and its operating environment. It also discusses the approach taken within this C3 channel saturation study. Section 3 gives an overview of the simulation tool FLAME and the method in which it was used to calculate communication requirements Section 4 gives an overview to the data communication requirements for a single UA. It reviews the data elements that may be used by a UA in operation across different phases of flight. Section 5 provides a description of the three deployment scenarios that are used within the simulation. This section presents the operational environment and attributes of the simulation Section 6 reviews the aggregate communication requirement for the multiple UAs operating within the deployment scenarios as described within section 5. Section 7 provides a spectrum requirements analysis based on representative technologies Section 8 contains conclusions and recommendation to the study 1.4 Terminology The following terminology is used in this report and has been developed by the study team. Note: A list of abbreviations is contained in section E. UA (Unmanned Aircraft) is an aircraft which is designed to operate with no human pilot onboard (EASA). Aircraft operated without the possibility of direct human intervention from within or on the aircraft. UA Application is the type of operation that the UA is performing within the simulation. The application encompasses the transit of a UA to and from the UA Mission Area. UA Type is similar to aircraft type and defines the characteristics of a UA. UAS 2 (Unmanned Aircraft System) - The totality of unmanned aircraft, and system elements necessary to enable the servicing, maintenance, security, taxiing, takeoff/launch, flight and recovery/landing of unmanned aircraft, and the elements required to accomplish its mission objectives. The system elements typically include: 2 As noted within ICAO there may be a replacement of pilotless and unmanned with remotelypiloted when referring to an unmanned aircraft for which a pilot is directly responsible. But current convention is used within this document. Edition Number: 1 Page 3

12 Unmanned aircraft Pilot stations Software Health monitoring Communication, control & data links Data terminals Payload (s) Launch & recovery elements Flight termination systems Support & maintenance equipment Power generation, distribution & supply Air traffic control communications equipment Handling, storage & transport equipment All required documentation related to aforementioned Operating personnel UA Mission Area the area or trajectory of the UA flight. In practical terms this means a set of route points and altitude defining an orbit or a search pattern over an area of sea, a pipeline, a road, etc. Scenario - A description of all the relevant features and activities connected with a particular course of action, event or situation. Specifically in this study a scenario includes general characteristics about the traffic environment within the simulation area and detail of anything that may affect the communication events Volume of Interest (VOI) A volume of airspace (250NM in diameter up to FL600) positioned in representative busy airspace i.e. centred on London. The study is examining the communication events relevant to C3 in this volume. Communication Events each scenario is designed to create multiple realistic communication events these are any activities that would generate some form of communication. For example when a UA crosses an ATC sector a communication event is created. When the overall simulation is run multiple communication events will be generated. These multiple events will create a communication load. Page 4 final report Edition Number;1

13 Take-off Location The location from which the UA initiates its flight and possibly, to which it returns. Transit the route the UA takes between its take-off location and its mission area and to its landing area. Edition Number: 1 Page 5

14 2. STUDY CONTEXT AND APPROACH 2.1 Context A UAS consists of an UA, remote pilot and a Ground Control Station (GCS). The remote pilot will monitor and control the flight from a GCS. Computer systems onboard the UA are able to fly the aircraft along a selected trajectory or route with intervention from the pilot in the GCS as required. At the same time, flight instruments and sensors are continuously monitored, and the pilot can be alerted to any abnormal condition or event. As a consequence, the pilot in the GCS spends more time monitoring systems and flight progress, rather than manually operating a joystick or control column however his ability to intervene must be available at all times. In addition the remote pilot, when flying the UA in controlled airspace, will need to monitor and respond to instructions from the ATC authority. This requires that the remote pilot interacts with the As described in section 1, the connection between a UA and its GCS is termed the C3 link and supports all communication with UAS for the functions of: Command and Control (C2) of the UA, comprising of the two-way exchange of messages related to flight progress, status and updates; Air Traffic Control (ATC) communications to enable reports to ATC, receipt of flight information and to react to ATC clearances and requests; Information to/from the Unmanned Aircraft (UA) related to Sense and Avoid (S&A), terrain and weather, in order to meet ATC requirements for separation assurance, collision avoidance, terrain and obstacle avoidance etc. There will always be a need for a legally responsible individual (i.e. pilot-in-command ) to be in control of the UA at all times regardless of the level of autonomy of a UA. The pilot remains legally responsible for the aircraft and must override the automated systems when necessary in order to comply with ATC instructions, or to deal with emergency situations. The communication link between the pilot and the UA (i.e. the C3 data link) must have high availability and integrity to prevent control of the aircraft being lost. It should be noted at this stage Command and Control (C2) link is the UA to pilot command and control link responsible for allowing the pilot to carry out all necessary control functions. The term C3 is used to describe the ATC to pilot link via the UA and is the last element in the system and is the focus of this study. Assuming general principles of equivalence with manned aircraft, for a UAS to obtain airworthiness certification requires a C3 data link with high availability and integrity between the GCS and the UA. To achieve this, the C3 data link must: Page 6 final report Edition Number;1

15 Operate in protected aeronautical spectrum with sufficient bandwidth to meet future requirements Have the capacity to allow full control of the UA from the ground in all operating conditions, to enable response to ATC instructions, or in the event of an emergency situation Provide monitoring of on-board control and situational awareness systems Provide uplink/downlink voice and data link channels for ATC communications Comply with appropriate technical standards to ensure the required Quality of Service (QoS) is achieved (i.e. availability, integrity and latency) Use a secure mode of operation to prevent unlawful/unauthorised control of the UA at any stage during flight Be spectrally efficient, and have the capacity to meet anticipated demand Table 2-1 below illustrates the envisaged operation of a UAS and other air traffic in shared airspace, showing ATC voice/data transmissions and UAS data link with a terrestrial ground station. The possible use of satellite communications for the UAS data link is also shown. (For completeness air/ground surveillance data links are also shown although this is outside the scope of this study). The detailed data elements of each of the three types of communication are described in section 4. Edition Number: 1 Page 7

16 Table 2-1 UAS Communication Links Specifically what impact will multiple UAS bring to bear on the particular aspect of the ability of any specified C3 channel spectrum (frequency, power, performance and bandwidth) to effectively support in a safe manner all C3 data traffic without degradation. This should be considered in terms of timeliness and integrity of the C3 data traffic, as a function of the number of UAS using such channel. In a particular volume of airspace, transmission power and the operational airspace environment are important considerations within this calculation. This study will simulate three unconstrained UAS operational scenarios between The simulations will be used to generate an overall UAS C3 spectrum requirement. EUROCAE WG-73 along with the ITU has performed a numerical analysis on a multiple UAS scenario. The ability of the UAS C3 spectrum requirement to fulfil the C3 data transmission requirements for this studies simulated scenario will be assessed. 2.2 Approach Table 2-2 below provides an overview of the study. The process illustrated was repeated for each of the three timeframes of 2020, 2030, and Page 8 final report Edition Number;1

17 Global spectrum requirements Single UAS C3 requirements Terrestrial system 1 UAS deployment Scenarios 2020, 2030 and 2050 Multiple UAS C3 requirements Global spectrum requirements Terrestrial system 2 Compare with WG73 results Global spectrum requirements Satellite system Table 2-2 Overview of the study To determine the C3 requirement, it has been assumed that the combined C2, S&A and ATC communications are multiplexed onto a single C3 channel from the UA to the Remote Control Station (RCS) where the remote pilot is situated. This is illustrated in Table 2-3 below. The left hand side of the diagram represents the ATC system which generates voice and data link communications. The central box represents the UA acting as the communications relay for the ATC and the right hand side box represents the GCS. The focus of this study is the C3 link between the UA and the GCS to support all the required functions as shown in the dotted ellipse. Edition Number: 1 Page 9

18 ATC Data service ATN protocol stack Video S&A functions Separation assurance C2 functions C2 functions S&A functions ATC voice ATC Data service ATC system Protocol bridge ATN protocol stack ATC data link radio ATC data link radio DN UP Vocoder 4.8kbps Link & Physical Link & Physical ATC voice radio - analogue ATC voice radio - analogue UA UP DN C3 GCS Table 2-3 Overview of the communication chain The initial step was to define the required C3 elements to operate a single UAS. The next was to define an operational context for UAS deployment in the 3 scenario timeframes and estimate the numbers of UAs operating into scenario. By combining the single UA data elements and the deployment scenarios, the overall data transfer rate for multiple UAs was determined using a fast time simulation FLAME. The FLAME fast time simulation and modelling tool was used to produce trajectories for the deployment scenarios. From these trajectories the communication events were derived, which drive the dynamic loading on the C3 links. These events represent aspects of ATC such as handover, clearances and sense and avoid detections of proximate traffic. The FLAMENCO communications model was used to analyse the C3 information requirements for the Volume of Interest (VOI) of the study. FLAMENCO used representative technology parameters to determine the amount of spectrum for each system to support the C3 communication requirement number of UAS to be serviced according to the cell size taking into account three candidate technologies. The aggregate data transfer to meet the information exchange requirements for multiple UAS in the deployment scenarios will be determined. By taking account of spectrum sharing and frequency re-use, the total (minimum) amount of spectrum required to service the information exchange requirements for the scenarios will be calculated. Page 10 final report Edition Number;1

19 Finally, the total aggregate spectrum required was calculated according to the spectrum management, spectral efficiency and frequency re-use techniques used. Edition Number: 1 Page 11

20 3. SIMULATION TOOLS This section describes the two main simulation tools used in this study. 3.1 FLAME (FLexible Airspace Modelling Environment) FLAME (FLexible Airspace Modelling Environment) is a suite of fast-time simulation software developed by QinetiQ for use in studies of concepts for future air traffic management systems. It was designed to simulate commercial traffic over a large area of central Europe typically spanning 7 degrees of latitude and 16 degrees of longitude, from the UK to the Mediterranean. FLAME is a modular fast time simulation; a complete simulation runs in several stages from data files, requiring no real-time human input. The stages of the simulation are: Traffic pattern preparation Traffic Sample Generation (TSG) Trajectory Generation (TrajGen and atc1) Filtering and analysis The programmes TrajGen and atc1 are variants of the same process. TrajGen calculates trajectories from the traffic sample, each trajectory being calculated independently of other trajectories. Atc1 considers all of the trajectories and attempts to calculate them while maintaining separation minima. Traffic sample routing and timing may be changed to achieve this. Page 12 final report Edition Number;1

21 Schematically, these stages are represented in Table Traffic Pattern TSG Traffic Trajectory File Filter & Analysis 3-1 Table 3-1 FLAME Modular Design Events A more comprehensive description of the FLAME modules is given in Appendix A Traffic Pattern The TSG uses the concepts of a traffic pattern and a traffic sample. The traffic pattern is built up from an analysis of traffic data from EUROCONTROL Central Flow Management Unit (CFMU). The traffic pattern comprises a set of traffic groups. For each traffic group, airports grouped by geographical region are identified and the numbers of flights between pairs of airports in the group are counted. Also recorded are the relative frequencies of flights between different airport pairs and the aircraft types used. Each traffic group is a statistical pattern of traffic for that geographical region. It specifies the number of flights in and out per hour, the airport pairs that aircraft fly between, the aircraft types, and their call sign prefixes. The resulting traffic pattern consists of a set of traffic groups for relatively small areas e.g. UK_internal, France_internal, through to wider groupings like UK_westbound, UK_eastbound, western_europe_internal, Western_Europe_external. For past studies the traffic pattern was generated by processing CFMU flight plan data. To grow a traffic pattern, i.e. to increase the number of flights, the hourly rates of flights can be increased. The pattern itself can be modified by changing the statistical pattern of airport pairs and aircraft types within groups. For C3, only the hourly rates were changed for background manned flights, and new traffic groups for UAs added. To reduce computer run-time, all traffic groups not Edition Number: 1 Page 13

22 including airports that were not within the simulation area of interest, and not likely to generate overflights, were excluded. The simulation area is described within the deployment scenario in section 5. The CFMU traffic data provides representative data across Europe which has been grown with time. Based on EUROCONTROL STATFOR forecasts the aircraft traffic in this study has been assumed to double every 15 years [11] Traffic Sample Generator To generate a traffic sample the TSG uses a random number generator to pick for each traffic group in the traffic pattern, the required number of flights per hour, such that their departure, destination, and aircraft type comply with the statistical pattern in that traffic group Trajectory Generation TrajGen takes the traffic sample and using the airspace definition calculates the 4D paths that the simulated aircraft take. The routings in the traffic sample are extended if necessary using airways and TMA routes defined in the airspace file. The TrajGen variant atc1, in addition, attempts to ensure separation of flights by level changes, vectoring, re-routing and delaying. The resulting flights can therefore be very different to the flights defined in the traffic sample. For the C3 study, the atc1 variant was used for all runs Aircraft Modelling FLAME uses a simplified model of aircraft performance. Aircraft types are either jet or turboprop, further divided into large, medium and small. A flight is assigned one of these aircraft types and an additional weight factor which is an integer between 1 and 9. Vertical speeds are based on a statistical study and analysis of radar data of all air traffic, modified according to the FLAME aircraft type and the weight factor. Cruise speed depends only on the type jet or turboprop. This provides a realistic range of aircraft performance in a large scale simulation but does not allow introduction of new types with specific performance characteristics. For this study new aircraft models were introduced for UAs as described below Larger UAs The existing FLAME aircraft modelling and simulated routing lends itself to modelling larger commercial UAs (e.g. category 4 and 5 unmanned freight aircraft) that would behave in much the same way as present day commercial transport aircraft. UAs falling into this category can be simulated in FLAME by inserting traffic groups consisting solely of UAs into the traffic sample, UAs being identified for the analysis process by a distinctive call sign. Because of the volume of interest chosen for the Page 14 final report Edition Number;1

23 study, the UAV traffic was concentrated in UK_internal and France_internal, with some flights in other groups that include or over fly the UK Smaller UAs The existing FLAME aircraft modelling does not lend itself easily to simulation of the smaller UAs (e.g. category 2 and 3) that might be used to perform, for example, lower (or much higher) altitude surveillance tasks, and have much lower speeds than commercial jet and turboprop aircraft. The modular nature of FLAME was exploited by creating a version of TrajGen to simulate lower level UA traffic only. This version uses a UA only traffic pattern and has a simple aircraft performance module to provide suitable airspeeds and vertical speeds for category 2 and 3 UAs. Flights were simulated with cruise levels lower than FL100, having the same airport for departure and arrival, and fly small orbits or circuits at a destination before returning to base Event Analysis To determine the required communication, events are generated at appropriate points during the flight for each of the simulated UAs based on the single UAS data requirements see section 4. FLAME produces a comma, separated variable (CSV) file containing all events for each second during the period of the simulation. All of the communication events created by the UAs within the simulation over an hour long period are then processed within FLAMENCO. 3.2 FLAMENCO FLAMENCO is the bespoke tool that uses the output of FLAME to calculate the bandwidth requirements for a given data throughput requirement for uplink and downlink in each scenario. This is illustrated in Table 3-2. FLAMENCO utilises the events information generated by FLAME to determine the instantaneous data requirements in each scenario. Edition Number: 1 Page 15

24 FLAME Input FLAME Output FLAMENCO Input Scenario 1 Scenario 2 FLAME Communication Events FLAMENCO Scenario 3 Table 3-2 FLAME and FLAMENCO Interaction In order to appropriately size the C3 data link, it is important to understand the amount of data in each category, its criticality/importance, and when it needs to be sent. For example, ATS communications, and certain C2 messages will undoubtedly be safety critical, and will be given the highest priority. Information such as outside air temperature or the down linking of engine management data is likely to be assigned a much lower priority. In essence, the data link must have capacity available to instantly send any high priority data that it is presented with. Page 16 final report Edition Number;1

25 4. DATA COMMUNICATION REQUIREMENTS FOR A SINGLE UNMANNED AIRCRAFT This section defines the data elements required on the C3 data link for different phases of flight for a single UAS. The C3 requirements will depend on the type of UAS category and phase of flight and have been determined based on a combination of information developed by the study team and data requirements that are accepted within the community. For this study, it is assumed that the Unmanned Aircraft (UA) acts as a communications relay for ATC communications with the pilot. (Note - this is similar to architecture Aircraft Relay 2 architecture as described in [4]). Consequently the three main functions that the C3 link must support are: Command and Control (C2); ATC relay (voice and data); Sense and Avoid (S&A). These are supported on a common C3 channel that is the subject of the study. Each of these functions has associated data elements, these have been determined along with the size of the data items, the maximum update frequency and priority. The voice and data exchange requirements will be dependent on (i) the function of the UAS and (ii) the airspace that it is operating in. Similarly, for S&A, the amount of information (e.g. video, surveillance tracks etc.) that needs to be sent down to the ground station to provide situational awareness will be dependent on the environment that the UAS is operating in (i.e. traffic density). For example high density controlled airspace may not require as high a sense capability and requirement, as would a low density uncontrolled airspace environment, because the separation provision is being provided by ATC. So it is not density alone that determines the bandwidth requirements nut also the operational environment.the use of the data elements in example scenarios will be defined in later phases of the study. The results presented in this report are technology independent. In a later phase, Data Elements An initial review of the type of C3 data link requirements for the different categories of UAS was carried out at a study Workshop (see Appendix B.2 and simplified to three phases of flight as shown below. The table also identifies flight phases which will be used in the study and they have been defined as follows: Airport Surface this covers UAS operations from pre-flight to take-off and from landing to stationary position; Approach area this covers the post take-off, climb, approach to land and landing phase; Edition Number: 1 Page 17

26 Cruise/Mission this covers the phase in which the UA has reached its normal cruise level on route to its mission area and the mission itself. UA Category Airport Surface Approach area Cat 1 C2 C2 C2 Cat 2 C2 C2 C2 Cat 3, 4, 5 - as above plus ATC ATC ATC Video Video Video Cruise/Mission - Terrain avoidance Terrain avoidance - Weather avoidance Cat 6 C2 C2 C2 ATC ATC ATC Weather avoidance Table 4-1 Preliminary Review of C3 Requirements per Phase of Flight For each data element, the size of the elements is specified (in terms of the number of bits required and the maximum required update rate). These have been defined following revision of work carried out within the ASTRAEA project [5] 4.1 Command and Control A range of typical functions to control and monitor the flight of a UA has been determined. These include for example Consolidated flight control input + brakes; Propeller Pitch; Consolidated primary instrument data (5Hz); Consolidated primary instrument data (2Hz); Nav system derived position; Consolidated 0.1 Hz data; Consolidated altimeter; Other flight systems (commands/data); Consolidated system health data; Undercarriage status (feedback); Flight Management System (FMS) data upload; Outside air temperature; Other non-critical data. For example, a transponder Mode A code comprises 4 x 3 bit characters, giving a word length of 12 bits. The pilot would only be expected to change the Mode A code Page 18 final report Edition Number;1

27 occasionally, so the update rate would be very low (a conservative value of 0.1 Hz has been assumed). This message is assumed to be a Priority 2 message therefore means that any input changes do not have to take place for 0.52 seconds. In contrast to this, consider the requirement for downlinking of the Attitude Indicator (AI) information. This falls within the category of a primary control instrument data; hence when the UA is being manually flown or during an emergency, this data element will provide critical feedback data to the UA pilot, upon which subsequent control input will be based. In the example provided, a 24-bit word and an update rate of 5 Hz is considered necessary for safe operation. Furthermore, as this is Priority 1 data, each update must take no longer than 130 milliseconds to reach the GCS. Although the data values are considered to be broadly representative, it is acknowledged that many of these values will need to be refined over time as systems and standards evolve. Regardless of actual values used, the calculation process described here can be repeated for different values at any stage, and the study modelling tool FLAME allows data values to be amended easily. Command and control messages are essential elements of communication in order to ensure the safe expedition of a UA. The data requirements for the assumed C2 message (minus overheads) are summarised below, it is recognised that with the evolution of systems and standards these data values may change. Details of these messages can be found in [5] and have been based on inputs from the ASTRAEA project. It is assumed within the simulation that C2 messages will occur constantly throughout the simulation at a standard rate. 4.2 ATC Communications There is a critical need to maintain communications between ATC and the UA pilot at all times when separation services are provided by ATC. The need to ensure good availability for ATC air-ground communications has long been recognised. The implication for UAs is that the C3 communications path between the GCS and the UA is engineered to provide equivalent (or superior) QoS performance to that of the existing air-ground communications system. When ATC communications are lost, ATC will invoke a range of procedures to reestablish communications with an aircraft. Even a short break in communications can result in a significant increase in workload as the controller attempts to restore communications. As a result, ATC may be distracted from managing other traffic, and this can potentially lead to an erosion of separation. As a consequence, loss of communication is treated seriously by ATC and is usually reported as a safety related incident; also if the loss of communications is intentional then security implications would be a significant risk to ATC. Such is the importance of this issue that an aircraft with a record of repeated failure could expect to be grounded by the airworthiness authorities until problems are rectified. This is another reason why it is essential for UA communications to be engineered to provide good integrity and availability, and to have appropriate means of avoiding situations that result in a total loss of communications with ATC. Edition Number: 1 Page 19

28 Another consideration is the confidence and trust that ATC will have in a UA s ability to operate accurately and reliably. If a pilot provides clear and succinct responses to ATC instructions and accurately follows its intended route, ATC will have confidence in its ability to operate safely and reliably. Conversely, an aircraft with unreliable or broken communications, or which erratically deviates from its intended route will give ATC cause for concern. The performance of the data link will be highly visible to ATC through the quality, continuity and latency of relayed voice communication messages. Any perceived deficiency in the quality or reliability of these messages may lead ATC to conclude that other aspects of the UA are also deficient, and not fit for purpose. In summary, if good quality, reliable voice communications are provided over the data link, ATC will have a level of confidence in the UA s ability to operate safely and reliably. ATC communications are assumed to be relayed via the UA. As both ATC and the GCS are on the ground, it is recognised that at some stage it may be feasible to have a direct link between ATC and the UA pilot. However, for the purposes of this study, it is assumed that the UA acts as a relay to ensure the most demanding spectrum requirement can be achieved. Within this study the voice performance requirements from [6] have been assumed; due to their demanding nature it is assumed that an always on channel is required to facilitate ATC voice communications with a vocoder data rate of 4.8 kbps as well as ATC data communications (on both the uplink and downlink channels). The need for an always on channel is justified for the following reasons: The UAV pilot may need to transmit a voice message to ATC or other aircraft at anytime, and such messages could be critical to flight safety. It is not acceptable for ATC voice messages to be blocked or delayed due to other traffic on the data link. The same is true for data communications. As with manned aviation, pilots are expected to monitor the ATC voice communications channel. Exchanges between ATC and other pilots provides valuable situational awareness, and allows an orderly 2-way exchange of messages between ATC and individual aircraft to take place. Although ATC data messages will be used routinely, the need for a voice communications channel will remain for urgent or non-routine messages. Consequently, it is entirely possible that there will be a need to simultaneously generate ATC voice and data messages, and given the potential safety criticality of both, sufficient capacity for an always on voice and data channel must be assigned. ATC communications are assumed to be relayed via the UA. As both ATC and the GCS are on the ground, it is recognised that at some stage it may be feasible to have a direct link between ATC and the UA pilot. However, for the purposes of this study, it is assumed that the UA acts as a relay to ensure the most demanding spectrum requirement can be achieved. Page 20 final report Edition Number;1

29 Within this study the voice performance requirements from [6] have been assumed; due to their demanding nature it is assumed that an always on channel is required to facilitate ATC voice communications with a vocoder data rate of 4.8 kbps as well as ATC data communications (on both the uplink and downlink channels) Voice Communications ATC communications are currently performed largely by voice communications. Although future ATM concepts e.g. the SESAR ATM Target Concept [7] foresees the gradual move to data communication for ATM, voice will always be required for emergency or non-routine operations. Under these conditions voice performance requirements will be similar to those achieved today. Ref [6] provides the voice performance requirements for ATS as shown in Table 4-1. It also points out that the quality of the voice must be sufficient to meet the operational requirement in the airspace where it is used. Quality includes user acceptability and intelligibility. Service Type Party-line Broadcast Domain Airport TMA En route Airspace Density Call Establishment Delay High Density Low Density High Density Low Density High Density Low Density Oceanic, Remote, Polar High Density Low Density 100 ms 100 ms 100 ms 100 ms 100ms 100 ms 100 ms 20 s 20 s Voice Latency 130 ms 130 ms 130 ms 130ms 130 ms 130 ms 130ms 485 ms 485 ms A P A U Table 4-2 Voice Performance Requirements Based on these demanding requirements, for this study it is considered that the use of an always on channel is required. To achieve the required quality of speech commensurate with minimised data rates and vocoder processing delay a rate of 4.8kbps has been chosen. ALL ALL Data Communications ATM will gradually become based on data communications as the primary means of communications. ATM will be supported by a range of data link services each with their own QoS depending on the operational context in which they will be used. Table 4-3 below shows the range of the services grouped into the type of function they support [6]. Data Communication s Management Services (DCM) Clearance/ Instruction Services (CIS) Flight Information Services (FIS) Advisory Services (AVS) Flight Position/ Intent/ Preference s Services (FPS) Emergenc y Informatio n Services (EIS) Delegated - Separatio n Services (DSS) Miscellaneou s Services (MIS) Data Link Logon (DLL) ATC Clearance Data Link Automatic Terminal Arrival Manager Informatio Surveillance (SURV) Data Link Alert (D- In-Trail Procedure Air-to-Air Self Separation Edition Number: 1 Page 21

30 ATC Communication Management (ACM) (ACL) Departure Clearance (DCL) Downstrea m Clearance (DSC) ATC Microphone Check (AMC) Data Link Taxi (D- TAXI) 4 (COTRAC) Information Service (D-ATIS) Data Link Operational Terminal Information Service (D-OTIS) Data Link Operational En Route Information Service (D-ORIS) Data Link Significant Meteorologica l Information (D-SIGMET) Data Link Runway Visual Range (D-RVR) n Delivery (ARMAND ) Dynamic Route Availability (DYNAV) Data Link Flight Update (D-FLUP) Flight Plan Consistency (FLIPCY) Flight Path Intent (FLIPINT) System Access Parameters (SAP) Wake Broadcast (WAKE) Pilot Preferences Downlink (PPD) Traffic Information Service- Broadcast (TIS-B) ALERT) Urgent Contact (URCO) s (ITP) Merging and Spacing (M&S) Crossing and Passing (C&P) Paired Approach (PAIRAPP) (AIRSEP) Auto Execute (A-EXEC) Data Link Surface Information and Guidance (D-SIG) Table 4-3 ATS Data link Services As there are many different types of message, only a core set of ATC data messages (based on the parameters stated in the COCR [5]) were included in the simulation. The C3 study uses the FLAME model to determine the rate at which ATC data messages are generated. For each UA in the simulation, ATC data communication events are generated at appropriate times/phases of flight. For example, at the start of each flight, each UA will generate a sequence of messages starting with network log-on (DLL), followed by a departure clearance (ACL), taxi clearance (D-TAXI) and take-off clearance (ACL) etc. DLL ACL ACM D-TAXI D-ATIS Data link Log On used to log onto data link network Clearance Message used for a wide variety of ATC clearances (including departure, flight level assignment, take-off and landing clearance etc) Communications Management used to configure ATC data communications transceivers. Taxi Message used to provide taxi instructions. Aerodrome Terminal Information used to provide runway and weather information for aircraft arriving at, or departing from a specific Page 22 final report Edition Number;1

31 D-ORIS D-SIGMET airport Flight Information - used for a variety of flight information messages En-route Metrological Information - used to provide details of significant weather conditions (wind shear/icing etc) Table 4-4 C3 study ATC Data Link Services A more detailed description of the services is given below Data Link Logon (DLL) The DLL service exchanges information between an aircraft and an ATSU to support other addressed data communications services. The DLL service is executed prior to any other addressed data communications service. It is used to uniquely identify an aircraft and to provide version and address information for all data communications services. Once initiated, DLL provides the flight identification to the avionics, and the remainder of the DLL takes place automatically without Flight Crew involvement. The DLL information must be available for each ATSU that will offer data communications services. The DLL initiation only needs to be completed once for a given flight ATC Clearance (ACL) A Flight Crew under the control of an Air Traffic Service Unit (ATSU) transmits reports; makes requests; and receives clearances, instructions, and notifications using ACL. The ACL service specifies dialogue exchanges via air-ground addressed communications between Flight Crews and Controllers working the specific position/sector associated with the aircraft s physical location. The ACL service may be initiated by either the ground automation/controller or the avionics/flight Crew. Some ACL exchanges, (e.g., altimeter settings and secondary surveillance radar (SSR) transponder code assignments) can be transmitted without Controller review/action. The ACL service consists of the following types of exchanges: ATC clearances, instructions, notifications, and requests; Flight crew requests, reports, notifications, and compliance indications ATC Communication Management (ACM) The ACM service is used for the following: To manage the transfer of data communication authority between sectors and/or ATSUs; To terminate data communications with an ATSU; To issue a change of voice frequency. Edition Number: 1 Page 23

32 When the ACM service is used for transfers between ATSUs/sectors or a change of frequency, it is initiated by one of the following: The transferring sector or ATSU; A request from the receiving sector or ATSU; A request from the Flight Crew. The ACM service consists of the following types of exchanges: Requests to initiate and terminate air-ground control communications; Indication of the next data authority; Voice frequency contact and monitor messages Data Link Significant Meteorological Information (D-SIGMET) The D-SIGMET service provides Flight Crews with advisories of the occurrence, or expected occurrence, of weather phenomena that may affect the safety of aircraft operations. The preparation and issue of SIGMET reports is the prime responsibility of meteorological watch offices. SIGMET information messages are distributed on ground initiative to aircraft in flight through associated ATSUs. The D-SIGMET service consists of the following types of exchanges: Uplink of SIGMET reports Data Link Automatic Terminal Information Service (D-ATIS) D-ATIS provides automated assistance in requesting and delivering air traffic information including: meteorological conditions, operating procedures, runways and approaches in use, and various other information which may affect the departure, approach, and landing flight phases as well as surface operations relevant to a specified airport(s) in any phase of flight (except in the AOA domain outside of the buffer zone) Data Link Operational Terminal Information Service (D OTIS) D-OTIS provides Flight Crews with compiled meteorological and operational flight information derived from ATC, ATIS, Meteorological Aerodrome Report (METAR), Notice to Airmen (NOTAM), and Pilot Report (PIREP) information tailored to the departure, approach and landing phases of flight. The D-OTIS information is updated when the ATIS, METAR, NOTAM, or PIREP components of the OTIS message change by specified criteria or delivery of operational information (e.g., delays, Collaborative Decision Making (CDM) sequences), is considered necessary by ATC. Page 24 final report Edition Number;1

33 4.2.3 Data Link Performance Requirements The performance associated with these data link services are shown in Table 4-5 below. Service Expiration Time (ET)( Required Communication Latency Technical Performance (ET RCTP (TT 95-1 way) 1 way) Continui ty RCTP Integrity RCTP Availability RCTP (per Flight Hour) APT TMA ENR ORP AOA APT TMA ENR ORP AOA CUIT I UCT A P A U ACL E ACM E D-SIGMET E DLL E D-ATIS E D-ORIS E Table 4-5 Performance requirements for chosen ATM data link service 4.3 Sense and Avoid To ensure that appropriate and consistent assumptions about the operation of the onboard Sense and Avoid (S&A) system are applied to the C3 channel modelling, it is necessary to describe the way in which onboard S&A systems are assumed to function. Each UA will have a suite of onboard sensors capable of deriving the relative distance and range between it and other airborne objects. The capability of these sensors will be one of the factors used to determine the flight rules and class of airspace that the UA platform is certified to operate under. For example, for operation under Instrument Flight Rules (IFR) in controlled airspace, it is likely that the onboard capability would only need to detect cooperative targets using SSR or ADS-B. Aircraft operating under Visual Flight Rules (VFR), or outside controlled airspace would additionally need to have the capability to detect non-cooperative targets (e.g. balloons, gliders, ultralights etc). However, in either case, the vehicle must have the capability to avoid aerial collisions to the same extent that a manned aircraft could. In order to be permitted to operate outside segregated airspace, it is assumed that a UAS will have a Sense and Avoid (S&A) system capable of detecting, monitoring/tracking and alerting the pilot to objects near the UA that need to be avoided. It is assumed that the UAV pilot will continuously require S&A information in order to monitor flight progress, make executive decisions or take manual control of the UA if required (i.e. if instructed to take avoiding action by ATC, or in an emergency situation). The types of S&A information and corresponding messages that need to be conveyed to pilot via the C3 data link are described in below. Edition Number: 1 Page 25

34 4.3.1 Aircraft target track message From the EUROCONTROL Surveillance Data Exchange Standard for ASTERIX 021, a track message data block is assumed to have a data block length = 57 bytes. The following assumptions have been made about the generation of track messages: For each aircraft within 1 NM range and ±500 ft height of the UAV: 1 track message every 5 seconds. Assumed to have priority level 1 QoS requirements, latency = 0.13s For each aircraft between 1 and 5 NM range and ±3,000 ft height: 1 track message every 20 seconds. Assumed to have priority level 2 QoS requirements, latency = 0.52s For each aircraft between 5 and 20 NM range and ±5,000 ft height: 1 track message every 60 seconds. Assumed to have priority level 3 QoS requirements, latency = 5.2s Resolution advisory message Resolution Advisory (RA) messages are assumed to have a data block length = 15 bytes. RA messages are generated as follows: Outside controlled airspace, generate resolution advisory messages at a rate of 1 per hour. Inside controlled airspace, generate resolution advisory messages at a rate of 0.1 per hour Weather Radar Message On analysis of the ITU working document it is assumed within this study that the worst case requirement will be used and exclusion of the wind sheer figures has occurred for this analysis as they are less demanding Terrain Avoidance Real time video Terrain avoidance in the form of a ground proximity warning when operating below 1,500ft. This is a monitoring task to ensure constant awareness of terrain. From a safety and certification perspective, it is expected that the SAA performance is at least equivalent to that achieved by the crew of a manned aircraft, and this implies a need for real time video imagery. The ability to observe other aircraft visually is very much dependent on the in-flight weather conditions, convergence angles and closing Page 26 final report Edition Number;1

35 speeds, and physical limitations such as the size and shape of cockpit windows etc. Consequently, the ability for the crew of a manned aircraft to visually detect other aircraft will vary enormously. In good VMC, and with no physical obstructions, the human eye with so-called 20/20 vision can detect an object subtending an angle of one arc minute. Therefore, for a small aircraft with a frontal cross-section of 2 square metres, visual detection would theoretically be possible at a distance of 4.8 km. Of course this distance could effectively be zero metres when flying in cloud, or if the other aircraft approaches from a direction that is obscured. A video system capable of replicating the visual acuity of a pilot would require significant bandwidth. For example, if we were to just consider coverage over 240 degrees of azimuth and 30 degrees in elevation (i.e. what a pilot in a conventional aircraft might be expected to see), then the resolution requirement would be: Azimuth = 240 x 60 = 14,400 pixels Elevation = 60 x 60 = 3,600 pixels Pixels per frame = 14,400 x 3,600 = 51,8 40,000 pixels If we assume that 16 bits are required for colour information (i.e. 65,536 colours), and 25 frames per second are sent, then the total information rate would be: 51,840,000 x 16 x 25 = 20,736 Mbps Of course, coding algorithms have been developed to efficiently compress the video signal without any discernable loss of picture quality. For typical high definition TV systems with 2,073,600 (1920 x 1080) pixels per frame, the compressed data rate for a 25 Hz picture is in the region of 12 Mbps. If we assume that 16 bits are again used to carry colour information, then this represents approximately 1.5% of the raw (uncompressed) data rate. If the same algorithms were used for SAA real time video, then a data rate of approximately 311 Mbps would still be required. Furthermore, it is not known whether the image presented to the pilot in the ground station on a 2- dimensional monitor would enable detection of a conflicting aircraft as effectively as an image viewed directly. Clearly, even with efficient compression techniques, the data rates required for truly equivalent real time video are substantial and beyond what is viable from a technological and practical point of view. It is necessary therefore to postulate how the real time video element of a certified SAA system might work, and what data rates will be required during different phases of flight. These assumptions can be found under the Data Requirements for Real Time Video section heading As already outlined, there are technological and practical issues associated with the provision of real time video. Even if it were possible to send 360 degrees of video in high definition, the UAV pilot would still be faced with the challenge of being able to detect a fast approaching aircraft, and determine from the 2-dimensional image whether or not is was on a conflicting path with his UAV. In practice therefore, it is likely that detection and tracking will be performed by onboard sensors, and the real time video will only be used to provide confirmation to Edition Number: 1 Page 27

36 the operator of any conflict detected. For example, radar or LIDAR sensors might detect and track another object 1 km away from the UAV. Knowing the relative azimuth and elevation, video cameras could be cued to zoom onto the object, and this image would then be sent to the pilot as real time video (overlaid with bearing/range data computed by onboard sensors). The video bandwidth requirements for this type of system are now substantially reduced, as coverage is only required for a small area. When the threat has passed, the video stream would be terminated, and the operator would be left with the traffic data display. Note 1: for this study video is activated when a proximate aircraft is within 5NM and within ft. Note 2: if two or more aircraft are detected within this range it has been assumed that the video system will determine the greatest threat and the camera will dwell on that target. Of course, aircraft on the ground, taking off or on approach to land would require a permanent forward-looking real time video image. This would need to cover a relatively wide angle, to show aircraft/vehicles either side of the taxiway, and obstacles beneath the approach path. The following estimates are used to assume the video data requirements for real time video in different phases of flight: Phase of Flight Start-Up and Taxi Mode Forward looking Az Range Pixels El Range Pixels Frame Size +/ / ,073, Frame Rate (Hz) Take-off & Climb Out Forward looking +/ / ,073, Cued +/ / , Cruise Cued +/ / , Approach & Land Forward looking +/ / ,073, Cued +/ / , Table 4-6 Video characteristics By applying earlier assumptions about video compression algorithms, it is possible to estimate the data requirements for real time video to supplement SAA functionality. Phase of Flight Raw Video (Mbps) Forward Looking Cued Total Raw Video Data Rate Compressed Video Data Rate (Mbps) Page 28 final report Edition Number;1

37 (Mbps) Start-Up and Taxi * Take-off & Climb Out Cruise Approach & Land For the purposes of this study a common rate of 13.9Mbps has been used for start-up, taxi, take-off and climb out. Using the assumptions above it is possible to estimate the data requirements for the UAV to provide the GCS with details of proximate traffic that has been detected and is being tracked by its onboard SAA system. Where appropriate for the phase of flight, the data required to provide real time video images is also estimated. Provision is also made for the generation of resolution advisory messages, so that the pilot in the GCS can be advised of the conflict and advised of the preferred escape manoeuvre. 4.4 Priorities All items of data to be carried on the C3 data link are assigned a priority level between 1 and 4. This is to reflect the anticipated quality of service requirements that any C3 data link is expected to require for airworthiness certification. Priority Type of Information Maximum Permitted Latency 1 Real-time safety critical information 130 ms 2 Near real-time safety critical Information 520 ms 3 Low priority safety information 5.2 s 4 Non-safety critical information 20.8 s Table 4-7 List of priorities The priority level of data can have a significant influence on data link performance requirements. In particular, the need to process and deliver any Priority 1 data in 130 milliseconds will dictate the instantaneous capacity of the C3 channel. This is of particular significance given the high proportion (over 90%) of Priority 1 data on the C3 data link. Furthermore, this capacity must be available to send data at the highest update rate (which is assumed to be 25 Hz for voice and video data streams). This is a fundamental difference in approach to the WG-73 methodology where priority is not taken account of. In summary, the C3 study has derived the C3 channel capacity requirements on the ability to deliver all Priority 1 data in a 40 millisecond period, rather than deliver the total data (all priority levels) over a 1 second period. Edition Number: 1 Page 29

38 4.5 Overheads As the C3 data link will be carrying a variety of messages which originate from subsystems within the GCS (in the uplink direction) or sub-systems on the UA (C2, ATC voice, video etc). each must be identifiable, so that it can be routed to the appropriate system when it emerges from the C3 link. GCS UA C2 Addressing (MUX) Routing (de-mux) C2 S&A S&A ATC Data ATC Data ATC Voice Video C3 Channel (Uplink) ATC Voice Video UA sub-systems GCS C&M sub-systems C2 Routing (de-mux) Addressing (MUX) C2 S&A S&A ATC Data ATC Data ATC Voice Video C3 Channel (Downlink) ATC Voice Video Table 4-8 Carriage of Sub-System Data over C3 Link As each sub-system can each generate in the order of 100 messages, we have assumed that up to 1024 different types of messages could be sent over the C3 link, and hence reserved 10 bits for addressing. To prevent malicious or accidental command of a UA, it has been assumed that all C2 uplink messages contain a 16-bit security word, which acts as a key. This is deemed to Page 30 final report Edition Number;1

39 be the minimum requirement to prevent unauthorised control of the aircraft3. Further security protection can be provided through encryption (scrambling) of the data link itself, which can be added as an additional factor in the over all throughput calculation. The total amount of data associated with these overheads will be determined by the rate at which messages are sent. In other words, each time a message is sent, addressing and in the case of C2 uplink, authentication bits must be added. The following tables summarise the total message size when these overheads are included (with a minimal level of security) Uplink Messages Message Type Information Rate (bps) Message Size (information only) Overhead bits Frequency (Hz) Information Rate (including overheads) ATC Voice ATC Data (Determined by FLAME traffic and airspace dependent) 10 Variable Determined by FLAMENCO C2 (Determined by FLAME airspace dependent) Variable Determined by FLAMENCO) Downlink Messages Message Type Information Rate (bps) Message Size bits (information only) Overhead bits Frequency (Hz) Information Rate (including overheads) ATC Voice ATC Data (Determined by FLAME traffic and airspace dependent) 10 Variable Determined by FLAMENCO C2 (Determined by FLAME airspace dependent) S&A Video (200 kbps) S&A Video (1.5 Mbps) S&A Video (13.9 Mbps) 10 Variable Determined by FLAMENCO 250,000 1, ,250 1,500,000 60, ,500,250 13,900, , ,900,250 3 It is recognised that UAS datalink security is a potentially emotive issue, for which there is currently no internationally agreed requirement or standard in place. The approach described in this document does not attempt to propose a solution. However, it does attempt to provide an indication of the range of overheads that might be applied for datalink security. Edition Number: 1 Page 31

40 S&A Surv Determined by FLAME traffic dependent) 10 Variable Determined by FLAMENCO 4.6 Overall Requirement for a Single UA The C3 study is not concerned with calculating the overall requirement for a single UA. Instead, it calculates the peak total data throughput required for all UA activity simulated to take place within a service volume (typically a cylinder of 125 NM radius) located in busy European airspace. This is because the need to meet priority requirements makes the individual UA data rates very bursty, and if considered in isolation, a C3 channel for a single UA would need to be much larger than the average throughput data calculation would suggest. Of course, to have sufficient data link capacity reserved to allow each UAV to simultaneously send all Priority 1 data would be wasteful in terms of bandwidth, spectrum and ultimately cost. In reality, throughput requirements can be met by taking a statistical approach that recognises the combined data requirements of all unmanned aircraft operating in a service volume. Hence, the overall capacity of a data link system serving a number of aircraft needs to be sufficient to ensure that on a high percentage of occasions, the message priority requirements of individual UAVs will be met. Therefore, whilst it is possible to divide this figure by the number of UA operating to derive an average data requirement per UA, it is important to understand the combining process that is used to ensure that any UA can send its high priority data over the data link with a high level of certainty. Page 32 final report Edition Number;1

41 100 95% Probability that a single UA will be able to send all P1 data in any 40 msec timeslot 50 R min = Steady state P1 data x No. UA in service R Max = Peak P1 data x No. UA in service volume 0 0 R Min Data Throughput (bps) R Max Table 4-9 Data Throughput vs. Probability of Meeting Message Priority Requirements Table 4-9 illustrates this principle. The red s-curve shows how the probability of meeting individual UAV message requirements rapidly increases when the combined throughput rate (for the service volume) is increased above R Min. It then increases a slower rate before accelerating towards 100% as the rate approaches R Max. This shows that, due to the datalink s collective unused throughput capacity, it is not necessary to increase R much beyond R Min in order to achieve a high probability. This is a fundamentally different approach to that used by WG-73. Edition Number: 1 Page 33

42 5. UAS DEPLOYMENT SCENARIO An important aspect of this study is the deployment scenario this is the area in which the simulations are run and in which the UAs will be operating. This section describes the three scenarios that were simulated and how the scenarios were created. 5.1 Scenario Creation Methodology Table 5-1 Scenario Creation Methodology As can be seen in Table 5-1 above draft scenarios were created to invoke discussion in the workshop to assist creation of three comprehensive scenarios. The draft scenarios used can be found in Appendix B.1 which were based on the top six applications envisaged within the EASA study [4]. A workshop was held involving technical and operational experts from QinetiQ, NATS and EUROCONTROL to develop three scenarios. Within the workshop agreements on scenario attributes were reached, for example on the types of UAS in operation over different timeframes etc. It was decided that the three scenarios would be based on similar characteristics 5.2 Scenario Workshop Outputs The workshop reviewed current work and activity within the UAS industry and created the following categories of UA to be used when simulating the three scenarios. Page 34 final report Edition Number;1

43 5.2.1 UAS Categories Cat Typical Mission 1 Police Surveillance Traffic Fire Crime Crowd control Security Crop inspection Description These are small applications that can be considered most likely to happen in the short term i.e. a quick win in the UAS market. They will require very little or no infrastructure to operate. UAs will be light weight and easily deployed from any location due to their size and weight. It can be expected that they would be car portable for easy deployment. Hence this type of UA does not require an airport or airfield to be launched from - it is feasible that they will be deployed from any random location within the volume of interest. It is assumed that this category of UAS will only perform short range line of sight operations under VMC conditions. As the UA will always operate near the GCS no onboard S&A is required. Actual UA flight will be hover or very slow flight with electric or small Internal Combustion (IC) engine power. It is expected that these will be more readily deployed in the short term to show the viability of operating UAS however they will perform only very local operations hence no infrastructure capabilities are assumed for this category of UAS. It is assumed for this category of UA that it will be less autonomous than other UA types. Due to the UAs performing low level short range operations they will not be utilising the communication system resources being emulated within our simulation. Hence they are considered to be outside the operating range of our simulation. The point to note about this type of UA is that they are likely to be the first to market and proof that UAs can be used readily. Max Range (NM) Max Height (ft) Edition Number: 1 final report 35

44 Cat Typical Mission 2 Survey Police surveillance Pipeline surveillance Forestry surveillance Traffic surveillance 3 Mapping Photography Police Surveillance Pipeline surveillance Forestry surveillance Traffic surveillance Security Medical Description Category 2 UAS are light aircraft sized so are more substantial in size and weight than category 1. In order to operate the UA will require a grass runway or airfield to perform a departure and landing procedure. The range of operation will be larger than category operating out to 100NM and up to 5000ft enabling beyond line of sight operations but operating under VFR. It is assumed that the UA is only capable of slow flight with a maximum speed of up to 100 knots with a piston or turbo powered engine. There will be some level of ATC interaction due to operational flight level of the UAS category; this could be in the form of ATC providing an advisory or information service. Due to the area of operation the UAS does not receive an Air Traffic Control Service operating under VFR. Capabilities Required: It is assumed the UA will need to be known to ATC and hence must have a transponder For Take-Off and Landing procedures the UA is required to have a Sense and Avoid (S&A) capability. Once airborne the UA will be required to maintain VMC as it is operating under VFR traffic S&A will be required. C2 capability will be required at a normal level of autonomy to operate the UA. Category 3 UAS will encompass the characteristics as described above within category 2. In addition category 3 will also: Operate in both VMC and IMC conditions Assumption that all IFR flights are point to point (will depart from airfield perform flight and land at another destination airfield) and that all VFR flights are out and back (flights will take off, perform flight and will return back to base to land). Max Range (NM) Max Height (ft) Page 36 final report Edition Number;1

45 Cat Typical Mission 4 Maritime surveillance Search and rescue Fire Light cargo Description Category 4 UAS will be light/small aircraft and either turboprop or jet powered. They will operate from an airfield or airport (hard runway) and will take on all the characteristics as described within category 3 Assumption that all IFR flights are point to point above FL100 and that all VFR flights are out and back below FL Heavy cargo Category 5 are larger type operations whereby the UA is a heavy cargo jet size. It is assumed that these will depart from airports with hard runways. Due to the size of the UA flights are IFR only operating on a point to point basis. Within the scenario it is assumed that the UA will be similar to a Boeing 747 freighter. 6 Communication relay Category 6 operate within long range high endurance type environments. It is assumed that the UA will be a light aircraft size. It is assumed to take off from a dedicated aircraft base. The UA may depart within segregated airspace where it may perform circular flight up to its required destination where it will remain for a long period of time. Max Range (NM) Max Height (ft) > > Edition Number: 1 final report Page 37

46 5.2.2 Simulation Volume of Interest At the workshop it was agreed to focus on a representative high density area in order to fully test channel saturation to its limits. The Volume of Interest (VOI) is centred on London covering the Terminal Control Area (TMA) and adjacent airspace. This provides representative European high density airspace which should provide the most demanding communication environment for this study. Table 5-2 Volume of Interest Table 5-2 above shows the volume of interest that will be modelled. The cylinder has a diameter of 250NM and extends from the surface up to FL600 (approx m AMSL) to encompass all potential UAS activity. The volume was chosen to encompass the physical limitations of potentially likely terrestrial based communication technologies that would be operating within that area. Details of the C3 technologies being considered within our simulations can be found in section 7. Specific details of the airports used within the simulation can be found within Appendix B. The VOI is centred on the high density London TMA airspace and C3 communication transactions will be simulated to replicate the level of command and control messages and expected ATC sector handover communication voice and/or data traffic that would be created. Typical airways and waypoints are constructed to provide realistic traffic patterns that will be grown by interpolation for future time horizons UAS operating in VOI Within each of the scenarios a mix of different UAS categories will be deployed with increasing traffic levels over the three scenarios time period. The approximated number of UA s operating within the VOI during the 1 hour simulation period is shown in Table 5-3 below as agreed at the Workshop. Edition Number: 1 final report 38

47 UA Category Scenario Scenario Cat Cat Cat Cat Cat Cat Table 5-3 Total Number of UAS Categories in Operation Scenario The table shows the numbers of UAS and their category within each sub-division of the VOI. It should be noted that category 1 UAS will not be simulated in FLAME as their operational capability means that they are not operating within our communications operating range. Within each of the scenarios a mix of different UAS applications was deployed with increasing traffic over the time period. Details on the definitions of UA categories can be found in [7]. The numbers of UA s operating within the VOI at one instance during the 1 hour simulation period is shown in below as agreed at the C3 Study Technical Experts Workshop. UA Category Scenario Scenario Cat Cat Cat Cat Cat Cat Table 5-4 Total Number of UAS Categories in Operation Scenario The actual number of aircraft used in the study differs slightly from the numerical values noted within Table 5-4 as FLAME is randomly generating the aircraft flight within the simulation as it is creating realistic city pair flights. 5.3 Simulation Scenarios The three deployment scenarios shall be similar in content i.e. they will be operated over the same VOI with infrastructure and airways remaining constant. However the scenarios will be grown over the timeframes 2020, 2030 and 2050 resulting in an increase in air traffic levels both manned and unmanned aircraft. The resultant outcome will be an increase in the communication traffic occurring within the scenario. The third scenario 2050 is seen as a non limiting scenario in an attempt to push traffic levels to their limits Scenario 3 is aimed at testing the capacity limitations of the communications system. Edition Number: 1 final report Page 39

48 6. AGGREGATE BANDWIDTH REQUIREMENTS FOR CONTROL AND NON-PAYLOAD COMMUNICATIONS OF UNMANNED AIRCRAFT 6.1 FLAME simulation The FLAME fast time simulation and modelling tool was used to produce trajectories for the deployment scenarios. From these trajectories communication events were identified which will drive the dynamic loading on the C3 links. These events will represent aspects of ATC such as handover, clearances and sense and avoid detections of proximate traffic. The FLAMENCO communications model we be used to analyse the C3 information requirements for the Volume of Interest (VOI). The C3 saturation study workshop specified the UA traffic levels in terms of the peak count of UA by category during an hour of interest as shown within Table 5-3. When running a simulation within FLAME there is no simple and direct connection between the input traffic pattern and the resulting traffic density within a chosen volume of interest FLAME traffic is initially specified as a traffic pattern in terms of the numbers of arrivals and departures from groups of airports. The traffic sample generator (TSG) then turns this pattern into a timetable for the whole simulation generating a set of flights that conform to the specified traffic pattern. Hence the peak number of aircraft in an hour cannot be specified as an input. The resulting peak counts of traffic within any specified volume in FLAME depends on, amongst other factors: Location of the volume Input traffic timetable Traffic routing Traffic cruise levels Traffic sequencing Separation minima Traffic, in this context, includes both manned and unmanned aircraft. To achieve traffic flows that maintain required separation minima, the input timetable will be changed as FLAME flow controls the traffic by dynamically imposing delays and possible re-routings at simulation run time. It can therefore be seen that to achieve a specific peak traffic count within a specified hour and volume of interest has to be achieved via a method of trial Edition Number: 1 final report 40

49 and error particularly with higher traffic densities. In practice it was found that achieving precisely the required peak values was not possible in every case, and the traffic samples generated are the closest that can be reasonably expected using this simulation model. This is due to the simulation model adding in a delay to the flight to deconflict the scenario, hence if capacity in the airspace is too dense they will be held on the ground for a clear slot. Table 6-1 shows the peak number of each UA category that was achieved during the simulation hour. Scenario T Scenario 1 Scenario 2 Scenario 3 a [2020] [2030] [2050] Manned b l Cat e Cat Cat Cat Cat Scenario 1, 2 and 3 UAS traffic numbers 6.2 Communication Events To determine the instantaneous communications requirements for each UA in the VOI, a series of events has been defined per phase of flight. The FLAME trajectory file is analysed is determine each event These events have been characterised for each UA category and is tailored to that UA s capability. The The following nomenclature is used for definition of the events: e[event],x[ua category],x[0=c2, 1=S&A, 2=ATC controlled, 3=ATC Class G], x[event number] For example, the first event related to ATC in controlled airspace for a category 2 UA would be given the number e221. A full description of the UA events is shown in Appendix D.2. Some of the events specified are continuous over a specified period, e.g. video on for airport surface for 15 minutes before take-off. This is clearly incompatible with the simulation which generates discrete events with a timestamp. The solution is to generate a series of events over the period of continuous demand, with a frequency equal to the time step to be used for analysis in the Flamenco model. Each of these events is associated with transmission of one timestep worth of data. Knowing that the FLAMENCO time step is 10 seconds, for the example above, the FLAME analysis outputs one video on airport surface event Edition Number: 1 final report Page 41

50 for every 10 seconds of the 15 minute period. Flamenco then interprets each of these events as 10 seconds of video transmission. Event codes in the following tables are the 2 digit identifiers the complete event code is the letter e followed by the UAV category number, followed by the 2 digit identifier C2 events The following C2 event conditions are applied. Start period End period Frequency Event code Take-off 15 minutes Take-off 10 seconds 01 Take-off Take-off + 15 minutes 10 seconds 02 Take-off + 15 minutes Landing 15 minutes 10 seconds 03 Landing 15 minutes Landing 10 seconds 02 Landing Landing + 15 minutes 10 seconds 01 Table 6-2 C2 Event conditions See and Avoid events video: The following video event conditions are applied. Start period End period Frequency Event code Take-off 15 minutes Landing + 15 minutes 10 seconds 11 Table 6-3 Video Event conditions See and avoid events proximity to other aircraft Events 12, 13, 14 are sent on detection of other aircraft within the specified proximities at the frequencies specified. Each simulated UAV tracks each of the other aircraft manned and unmanned and for each one sends out messages at the specified frequencies according to its proximity. This means that as a pair of aircraft gets closer the frequency of messages increases in steps according to the specification, and one sequence of messages is generated for each of the pair. Event 17, video, is generated with a frequency of 10 seconds whenever an aircraft is detected within 5NM and 1000ft, between 15minutes after take-off and 15 minutes before landing ATC messages in controlled airspace The following ATC event conditions are applied in controlled airspace. Page 42 final report Edition Number;1

51 Time Event code Description Take-off 15 minutes 21 Taxi instruction Take-off 5 minutes 28 Data link ATIS Departure Take-off 22 Take-off clearance Landing 5 minutes 29 Data link ATIS Arrival Landing 26 Landing clearance Landing + 15 minutes 27 Taxi clearance On sector boundary crossing 23 ATC sector handover Sector boundary crossing 1 minute 24 ATC instruction messages and + 1 minute Sector boundary crossing + 5 minutes 25 ATC information message Table 6-4 Controlled airspace ATC Event conditions ATC messages in uncontrolled airspace The following ATC event conditions are applied in uncontrolled airspace. Time Event code Description Take-off 15 minutes 31 Taxi instruction Take-off 32 Take-off clearance Landing 34 Landing clearance Landing + 15 minutes 35 Taxi clearance Sector boundary crossing + 5 minutes 33 Information message Table 6-5 Controlled airspace ATC Event conditions 6.3 Events Results The final output of the FLAME simulations is a log of events against time for each of the three scenarios. The figures below provide an overview the numbers of difference events in each scenario. Edition Number: 1 final report Page 43

52 Communication Events per Scenario 2020, 2030 and 2050 Number of Communication Events ATC C2 S&A Figure 6-1 Overall events numbers in the 3 scenarios C2 Communication Events Number of Communication Events within Simulation Hour ex01 ex02 ex Figure 6-2 C2 events during the 3 scenarios Page 44 final report Edition Number;1

53 S&A Communication Events Number of Communication Events within Simulation Hour ex11 ex12 ex13 ex14 ex17 ex18 ex Figure 6-3 S&A events during the 3 scenarios ATC Communication Events Number of Communication Events within Simulation Hour ex21 ex22 ex23 ex24 ex25 ex26 ex27 ex28 ex Figure 6-4 ATC events during the 3 scenarios Edition Number: 1 final report Page 45

54 6.4 Throughput requirements In order to appropriately size the C3 data link, it is important to understand the amount of data in each category, its criticality/importance, and when it needs to be sent. For example, ATS communications, and certain C2 messages will undoubtedly be safety critical, and will be given the highest priority. Information such as outside air temperature or the down linking of engine management data is likely to be assigned a much lower priority. In essence, the data link must have capacity available to instantly send any high priority data that it is presented with. The following diagrams illustrate the typical patterns of the various categories of data, on the C3 uplink and C3 downlink channels. Category Taxi Climb-out Cruise Approach Taxi ATC Voice ATC Data C2 S&A (video) S&A (surv.) Wx radar Table 6-6 Typical Uplink messages The following gives an overview of the characteristics of the messages; ATC Voice - will only be present for short periods when the UAV pilot needs to speak to ATC (to make a request or read back a clearance). As voice messages can occur at any time, dedicated capacity needs to be reserved on the data link for this category of message. ATC Data a series of relatively short messages (to make a request or acknowledge a clearance). As these messages can occur any time, dedicated capacity needs to be reserved on the data link for this category of message. The rate at which these messages are generated is derived from simulations run by FLAME. C2 the need for the uplink of C2 will depend on the level of autonomy to large extent. However, regardless of this, the UA pilot will be required to intervene at any stage of flight, to take avoiding action or to respond to an emergency. Consequently, capacity needs to be reserved for these important uplink messages, regardless of whether they are generated. The amount of C2 uplink data required varies slightly according to the phase of flight. S&A Video there is no requirement for this category of data on the uplink. S&A Surveillance - there is no requirement for this category of data on the uplink. Page 46 final report Edition Number;1

55 Weather radar there is no requirement for this category of data on the uplink. Category Taxi Climb-out Cruise Approach Taxi ATC Voice ATC Data C2 S&A (video) S&A (surv) Wx Radar Table 6-7 Typical Downlink The following gives an overview of the characteristics of the messages; ATC Voice the downlink voice channel will contain messages from ATC to aircraft, and voice replies from other aircraft to ATC that are received by the UA. As voice messages can occur at any time, the dedicated capacity needs to be reserved on the data link for this category of message. ATC Data - these relatively short messages are expected to be generated at regular intervals whenever the UA is in airspace where data link services are provided. As these messages can occur any time, dedicated capacity needs to be reserved on the data link for this category of message. The rate at which these messages are generated is derived from simulations run by FLAME. C2 regardless of autonomy, a wealth of information will be downlinked to the ground station. This is principally to monitor onboard systems and flight progress. The C2 downlink is also used to provide confirmation of system commands sent on the uplink (e.g. flap position, undercarriage down and locked). Given the critical importance of this type of information, dedicated capacity is reserved on the downlink for this category of message. S&A Video it is assumed that continuous streaming of video will be required during ground manoeuvring, as well as take-off and approach phases. It is also anticipated that video will be used intermittently at other times to identify other traffic/hazards detected by the S&A system. S&A video (at a range of rates) is assumed to be required for all phases of flight, and consequently dedicated capacity needs to be reserved on the data link. S&A Surveillance this will be required whenever the UA is airborne in order to provide the UA pilot with situational awareness (akin to a TCAS traffic display). As well as track messages, the system will generate a string of resolution advisory messages whenever a risk of collision with another aircraft arises. The number of messages will depend on the density of airspace the UA is operating in. FLAME is able to calculate the Edition Number: 1 final report Page 47

56 rate at which such messages are expected to be generated, and this can be used to estimate the load that such messages place on the C3 link. Weather Radar for those categories of UA equipped with weather radar, it will be used for periods during the climb-out, cruise and approach phases of flight. The low update rate and snap-shot nature of weather radar images means that dedicated capacity does not need to be reserved on the data link Uplink Calculation Method For the uplink, the minimum data throughput requirement (R Min ) for the service volume will be derived as follows: R Min uplink = [ATC voice rate incl. overhead] + [Sum of ATC data message bits + overheads] + [ Sum of C2 message bits incl. overhead] The maximum data throughput requirement (R Max ) for the service volume will be derived as follows: RMax Uplink = ( P1 uplink message data + overheads) x 25 RMax Uplink = ([ATC voice message + overhead] + [largest ATC data message + overhead] + [largest Priority 1 C2 data message + overhead]) x 25 Priority 1 messages are generated at rates of up to 25Hz. The likelihood of a message being generated in a single 40 millisecond timeslot will be: MessageRate P20 m sec = 25Hz It is therefore necessary to split the Priority 1 C2 uplink messages according to their update rates. For example, for the data sent at 5 Hz, there will be a 0.2 (20% probability) of this data being sent in each 20 millisecond timeslot. By repeating this calculation for data sent at different update rates, it is possible to plot the data throughput verses probability curve. In the case of ATC data, FLAME outputs messages at rates appropriate to the phase of flight and type of airspace. It is therefore possible to calculate the average message rate, and combined size of messages. Uplink throughput rates will be calculated for 2020, 2030 and Page 48 final report Edition Number;1

57 6.4.2 Downlink Calculation Method The downlink calculation method is similar to the uplink, but performed twice for each FLAME scenario to reflect the different S&A video rates of (i) 200 kbps and (ii) up to 13.9 Mbps. For each video rate, the minimum data throughput requirement (R Min ) for the service volume will be derived as follows: R Min downlink = [ATC voice rate incl. overhead] + [Sum of ATC data message bits + overheads] + [ Sum of C2 message bits incl. overhead] + [S&A video + overheads] + [S&A surveillance + overheads] The maximum data throughput requirement (RMax) for the service volume will be derived as follows: RMax Downlink = ( P1 downlink message data + overheads) x 25 x number of UAV RMax Downlink = ([ATC voice message + overhead] + [largest ATC data message + overhead] + [largest Priority 1 C2 data message + overhead] + [S&A video message + overheads] + [S&A surveillance message + overheads]) x 25 x number of UAV As depicted in Figure 1, Priority 1 messages are generated at rates of up to 50Hz. The likelihood of a message being generated in a single 40 millisecond timeslot will be: MessageRate P20 m sec = 25Hz It is therefore necessary to split the Priority 1 C2 downlink messages according to their update rates. For example, for the data sent at 5 Hz, there will be a 0.2 (20% probability) of this data being sent in each 40 millisecond timeslot. By repeating this calculation for data sent at different update rates, it is possible to plot the data throughput verses probability curve. In the case of ATC data, FLAME outputs messages at rates appropriate to the phase of flight and type of airspace. It is therefore possible to calculate the average message rate, and the collective size of messages. Downlink throughput rates will be calculated for 2020, 2030 and Edition Number: 1 final report Page 49

58 6.5 Throughput rate results Using the FLAMENCO tool based on the assumptions above and the event log produced by FLAME, the uplink and downlink throughput requirements can be determined for each of the scenarios. This has been undertaken for both the low rate video (200kbps) as shown in Table 6-8 and the high rate (13.9Mbps) as shown in Table 6-9 Timeframe UL - kbps DL - kbps Table 6-8 Throughput requirement low video rate for the 3 scenarios Timeframe UL - kbps DL - kbps Table 6-9 Baseband requirement high video rate for the 3 scenarios Page 50 final report Edition Number;1

59 7. SPECTRUM REQUIREMENT ANALYSIS 7.1 Introduction This section describes the method of converting the C3 throughput requirements determined in section 6 into spectrum requirements. The C3 study provides three assessments of total bandwidth (spectrum) requirements for C3: Terrestrial-based C3 network using based on L-DACS1 technology Terrestrial-based C3 network using a theoretical data link technology Space-based C3 network based on Inmarsat SBB (spot beam) technology Each assessment uses the same throughput data requirement I (based on the minimal level of security), for which there will be 12 values: Uplink I Low video I Low video I Low video Downlink I High Video I High Video I High Video I Low video I Low video I Low video I High Video I High Video I High Video 7.2 L-DACS1 Although not originally designed to support UAS C3 requirements, an analysis of L-DACS1 indicated that it had potential to meet the throughput requirements. Between NATS sponsored a series of simulations of the L-DACS1 system to examine whether this proposed Future Communications Systems (FCS) was capable of meeting both the latency requirements and the expected data demand in the ATM environment as described in the COCR. The latency and throughput results are shown in the tables below. Edition Number: 1 final report Page 51

60 Scenarios User demand (kbps) No of aircraft Achieved latencies TT 95 (s) ENR SML ATS ENR LRG ATS ENR SML TMA LRG ENR MED ENR LRG ENR SLG (ATS only) Table 7-1 Latency results - TT95 results decomposed for each Class of Service with priority Scenarios User demand (kbps) No of aircraft Achieved throughput (%) Previous B- AMC simulations New L- DACS/1 Simulations with no priority New L- DACS/1 Simulati ons with priority ENR SML (ATS only) % 100% 100% ENR LRG (ATS only) % 99.99% 100% ENR SML % 100% TMA LRG % 99.71% ENR MED % 100% 99.74% ENR LRG % 98.71% 99.47% ENR SLG (ATS only) % 99.98% Table 7-2 Comparison of throughput results from simulations The simulations demonstrated that the even when the throughput demand was over for 95% of the available capacity the latency requirements could still be met. The message size as described in [6] is typically small and the number of aircraft ranges from around 40 up to 200. This is different from the situation with the UAS where the message size is large but the maximum number of UAS in the area of interest is lower especially in the 2020 & 2030 timeframe, in the 2050 the number of UAS a/c is predicted to be around As a result of this and discussions with the developer of the specification we have decided to use a user data throughput value of 90% approximately of the available rate and a frequency re-use factor of 7 again after discussions with the developer. Page 52 final report Edition Number;1

61 Max Uplink or Downlink Demand Table 7-3 below is based on the use of 16QAM which provides a user data throughput of 582kbs uplink and 537kbs downlink with a channel bandwidth of 500kHz up-link and 500kHz downlink i.e. each L-DACS1 channel requires 1Mhz of spectrum resulting in a requirement of 7Mhz when frequency re-use is factored in. The figures have been rounded for simplicity. If the demand figure exceeds 500kbs for either the uplink or the downlink then another L-DACS1 channel will be required hence an extra 7MHz would be needed. The extra L- DACS1 channel would be required even if only the uplink or more likely the downlink data throughput demand was exceeded as the channels are arranged in pairs with the uplink providing the channel access control to the aircraft on the corresponding downlink channel pair. L-DACS Channels Bandwidth per channel (MHz) 500kps Mbps Mbps Mbs Mbps Mbps Mbps Table 7-3 L-DACS1 spectrum required Total Bandwidth (MHz) It is likely that some tailoring of the MAC layer may be necessary to deal with the large size of the video message to optimise throughput. L-DACS-1 already allows the use of a higher modulation scheme such as 64QAM for some part of the user data and a lower one for others such as voice. If 64QAM were to be used it would provide a user throughput of 1.3Mbps uplink or 1.2Mbps downlink for each 500kHz channel i.e. 2.5Mbps in total for 7MHz total spectrum Spectrum Calculation L-DACS1 has been specifically developed as a terrestrial-based digital data link for aeronautical communications in a mobile environment at ranges of up to 200 NM. Tests have shown that a 0.5 MHz channel can provide 582 kbps throughput at on the uplink, and 537 kbps on the downlink. Whilst the maximum operating range is 200 NM, in practice, base stations must be placed at intervals that will ensure coverage to aircraft at all operating altitudes. Also, the FLAME simulation covers a circular area of 125 NM radius. It is important therefore to ensure that the coverage cell is not larger than the area modelled. The following table summarises the distance factor (i.e. the distance between cells divided by cell radius) for different reuse patterns: Edition Number: 1 final report Page 53

62 Reuse Pattern (k) Distance Factor (x cell radius) L-DACS1 has a frequency re-use factor of k=7. Therefore, service volumes using the same frequency must be spaced at least 4.6 times the cell radius apart. ƒ1 r ƒ1 4.6 r Minimum distance between same frequency cells (k=7) So, for K=7, therefore, we could postulate cells with a coverage radius of 100 NM, and a reuse distance of 460 NM. This would provide coverage for all aircraft above approximately 6,000 ft (and lower for aircraft that are closer to the base station). The worse case interference situation will occur for unmanned aircraft operating at the edge of the cell, and at maximum altitude. In this situation, the unwanted co-channel signal will be a distance of 3.6 r (i.e. 360 NM). The radio horizon for this range is 85,000 feet, which is deemed to be more than adequate for any current UAS application. The bandwidth calculation method for L-DACS1 is as follows: 1. Calculate the uplink and downlink throughput requirements to service unmanned aircraft simulated by FLAME within a 100 NM radius in 2020, 2030 and Separate downlink rates should be calculated for (i) 200 kbps and (ii) 13.9 Mbps S&A video streams. 3. For uplink, the number of L-DACS1 channels required for each 100 NM radius cell will be the uplink rate divided by 582 kbps. Page 54 final report Edition Number;1

63 4. For downlink, the number of L-DACS1 channels required for each 100 NM radius cell will be the downlink rate divided by 537 kbps. 5. The total spectrum requirement for an L-DACS1 solution will be number of uplink and downlink channels multiplied by 7, then multiplied by 0.5 MHz 6. This value needs to be multiplied by a system redundancy factor, using R= Theoretical Terrestrial Data link Technology Assessment With an existing technology such as L-DACS1, there was no need to worry about the way in which message data is handled by the sub-network. For example, there will be additional overheads associated with coding, acknowledgements and re-tries. In addition, there will be framing and sequencing information that allows the sub-network to re-assemble the messages at the other end. Whilst it is recognised that any digital data link technology will be complex, it is possible to make some very generic assumptions about the data link channel rate RC and the corresponding amount of spectrum that would be required. The channel rate can be calculated by considering the throughput rate and estimating sub-network overheads The basic throughput (information) rate I bit/s for uplink and downlink in a terrestrial coverage cell of radius 100 NM, as described in sections X.X and Y.Y. Protocol header or framing overheads expressed as a fraction F of the information rate FEC codes applied to the information and headers, expressed as a code rate ρ Any retransmissions expressed as a fraction R of the complete packets that need to be retransmitted. The order in which these are added is important. Based on standard approaches to data protection the overall channel rate R C bit/s can be calculated from: ( 1+ F )( 1 R) + R C = I ρ For example a 10 kbps information rate with 10% framing overhead (F=0.1), half-rate FEC (ρ = ½ ) and 15% retransmissions (R = 0.15) has a channel rate R C of 25.3 kbps. Edition Number: 1 final report Page 55

64 A core assumption here is that the channel can transmit what ever data is required to meet requirements for latency and integrity etc, and it is not limited to an upper channel rate as might be the case in practice Bandwidth Required per Cell The amount of spectrum per cell f(c) Hz can be related to the channel data rate R C bit/s by considering the spectral efficiency Γ bit/s/hz of a candidate waveform. These can be related by the equation: R f ( C) = C Γ Technologies such as WCDMA can offer spectral efficiency rates of up to 4, but such efficiency is generally not achievable in a mobile/multi-path environment. It is reasonable therefore to assume a lower spectral efficiency of 2.5 bits/hz Frequency Management Having calculated the theoretical spectrum requirement for the uplink and downlink within each 100 NM radius cell, the next step is to calculate the total spectrum requirement for a network. The key variable here is the frequency re-use factor k which will vary according to the technology used. Whilst there are technologies that offer efficient re-use factors (i.e. K=1 or 3) they are generally not suitable for fast moving mobile users, or elevated operation (as is the case for UAV applications). Given these considerations, a reasonable assumption for re-use factor is K=4. The estimated total spectrum requirement W for a continuous network of cells can be calculated by taking account of re-use factor K and redundancy factor R. W = f ( C) k R The spectrum calculation method used for a theoretical terrestrial technology can be summarised as follows: 1. Calculate the uplink and downlink throughput requirements to service unmanned aircraft simulated by FLAME within a 100 NM radius in 2020, 2030 and Separate downlink rates should be calculated for (i) 200 kbps and (ii) 13.9 Mbps S&A video streams. 3. Calculate the per cell channel rates for uplink and downlink throughput using F = 0.1, R=0.15 and ρ = ½. For downlink this will be for (i) 200 kbps and (ii) 13.9 Mbps S&A video streams. Page 56 final report Edition Number;1

65 4. Calculate the corresponding spectrum requirement f (C) for each cell, using an assumed spectral efficiency Γ of 2.5 bits/hz 5. Calculate the total spectrum requirement W, using a re-use factor k=4 and redundancy factor R= To provide an estimate of the bandwidth requirements for high security (scrambled) C3 link, the spectrum should be multiplied by a factor, using S= Spot beam Satellite Technology Assessment Indicative information for this technology has been based on the Inmarsat SwiftBroadband satellite service is an existing technology that can be used to provide broadband services to aircraft in a mobile environment. Whilst it is unlikely in its current operational configuration to have the capacity to meet C3 channel throughput requirements (or be able to achieve latency requirements given its geostationary characteristics) it does provide a benchmark in terms of throughput, bandwidth and frequency re-use for a broadband satellite communications system. SBB has a sub-network data throughput rate of 432 kbps (without QoS) in a 200 khz bandwidth. This is true for both uplink and downlink. SBB has a frequency re-use factor of K=4 Spot beam area gets larger with increasing latitude (north or south of the equator). However, in common with ITU WP-5B, a spot beam is assumed to be 391 km in radius (211 NM), NM 2. The area of interest modelled in FLAME is 125 NM (radius, and has an area of 49,087 NM 2. Hence, the spot beam area used by ITU is larger than FLAME by a factor A, where A = The spectrum calculation method using SBB satellite technology: 1. Calculate the uplink and downlink throughput requirements to service Category 3, 4 and 5 unmanned aircraft (i.e. those with satellite communications capability) simulated by FLAME within a 125 NM radius for 2020, 2030 and Separate downlink rates should be calculated for (i) 200 kbps and (ii) 13.9 Mbps S&A video streams. 3. Multiply uplink and downlink throughput rates by A to represent the throughput that would have to be serviced by a single spot beam. 4. For uplink, the number of SBB channels required for each 211 NM radius spot beam will be the uplink rate divided by 266kbps Edition Number: 1 final report Page 57

66 (the average of the number of UA installations capable of supporting 432 kbps category 4 & 5 and those with lower rate of 100kbps). 5. For each downlink, the number of SBB channels required for each 211 NM radius spot beam will be the downlink rate divided by 266 kbps. (the average of the number of UA installations capable of supporting 432 kbps category 4 & 5 and those with lower rate of 100kbps). 6. The total spectrum requirement for an SBB solution will be number of uplink and downlink channels multiplied by 4, then multiplied by 0.2 MHz 7. This value needs to be multiplied by a system redundancy factor, using R= Spectrum Requirements Based on the above calculation and using the FLAMENCO tool the following spectrum requirements on the up and down-links as well as the global value has been determined for the two rate of video low and high. Table 7-4 below contains the spectrum requirements for the three technologies using low rate video. Table 7-5 below contains the spectrum requirements for the three technologies using high rate video. Spectrum Requirements (MHz) Candidate Technology A L- DACS1 Spectrum Requirements (MHz) Candidate Technology B - Theoretical Terrestrial Data link Spectrum Requirements (MHz) Candidate Technology C: Satcom based on Swift Broadband UL DL Overall UL DL Overall UL DL Overall Table 7-4 Spectrum requirements low rate video Spectrum Requirements (MHz) Candidate Technology A L- DACS1 Spectrum Requirements (MHz) Candidate Technology B - Theoretical Terrestrial Data link Spectrum Requirements (MHz) Candidate Technology C: Satcom based on Swift Broadband UL DL Overall UL DL Overall UL DL Overall Table 7-5 Spectrum requirements high rate video Page 58 final report Edition Number;1

67 8. COMPARISON OF WORK WITH WG73 This section summaries a review of the methodology 1 adopted by WG-73 to determine spectrum for the C3 link. A comparison of the approach and assumptions used by WG-73 is made with this EUROCONTROL C3 channel saturation study hereafter called the C3 study. 8.1 Approach WG-73 followed a logical numerical analysis to create a spectrum data requirement. It is stated within [2] that the radio spectrum was calculated via a two-step process: Step 1: determination of the bit data rate requirement for a single UA based on the use of digital communications Step 2: calculation of an aggregate radio spectrum requirement determined by Calculating the total number of UAs operating in a given area Use of the number of UAs to determine the aggregate bit rate requirements for UA operations Inclusion of any additional provisions in developing the aggregate amount (i.e. back up or dual links) Translate the aggregate bit rate requirement using estimated radio spectrum efficiency of the technology and the frequency reusability from one cell to another This C3 study follows a similar high level analytical approach: Single UAS modelling quantification of C3 data elements for different UA categories, and how they will be used for different phases of flight UAS Deployment Scenario to reflect the quantity of each UA category operating in 2020, 2030 and 2050, and how they will be distributed within the simulation area. Includes non-ua traffic to reflect sense and avoid information exchange requirements. Multiple UAS modelling dynamic traffic simulation captures the C3 communication events that occur for each UA over time. Analysis of Spectrum Requirements determine information exchange requirements for a given volume of airspace and estimate the total spectrum requirement using different communications technologies (both terrestrial and space based). Edition Number: 1 final report Page 59

68 Both studies have been carried out in a similar compartmentalised way hence and the high level approach of each study is consistent. Both studies of work have approached their analysis in a similar high level structure which aids its comparison here. Table 8-1shows the analysis carried out within this deliverable for each of the two studies. Page 60 final report Edition Number;1

69 Single UAS Modelling UAS Deployment Scenario Multiple UAS Modelling WG-73: ATC/C2/S&A Comms Overheads Overall throughput requirements consistent with ITU Single UAS Modelling Comparison WG-73: Density of UAs in ECAC Fixed number of UAs in coverage cells (snapshot). UAS Deployment Scenario Comparison Multiple UAS Modelling Comparison C3 Study: ATC/C2/S&A Comms using inputs from ASTRAEA and CAUSE, taking account of priority and latency C3 Study: Set of missions defined for each UA category. Non-UA traffic grown to be representative for 2020, 2030 and 2050 C3 Study: FLAME simulation used to generate C3 events. FLAMENCO used to Estimate channel rates and spectrum need. Overall Study Observations Key Findings on Spectrum Requirements for UAS usage Table 8-1 Analysis Approach to review of Studies performed by both WG-73 and C3 Study Edition Number: 1 final report 61

70 8.2 Single UAS Modelling Common to both studies, there are 3 envisaged communication needs of a UA within its operating environment: Command and Control (C2) communications which enable the UA to be controlled and monitored during all stages of flight by the remote pilot based on the ground. Sense & Avoid (S&A) communications to provide the UA pilot with information about objects and the environment that the UA is operating in. This includes track information of proximate flying objects that the UA s onboard sensors have detected, video imagery (particular for ground phases of flight) and weather radar data to forewarn of hazardous flying conditions (i.e. severe turbulence/icing). ATC communications to enable a UA to either receive services and information from ATC, or communicate with other aircraft via an onboard ATC radio. In the short-medium time frame it is widely accepted that voice will provide the primary means of communication, but this will gradually be replaced by data link. However, ATC voice will always be necessary for emergency communications, so it is assumed that UA will require both ATC voice and data capability for the foreseeable future. The sections that follow look specifically at the details of the above mentioned communications and outlines what sort of amount of data is expected for each communication type that would potentially be using the C3 channel. The sections that follow analyse WG-73 and C3 study approaches and is followed by a comparison section WG-73 Data Transfer Requirements for a Single UA Communications Requirement Command and Control (C2) Communications The bandwidth requirement for the Command and Control link is assumed to be dependent upon the UA s level of autonomy. The Command and Control link load for a UA that only accepts waypoint changes is significantly less than for a UA receiving control surface commands. The requirement for highly autonomous UA will be less stringent. WG-73 have recognised that there is a great diversity in the types of UAS missions, systems and aircraft characteristics that will have an impact on the communications link. It was recognised that the UAS manufacturing community have accepted NATO STANAG 4586 [9] as an accepted generic standard for UAS message types and formats. Edition Number: 1 final report 62

71 The C2 data requirements are the same as those used within the ITU documentation where a more detailed breakdown of message types, size and frequency has been carried out ATC Communications For ATC communications it is assumed that there is a requirement for the UA to operate in the same way as a manned aircraft. The assumption is made that by 2020 ATC communications will be achieved via a relay through the UA rather than as a direct (i.e. ground-ground) link between the pilot and ATC. Voice communications will be conveyed using two 4800 bps data streams (i.e. UA pilot to ATC on the uplink channel, and ATC to UA pilot on the downlink channel). In addition, ATC data (including overheads) are added to the ATC communications The study recognises that beyond 2020, new data link communications systems will exist in the L band, and a C band system will be exist for use on the airport surface. However, regardless of whether these new technologies are in service, they will not have an impact on the amount of spectrum required for ATC communications over the C3 data link. Moreover, WG-73 has stated that ATS Data messages are small enough in size to be accommodated within the bandwidth allocated for ATC voice messages. Despite this, the WP-5B calculation methodology includes a data rate allowance for the relay of ATS Data messages sent and received during each phase of flight. The message size is derived from the COCR [6] Sense and Avoid Communications Sense and avoid is seen as an additional requirement for a UAS to become equivalent to manned aircraft operations. This sense and avoid (S&A) function is broken into: Maintenance of the required separation from other aircraft or obstacle according to the flight rules and separation standards applicable to the considered airspace Avoidance of close proximity aircraft or obstacle when separation standards have been breached It has been assumed that S&A system will comprise of different data flows from various sensors including: Aircraft target tracks Weather radar plots Video (optical or infra red) surveillance stream especially in taxing take off, landing or as requested by the CS Warning of potential incidents Flight information service provided by ATS The table below provides a brief overview of the S&A information assumed by WG-73. Edition Number: 1 final report Page 63

72 Requirement Description Data Requirement Aircraft target tracks The ADS-B standard (DO-260A) is used as an off-the-shelf format for conveying surveillance tracks (or target tracks) of nearby aircraft kbps The ADS-B standard (DO-260A) indicates that the message transmitted to update the track is limited to 209 bits with an update rate of 1 Hz. It is assumed for the purpose of spectrum assessment that a total up to 60 tracks may be downloaded to the CS. The resultant maximum data rate is 60 x 209 = bps for a single UA. WG-73 noted that the ITU WP-5B compression assumption on message size from 209 to 80 bytes seemed unrealistic. However on review of the numerical value no adjustment was made to the ITU data requirement amount (as shown in column to the right). Weather Radar Non payload video Airborne Weather Radar Systems provide the pilot with a local (forward looking) weather picture that allows the pilot to identify and avoid weather formations that might be hazardous. A maximum range of 180 Nm is common although the commonly used range (as selected by pilots) would normally be in the 30 to 80 Nm range. While it is very likely that the smaller UA will not carry such equipment, it is likely that most of the other larger UA will carry it for severe weather avoidance in order to get their certification. In order to be spectrally efficient it is assumed that the pixel of the images will be processed and compressed on board to create the plots that will be downloaded to the CS. A matrix of [78 x 48] plots transmitted every second seems sufficient to recreate in the CS a meteorological map. Therefore the data rate throughput is [78 x 48 x 5 = 18720] bps In the WG-73 spectrum requirement overview table the ITU figure has been used. A non-payload video downlink is likely to be required intermittently by some UA for situational awareness in certain situations such as takeoff and landing. It is stated that The video system has been assumed to provide a resolution of 720 by 480 pixels with an update rate of 5 frames per second. The number of bits per pixel has not been specified, but it is stated that with latest videocompression technology, it is feasible to encode such video kbps 200 kbps Page 64 final report Edition Number;1

73 Other sources of information as a 200-kbps stream. (This rate increasing to 270kbps when overheads are included). It has been assumed that the non-payload video rate is reduced to 10% of this value for UA operating at medium and high altitude. A single allocation is reserved on the data link for nonpayload video and Weather Radar, which is taken to be the greater of the two (i.e. the non-payload video). There are differing assumptions made for how the UA is flying (i.e. IFR/VFR) and in which phase of flight it is within. The specific detail for which can be found in [2].. Flight Information Service will be used for surveillance and S&A functions. These messages will be either transmitted by the ground ATS network directly to the control station (in this case there is no need for spectrum), or over the air via the ATC data relay or by the air FIS (Flight Information Service). It is assumed that a 20 kbps would be necessary with this estimation being the same as that provided in the ITU 5B paper Error! Reference source not found.. 20 kbps Overhead Factors WG-73 have assumed the following overhead factors for the data requirements outlined above: Packet header lengths: The transport protocol requires 8 bytes and the network protocol requires 46 bytes. The average packet has 400 contents bytes and contains 2 messages. Each message has a 34-byte wrapper and a 4-byte presence vector identifying the fields to be transmitted. The overhead is (4 + 34) = 130 bytes i.e. a ratio of 1,325. Encryption overhead: In a Digital Signature Algorithm (DSA) or Elliptic Curve DSA system with 80-bit security (which would oblige a spoofer to try roughly times to crack the private key), encryption overhead is 40 bytes per packet. With 400 content bytes, the ratio for encryption is Error Correction: A ¾ FEC coding rate has been assumed. Total overhead increases the ratio to Since the video downlink will not be packetized, only error correction overhead may apply. Edition Number: 1 final report Page 65

74 Factors C2 ATS relay S&A tracks S&A video S&A weather S&A other Packet NA NA Encryption1.1 NA 1.1 NA NA 1.1 FEC Total Table 8-2 WG73 Data Overhead Assumptions Overall Requirement for a Single UA The study has split the UA s into 4 altitude levels: airport surface, low altitude, medium altitude and high altitude. The data rates have been multiplied by the overhead factors detailed above to give the estimated throughput requirements summarized in Error! Reference source not found.. Proposal : airport surface Proposal : Low altitude Proposal : medium altitude Proposal : High altitude Command and control ATC relay Sense and Avoid x (UL: DL: ) x (UL: DL: ) x (UL: DL: ) x (UL: DL: ) Table 8-3 WG-73 Estimated Throughput Requirements for a Single UA Video/ weather radar Comparison of Single UA Data Transfer Requirements The following table summarises the differences between the WG-73 and C3 studies with regard to the approach used to derive single UA data transfer requirements. Function WG-73/ITU WP-5B C3 Study ATC Voice Communications Relay via UA assumed Always on 4.8 kbps channel in each direction Relay via UA assumed. Always on 4.8 kbps channel in each direction Page 66 final report Edition Number;1

75 ATC Data Communications S&A Video S&A Surveillance Track Messages S&A Weather Radar Relay via UA assumed Fixed set of ATC data messages assumed for each UA 200 kbps stream providing 720 by 480 pixels with a 5 Hz frame rate Constant load of 60 track messages per UA assumed Assumption that weather radar data at bps can be sent with S&A video allocation. Relay via UA assumed ATC data messages generated by FLAME simulation Low: 200 kbps stream providing 720 by 480 pixels with a 5 Hz frame rate High: 13.9 Mbps stream providing resolution equivalent to acuity of human eye with a 25 Hz frame rate. (Reduced rate of 1.5 Mbps for cruise phase). Surveillance messages generated by FLAME according to proximity of other aircraft. Weather radar data at 20,751 bps sent as Priority 2. (Automatically overridden by priority 1 messages). C2 Security Assumptions Prioritisation Overheads Fixed set of messages based on STANAG Digital Signature Algorithm (DSA) or Elliptic Curve DSA system with 80-bit key. Not reflected in data throughput calculation Calculated as a percentage factor of message size, with a fixed amount added for S&A video. Fixed set of messages based on ASTRAEA. Message set and update rates change according to phase of flight. Low: C2 uplink messages include a security key (16-bit) to reflect assumed minimum requirement. High: Additional encryption of all transmitted data over C3 link (not reflected in single UA message data size) Throughput calculation takes account of message priority requirements Fixed overhead per message. Overall Data Requirements Arithmetic sum of per second Not calculated. Edition Number: 1 final report Page 67

76 per UA data rate plus overheads. Table 8-4 Comparison of WG73 and this study on single UA data transfer requirements 8.3 UAS Deployment Scenario Analysis Section 4 provided a description of C3 data exchange requirements for a single UA operating within different phases of flight. To understand the collective demand for bandwidth in a given geographical area or region, it is necessary to generate traffic scenarios that take account of the type of UAs that are expected and their operating characteristics. Once the amount of traffic is known, it is possible to calculate the bandwidth requirement for a given area or volume of airspace (see section 5). The different approaches used to develop traffic scenarios are detailed below WG-73 UAS Deployment Scenario WG-73 provided a density analysis of UA distribution within European airspace based on a Peak Instantaneous Aircraft Count (PIAC) in the 2030 timeframe. An assumption is made that 10% of the PIAC in ECAC will be UA and that all small UA s will operate at low altitudes, medium UA s will operate at medium altitude and large UA s will operate at high altitude. It is also assumed that only 60% of UA will be flying simultaneously. Table 8-5 Total number of UA and density values The total number of UA s is based on PIAC numbers (TMA 44, Medium En route 62 and Large Enroute 204) however exactly how the figures in the above table were created from these is unclear. This method uses a geographically uniform distribution of UA although it is recognised that in an emergency situation the densities may well be greater than those shown within Table 8-5 (in certain localised areas). The area within this study is taken to be ECAC which has an area of approximately 7.8M km 2. All UA are assumed to operate within this area at one level for each type of UA. This provides an estimation of the potential traffic levels of UA to give the density levels as shown in Table 8-5 above. The final factor used to calculate the total bandwidth required to support UAS operation is how many UA are flying in each phase of flight in the assumed deployment scenario. Page 68 final report Edition Number;1

77 The study could not define precise quantities based on UA categories, capabilities or mission profiles but reviewed responses to an RTCA questionnaire. The average estimated time spent within each phase of flight was calculated as presented in Table 8-6. UA QUANTITY PER PHASE OF FLIGHT Pre-flight Terminal departure En-route Terminal arrival Postflight Percentage of time in phase 4% 8% 76% 11% 1% Table 8-6 Disposition of total number of UA interferers by phase of flight Comparison of UAS Deployment Scenarios On review of the UAS deployment scenarios used within both studies there is a clear difference in approach to modelling the operational environment. WG-73 have assumed a large area covering ECAC for analysis totalling an area of approximately 7,800,000km 2. Presumably this is because it is considered to be a busy area. It has been mentioned that the PIAC has been used to calculate the number of aircraft present within the area although how this has been constructed is unclear. They have generally assumed that the distribution of all UAs is homogeneously spread, i.e. directly coupled to the surface of the area it is deployed in. Hence when density values were calculated in [3] they have assumed that UAs will operate within a given area rather than within the volume of airspace. This is a numerical assumption to aid calculation but is unrealistic as UAs will be operating throughout the volume of airspace in real flight. The C3 study assumes that UAs will be operating within the VOI operating according to their associated performance characteristics. The UAs will take-off, perform their mission and land either at a new airfield or return to base. From a technical workshop the number of UA within such a volume were estimated to be present over the differing timeframes. C3 study has run a simulation of events so that UA will be operating amongst manned aircraft following realistic traffic patterns and routes to carry out their tasks. 8.4 Bandwidth Calculations WG-73 Bandwidth Calculations Based on the assumptions made regarding UA traffic densities, and calculation of the bandwidth requirement for a single UA, an aggregate bandwidth requirement for all UAs operations is then determined according to the following steps: Determine the total number of UAs operating in a given area. Edition Number: 1 final report Page 69

78 Use the number of UAs to determine the aggregate bandwidth requirements for UAS operations. Include spectrum sharing and frequency reuse in the calculations to determine the aggregate bandwidth requirements for UAS operations (for both terrestrial and satellite C3 systems). Include backup communications or dual link requirements as appropriate in developing the aggregate bandwidth requirement. The WG-73 method produces separate aggregate bandwidth requirements for a terrestrial (line-of-sight based system) and a spot-beam satellite system. It is assumed that 75% of the medium and high altitude UA are equipped and using a spot beam satellite system. The remaining 25% of medium and high altitude UA, and all other UA in the scenario are using a terrestrial based C3 system Radio Technology and Network Factors Assessment is based on the application of a suitable (theoretical) radio technology. The level of safety (and also security) required for the safe operation of future UA would probably lead to double some kinds of communications. Terrestrial C2 ATC relay S&A low latency S&A medium latency R U E Ratio R/UE Video/weather radar Satellite C2 ATC relay S&A low latency S&A medium latency R U E Ratio R/UE Video/weather radar Frequency Management The WG-73 makes assumptions about the size of coverage cell required for terrestrial and satellite operation. For terrestrial, four types of cell are assumed, each with different cell radii and altitude range. This approach recognises the need to have Page 70 final report Edition Number;1

79 greatest capacity in the network to serve the majority of UA (small/medium) that are operating at low/medium altitude. Cell type A 6000 m Cell type B 157 km 65 km 1500 m 1500 m 112 km Surface 272 km Cell type C Cell type D 315 km 480 km m m 6000 m m Surface 545 km Surface 831 km For each cell type, a frequency reuse factor has been calculated to represent the most efficient frequency reuse that could be achieved, given the potential for co-channel interference from the nearest cell assigned the same frequency. This shows that for larger type D cell, it is possible to use a lower, more efficient k value due to the fact that the earth s curvature prevents co-channel interference. For the spot beam satellite system, a value of k=4 has been used, based on what is currently achieved by a typical system. Cell Type Cell radius (Km) K applied A 65 7 B C D E (sat spot) Bandwidth Calculation Model The aggregate bandwidth requirement W (khz) per class of traffic can be expressed as: W =K B M R / (U E) Edition Number: 1 final report Page 71

80 where: K is the frequency reuse factor B is the data rate requirement (Kbits/s) of a single UA per class of traffic. M is the number UA per cell. Terrestrial infrastructure spectrum requirement: Cell type At surface Without video and weather radar A B C D E (sat spot) Satellite infrastructure spectrum requirement Cell type With video and weather radar 25.7 MHz MHz Without video and weather radar With video and weather radar E 25.7 MHz MHz The following table summarises the UAS spectrum needs summary. Except video/ weather radar Video/ weather radar only Total Terrestrial needs, MHz Satellite needs, MHz Comparison of Approaches The following table summarises the different approaches used by the two studies to estimate the total amount of bandwidth (spectrum) required for terrestrial and spacebased C3 data link communications. Page 72 final report Edition Number;1

81 Redundancy Frequency Reuse (terrestrial) Frequency Re-use (spot beam satellite) Summation Method (Terrestrial) Summation Method (Satellite) Output WG-73/ITU WP-5B 100% redundancy applied to C2, ATC communications and low latency S&A. 50% redundancy applied to medium latency S&A. No redundancy applied to video/weather radar 4 types of coverage cell assumed, each with an appropriate k value. K=4 Spot beam assumed to have a radius of 211 NM Summation of bandwidth required to service 75% of medium and high altitude UA with a continuous network of non-overlapping cells covering ECAC airspace. Summation of bandwidth based on a continuous network of (non-overlapping) spot beams Single bandwidth value (uplink+downlink) for terrestrial-based C3 communications, with/without video & weather radar Single bandwidth value (uplink+downlink) for spacebased C3 communications with/without video & weather radar C3 Study 50% redundancy factor applied to all data Single size coverage cell assumed for each technology. K=4 Spot beam assumed to have a radius of 211 NM Summation of bandwidth required for a continuous network of nonoverlapping cells to service category 4, 5 and 6 UA, based on throughput requirements for core European airspace (London area). Summation of bandwidth based on a continuous network of (nonoverlapping) spot beams A range of values for low/high video and low/high security, repeated for each technology in each timeframe. There are obvious similarities between the approach adopted by WG-73 and this study. However there are notable differences in that this study covers A different set of single UA data elements with related priorities to respect latency requirements Edition Number: 1 final report Page 73

82 The use of a fast time simulation to generate the UAS operation environment for 3 timescales 2020, 2030, and 2050 The use of substantially high data rates for S&A video Identification of communications requirements within a volume of interest located in high density airspace The use of different overhead values including a different security option The adoption of a novel technique to ensure that peak C3 demand for individual UA is met on a high percentage of occasions The use of representative technologies to determine spectrum requirements Page 74 final report Edition Number;1

83 9. CONCLUSIONS AND RECOMMENDATIONS 9.1 Overall This study has used a set of simulations (FLAME and FLAMENCO) to model the communication requirements in as realistic manner as possible. The area of operation of the UAs was chosen in high density airspace has a worse case example of UAS deployment. A number of assumptions have been used in deriving the results; changing any of the assumptions can have a dramatic effect on the results. A perfect ground and airborne infrastructure has been assumed and no delay has been taken into account. The C3 latency values used for this study are only a component of the end-to-end latency value. The latency values used are primarily driven by the C2 requirements and the need to support ATC voice. An always open channel has been assumed to meet the latency for ATC voice to ensure transparency with the existing infrastructure. The use of FLAME and FLAMENCO allowed a parameterised approach to the variables in the study. These parameters could be modified and the simulations repeated to accommodate difference values if required. 9.2 Comparison with WG-73 methodology The following general differences in approach in this study compared with the WG-73 approach can be made; The development of realistic operational scenarios to the maximum extent possible The use of a fast time simulation to generate the UAS operation environment for 3 timescales 2020, 2030, and 2050 The use of substantially high data rates for S&A video Identification of communications requirements within a volume of interest located in high density airspace The use of different overhead values including a different security option The adoption of a novel technique to ensure that peak C3 demand for individual UA is met on a high percentage of occasions The use of representative technologies to determine spectrum requirements Edition Number: 1 final report Page 75

84 9.3 Spectrum results The study has determined the global spectrum requirements for the up and down-links as well as overall value. The results produced are based on worse case scenarios in high-density airspace. The study has concentrated on the C3 link and associated spectrum requirements at a single location and then extrapolated the result to a global requirement. In reality lower density airspace would not have such high demands. 9.4 Video This study has demonstrated the amount of spectrum needed is highly dominated by video. High rate video has a dominant effect on the results. SAA data is dominated by real time video, and this is particularly the case for take-off, approach and landing phases of flight. Whilst real time video may not be required during the cruise phase of flight, particularly in controlled airspace To be truly equivalent to manned aviation, a video system capable of replicating the visual acuity of a human pilot is required. We estimate that this would require a data rate of 13.9 Mbps. In practice, it may be acceptable to use a video system that is inferior to the human eye ball, but when used in conjunction with other sensors, can be shown to match or exceed the human see and avoid performance. Such a system would have a more affordable and practical bit rate requirement, and it is reasonable to assume that a rate as low as 200 kbps (as used by WG-73) might be acceptable. Therefore, the approach adopted is to use a minimum and maximum value in order to indicate the range of values that might apply: S&A video at 200 kbps (in line with WG-73/ITU estimations) S&A video at 13.9 Mbps (as detailed in D3) reducing to 1.5 Mbps in cruise phase 9.5 Satellite For the purposes of this study, to determine the spectrum requirements for the spot beam satellite all UAs operating in the VOI have been assumed to be using satellite communication. This is a worse case scenario as it is likely that only a proportion of aircraft will be equipped (WG-73 assumed around 75%). Although spectrum requirements for a satellite system have been determined this is academic as communication with a geostationary satellite cannot achieve the end-toend times of priority level 1 (130mS). Page 76 final report Edition Number;1

85 9.6 Emerging technologies Although not specifically designed to support C3 communications, emerging technologies e.g. L-DACS1 may have the capability to support this requirement assuming the video element was not included. 9.7 Recommendations The following recommendations are made - There is an urgent need to determine whether video from the UA to remote pilot is required and its quantity Consideration needs to be given to the video compression techniques needed to ensure they meet the latency times particularly manoeuvring on an airport surface. If there is a need for video then consideration should be given to a dedicated communication system to specifically handle this requirement. The role of satellite communication in the C3 link needs to be determined due to the latency of at least 0.27 seconds. Edition Number: 1 final report Page 77

86 10. REFERENCES [1] QinetiQ - Project Management Plan - UAS C3 Channel Saturation Study Issue 1.0 October 2009 [2] EUROCAE WG73 - Radio Spectrum Requirements - UAS_ June 2009 [3] ITU WP5B - Characteristics of unmanned aircraft systems (UAS) and spectrum requirements to support their safe operation in non-segregated airspace 3 December 2009 [4] EASA, Final Report of the Preliminary Impact Assessment On the Safety of Communications for Unmanned Aircraft Systems (UAS) Volume 1 Issue 1 - Dec 2009 [5] QinetiQ - Report D1 - Bandwidth Requirements Astraea T2.2 [6] EUROCONTROL/FAA - Communications Operating Concept and Requirements for the Future Radio System version 2.0 [7] SESAR Target Concept D3 [8] QinetiQ Notes of the Notes of the Scenarios Workshop of the EUROCONTROL C3 Channel Saturation Study November 2009 [9] NATO Standard Interfaces for UAV Control Systems for NATO UAV Interoperability STANAG 4586, Nov 2007 [10] RTCA Special Committee 203 s questionnaire sent to a large number of UA manufacturers and operators (Guidance Material and Considerations for Unmanned Aircraft RTCA DO-304 March 2007 Appendix F) [11] EUROCONTROL Long-Term Forecasts Flight Movements v1.0, 19/11/08. Page 78 final report Edition Number;1

87 A. FLAME DESCRIPTION A.1 Introduction This Appendix describes the main modules which are part of the suite of fast-time simulation software modules known as FLAME (FLexible Airspace Modelling Environment), built by QinetiQ for use in studies of concepts for future air traffic management (ATM) systems. The main modules relevant to this study are described in the following sections. A.2 Trajectory Generator with ATC This program assumes that aircraft prefer to fly according to their flight plans (represented by traffic sample entries), but it detects potential separation problems (conflicts) and modifies aircraft trajectories to avoid such conflicts. It also keeps track of which control sector each flight is currently in, and maintains sector workload statistics. The program collects more statistics than the simple trajectory generator on the fly, and studies using it are therefore less dependent on post-processing of trajectory files than are those using the simple trajectory generator. A.3 Flow Manager In current ATM practice, flow management procedures are routinely used to smooth traffic flows. Consequently, traffic scenarios for simulation experiments lack a degree of realism if they have not been through some form of flow management process. The flow manager allows flow restrictions to be applied to airports, control sectors and waypoints. In the case of airports, either a single restriction is applied to the total outbounds + inbounds, or two restrictions are applied to outbounds and inbounds separately. In the case of waypoints, separate restrictions may be applied to bands of levels at a waypoint. The program reads a traffic sample file, applies any delay which might be needed to comply with the flow restrictions, and writes a revised traffic sample file. A.4 Traffic Sample Generator In order to conduct ATC simulation experiments it is necessary to have one or more traffic samples. A traffic sample is simply a list of all flights to be simulated, complete with all relevant details for each flight. These details might include such things as: flight start time, origin and destination airports, cruise flight level, aircraft type, and so on. The samples used in most ATC simulations are obtained by recording the real traffic that flies on particular days, and then manipulating the recordings in various ways (e.g. by duplicating flights to increase traffic density) to obtain samples suitable for Edition Number: 1 final report 1

88 experiment. This approach is appropriate for real-time simulation studies, but is not appropriate for many of the fast-time studies for which FLAME is intended. Instead, FLAME uses a sample generator program that generates pseudo-random traffic samples from more abstract descriptions of the required traffic patterns. This approach offers a number of important advantages: Samples of any practical duration can be generated from a traffic pattern description. By using different random-number seeds, an almost unlimited number of different samples can be generated from a single traffic pattern description. The traffic pattern description provides experimenters with the means to control traffic densities and geographical distributions of traffic independently of one another. These capabilities support an approach to simulation where statistics are obtained for a whole population of possible traffic situations rather than for a single sample. They enable experimenters to make the trade-off between simulation run time on the one hand and the variances of parameter estimates on the other. A.5 Traffic Display The Traffic Display Program provides FLAME experimenters with a tool for viewing simulated traffic on a radar-like display after the completion of a simulation run. The display symbols used are meant to be helpful to experimenters, typically when they are validating that a simulation run has behaved as planned; there is no suggestion that anyone would attempt to control traffic by using such a display. The Traffic Display Program has the following general capabilities: The program can display symbols representing individual flights that move as a function of simulated time. The symbol shape indicates whether a flight is climbing or level or descending, and the symbol colour indicates the flight's altitude band. A single displayed flight may be selected with the mouse. This causes the display of additional information about the flight (callsign, origin and destination airports, flight level information). The program's simulation clock can be set to different times so as to view different parts of a run. It can be set to run at different speeds so that the picture changes faster or slower. The clock can also be run backwards so that experimenters can see how a particular situation developed. The program can display map information as a background to the traffic. The map information can include: coastlines and international boundaries, control sectors and military zones. The display centre and scale (zoom) can be set by the user. Page 2 final report Edition Number;1

89 A.6 Aircraft Modelling This module provides various low-level aircraft performance modelling and related functions for FLAME. Additional aircraft models were developed for the various UA categories in this study. In FLAME, an aircraft's capabilities are completely characterized by three parameters: aircraft type, aircraft weight factor, and navigation capability. Although there are several hundred different aircraft types found in the real world, in FLAME these are abstracted into just four types: large, medium and small jets, and turboprops. Navigation capability is not currently used for performance modelling purposes; however it is made available to trajectory analysis programs for use in experiment-dependent ways. Aircraft weight is not used directly; instead a quantity called weight factor is used. This is a number in the range 1..9 that represents how fully loaded the aircraft is: 5 represents typical average weight, 1 and 9 represent minimum and maximum operating weights respectively. The justification for this approach is that there is a much greater variation in vertical performance with weight variation within any type than there is from one type to another at average weight. For aerodynamic reasons aircraft normally operate at constant calibrated airspeed (CAS) at low levels, and at constant Mach number at high levels. While either of these quantities is held constant the resulting true airspeed (TAS) varies with altitude, and with temperature deviation from ISA (International Standard Atmosphere) conditions. It is customary to express planned operating speed for a flight phase by a speed schedule, that is simply a CAS/Mach pair. For example, 'climb at 330/0.75' means 'climb at 300 knots CAS until the Mach number has increased to 0.75, and then continue the climb at this Mach number'. This module provides a function for converting a CAS/Mach pair at a given altitude to TAS. To obtain ground speed, the TAS vector has to be combined with the wind vector, and a function is provided for doing this too. When an aircraft climbs or descends, its vertical speed is a complicated function of many variables. This module provides a simple vertical speed model which is sufficient for fast-time simulation purposes. It also provides functions for determining cruise flight level and for doing related climb/descent calculations. A simple model of the rate of fuel consumption is provided. This provides fuel flow rates in arbitrary fuel units, which is sufficient for making comparisons between simulated scenarios. A.7 Airspace Structure Modelling The FLAME Airspace module provides facilities for modelling the following airspace entities and functions: Simulated Region: This is the name given to the geographical region of airspace defined for a set of simulation experiments; it is defined by two parallels of latitude and two meridians of longitude. For flights that begin or end outside the simulated region, FLAME simulates only the portions inside it. Cartesian coordinates are used for calculations of distance etc. inside the region, and a Edition Number: 1 final report Page 3

90 standard map projection technique is used for transforming between latitude/longitude and these Cartesian co-ordinates. Direct Regions: These are regions of airspace where aircraft can fly directly from point to point without being constrained by airways. Military Zones: These are regions that must be avoided by civil traffic. Waypoints: These are named points with defined spatial co-ordinates, which are used for specifying routes, airways, etc. Waypoints have knowledge of which neighbouring waypoints they are connected to by airway segments, and which direct regions (if any) contain them. Waypoints may have height-banded flow restrictions associated with them. Airports: These are named points with defined spatial co-ordinates which can act as sources and sinks for traffic flows. Airports have knowledge of the TMA routes that connect them to the airways system. Airports may have flow restrictions associated with them. Airways: These are paths through the sky defined by lists of waypoints. The airways system as a whole may be thought of as forming a directed graph whose vertices are waypoints, and whose edges are airway segments (see refs 2 to 5 for some of the mathematics of directed graphs). Airways may have altitude restrictions, direction restrictions, and flow restrictions, imposed at various points along their length. TMA Routes: These are like airways, but are used only for routing traffic between airports and either airways or direct regions. TMA routes are defined by lists of waypoints and may have altitude restrictions associated with them. TMA routes may be specified by experimenters, or alternatively, very simple TMA routes may be constructed automatically by the Airspace Input module. Routes: A route represents the path in the horizontal dimension that a flight will take from origin airport to destination airport. It consists of a list of segments; each may be an airway segment, a TMA route segment or a direct-routeing segment. For a flight that begins or ends outside the simulated region, the route represents only the part inside the region. However, the route knows the distance flown before entering and after leaving the region. Route Construction: This is the process of building the list of segments that joins an origin airport to a destination airport. This process requires the ability to find program objects representing waypoints etc. from their names. Experimenters may define route restrictions of the form: traffic from airports x, y, z,... to airports u, v, w,... must go via the waypoints p, q,... Route Navigation: This is the process of navigating along a route and determining the track to be flown for each segment. Control Sectors: A sector is a contiguous volume of airspace that is normally controlled by a single controller or small team of controllers. In FLAME as in the Page 4 final report Edition Number;1

91 real world, sectors may not be of arbitrary shape. In FLAME a sector is composed of a contiguous set of volume elements, each of which is defined by a polygon in plan, and by two horizontal planes in the vertical dimension. A FLAME airspace description may exist in two forms: as readable ASCII text on a file (written by an experimenter), and as a set of linked C++ objects within a running program; this module provides for the latter representation. The translation from readable text to C++ objects is performed by the Airspace Input module. A.8 Conflict Resolution The Conf module provides a conflict resolution (CR) capability for FLAME. The CR rules, methods and manoeuvres implemented are those used for the European Commission's INTENT Project. For each pairwise conflict detected, the Conf module tries various possible resolution manoeuvres, and then chooses and implements one that successfully resolves the conflict. It outputs details of all resolutions attempted and all resolutions implemented to a conflicts log file. It also maintains a list of any unresolved conflicts so that these are not logged over and over again. For each pair of flights predicted to be in conflict, the CR process consists of the following steps: 1. Apply a set of rules (see below) to determine which flight to manoeuvre, and which to allow to continue without manoeuvring (these are sometimes called priority rules). If no resolution can be found by manoeuvring the chosen flight, then try manoeuvring the other one. 2. Try to find both a horizontal manoeuvre and a vertical manoeuvre that resolve the conflict. If both are found, make a random choice with equal probabilities between the horizontal and vertical resolutions. The random part of the process is meant to be a simple model of the fact that, in most situations, a human operator will have to choose between solutions offered by an automated tool. 3. When considering possible CR manoeuvres, each candidate is tested as follows: Does the manoeuvre resolve the conflict being considered? Does the manoeuvre resolve all other conflicts involving the flight to be manoeuvred, and does it avoid generating any new conflicts? Does the manoeuvre avoid violation of military zones? The rules for determining which of a pair of flights to manoeuvre are as follows: 1. If one member of the pair is involved in more conflicts than the other, choose it. Edition Number: 1 final report Page 5

92 2. Otherwise, if both members of the pair are in different phases of flight, choose one in climb rather than one in cruise or descent, and choose one in cruise rather than one in descent. 3. Otherwise, choose the flight farthest from the onset of conflict, that is, the one with the highest ground speed. When searching for a horizontal CR manoeuvre, the first approach tried is skipping the next waypoint and going directly to the one after. If this is unsuccessful, the next approach tried is vectoring by increasing amounts each side of the flight's current track. When searching for a vertical CR manoeuvre, the approach depends on the current vertical state of the flight to be manoeuvred. If it is in climb or descent, than the approach tried is stopping-off the climb or descent at levels intermediate between the flight's current level and its level at the onset of conflict. If the flight is in the cruise phase and near top-of-descent, than the approach tried is making top-of-descent earlier or later than originally planned. If it is not near top-of-descent than different cruising altitudes are tried, in increasing steps below and above the current cruising altitude. Page 6 final report Edition Number;1

93 B. UAS DEPLOYMENT SCENARIOS B.1 Draft Scenarios Draft Scenario 1 Draft Scenario 2 Draft Scenario 3 General Assumptions Voice still primary means of operation Data messages also being used Tactical environment More strategic operations Increased data flow Supporting Infrastructure Similar to today Voice used as main means of communication Data link becomes the main means of communication Voice is available for non-routine and urgent communication Highly automated ATM Data communications is widely Trajectory management accepted System Wide Information Management (SWIM) is in operation Table B-1 Draft Scenario Descriptions Air Traffic Growth Baseline air traffic (background manned traffic in FLAME) UAS will be present in non segregated airspace. The details to be determined in WP3. As per EUROCONTROL Statistics and Forecasts (STATFOR) predictions Assumed to be significant growth of UAS due to wide acceptance of UA applications. The scenarios in the table above will have a mixture of different UAs operating within it; these UAs are presented in the table that follows. UA Application UA Type/payload Description Maritime Surveillance Medium Its payload will include a camera and all images will be sent back to its operational base. Fishery monitoring purposes. UA takes off from UA port 1 (west UK) class G airspace and climbs to an altitude of 5000ft. UA will transit within Class A airspace to North Sea Area and descend to mission altitude of 500ft typically to avoid cloud base. UA will operate within the mission area and perform its monitoring task. Typically, a mission will last 12 hours where UA will return to UA port 1 on completion of mission, by climbing to 5000ft (returning to class A airspace) and transiting to UA port 1 whereby it will descend, land and taxi to stand. Edition Number: 1 final report Page 7

94 UA Application UA Type/payload Description Search and Rescue Medium Camera and multi sensors for detection purposes Mountain rescue in remote region and operations assumed to take place only within Class G airspace. UA takes off from UA port 1 and climbs to an altitude of 2000ft. Transit to mountainous area (terrain requirement possible) Search area UA will descend to an effective search altitude below cloud base and will weave in search pattern around the area to cover land and find target. Typically mission could last up to 10 hours maximum. Once mission is complete will ascend to 2000ft and return to UA port 1 where it will land and taxi to stand National Critical Infrastructure Small Camera and multi sensor with information flow back to operational centre Mission is to follow critical infrastructure: either gas line, power line or telephone line. UA departs from UAV Port 3 and climbs to 5000ft (Class A) Transit to UA mission area 3 where UA will descend to 300ft (Class G) to following path of infrastructure. Capable of 60km tracking a day. Once complete the UA will ascend to 5000ft and return to UA Port 3. It will be possible to retire UA and replace so that mission is ongoing and continuous. Page 8 final report Edition Number;1

95 UA Application UA Type/payload Description Cargo Medium Cargo aircraft type (e.g. B747) Takes off from UA Port 2 which is a relatively large airport operating as cargo hub Performance model of a B747 Takes off and climbs to 35000ft (Class A) transit across EUR to Germany Land at destination airfield (e.g. Munich) and taxis to stand Traffic Monitoring Medium Camera, information passed back to operational centre No predetermined route UAS monitoring traffic in densely populated areas Takes off from UA Port 2 and climbs to 2000ft, transit to UA mission area over London. Hover over desired incident spots within the UA mission area Return to UA Port 2 Edition Number: 1 final report Page 9

96 UA Application UA Type/payload Description Communications Relay High long endurance, high altitude Communication platform Takes off from UA Port 3, carries out a slow spiral climb to mission height and transits to mission area. Performs circular flight acting as a communications relay Mission dimensions: 5NM diameter and a possible height of mission equal to 2000ft Operates for up to 48 hours to be replaced by another Table B-2 Draft Scenario Example Applications Airports used within FLAME for aircraft departure and landing points these also include some new UAS take off and landing points Table B-3 FLAME airports in the volume of interest Page 10 final report Edition Number;1