COMMUNICATIONS PANEL. WG-I 20 Meeting

Size: px

Start display at page:

Download "COMMUNICATIONS PANEL. WG-I 20 Meeting"

Emory Armstrong
5 years ago
Views:

International Civil Aviation Organization CP/WG-I20/WP-04 29/02/2016 WORKING PAPER COMMUNICATIONS PANEL WG-I 20 Meeting Montreal, Canada 29 Feb 4 Mar, 2016 Agenda Item xx: Title: IP Environment for

1 International Civil Aviation Organization CP/WG-I20/WP-04 29/02/2016 WORKING PAPER COMMUNICATIONS PANEL WG-I 20 Meeting Montreal, Canada 29 Feb 4 Mar, 2016 Agenda Item xx: Title: IP Environment for UAS Presented by Bruce Eckstein SUMMARY This working paper describes a high level view of the information flows to support Unmanned Aeronautical System (UAS) connectivity that the Internet Protocol Suite (IPS) should provide for in the upgrade of the existing IPS standards for Air/Ground (A/G) communications to include UAS communications. ACTION It is recommended that the WG-I consider ensuring that the IPS accommodates the UAS in establishing the standards for A/G IPS. In addition, WG-I should recommend any changes in the G/G IPS necessary to accommodate UAS. 1. INTRODUCTION 1.1 The ICAO Communications Panel (CP) produced a standard that addressed the networking of ground applications to other ground applications using the Internet Protocol (IP) as appropriate for aviation's Internet Protocol Suite (doc 9896). Working Group I of the CP has been assigned the task of developing the A/G communications standard for IPS. The current architecture that the standard for A/G IPS is being developed supports manned aircraft. The information flow for the manned aircraft environment is a well understood communications environment. A new aircraft type is coming forward on a worldwide basis that A/G IPS needs to address. That aircraft type is the unmanned Page 1 of 6

aircraft. This paper proposes the unmanned communication environment that the A/G IPS should also address to ensure that IPS appropriately addresses unmanned aircraft as well as manned aircraft. 2.

2 aircraft. This paper proposes the unmanned communication environment that the A/G IPS should also address to ensure that IPS appropriately addresses unmanned aircraft as well as manned aircraft. 2. UNMANNED AIRCRAFT OPERATIONAL ENVIRONMENT 2.1 Within the Unmanned Aircraft System (UAS) environment are many of the same applications as in the manned aircraft environment. How these applications are connected and where the applications are located is different than for manned aircraft. Figure 1 UAS Environment shows the environment that a UAS will exist within from a UAS prospective. Figure 1 UAS Environment 2.2 The key issues to extract from Figure 1 for the IPS is that there are Air Traffic Services (ATS) functionalities located on the ground, aircraft functionalities located in the air, and aircraft functionalities located on the ground. From a US prospective these UAS will be integrated into the National Aerospace System (NAS) and are to be capable of file and fly the same as a manned aircraft does today. For the UAS to integrate into the airspace, communications between all 3 of these locations are required. Figure 2 UAS Information Flows described below indicates the major classes of applications and the flow of information between them. Page 2 of 6

3 Figure 2 UAS Information Flows 2.3 The Unmanned Aircraft (UA) will have Command and Control (C&C) and Status applications. Information from the C&C must be exchanged with the Ground Control Station (GCS). In addition, UA Status must flow from the UA to the GCS for display to the operator. 2.4 Airborne Detect and Avoid (ABDAA) may be a capability on the UA. For the ABDAA, Information must flow from the UA ABDAA to the GCS. Processing and recommendation generation for display to the operator occurs on both the UA and the GCS. The GCS displays provide situational awareness based in part on the downlinked information and ABDAA recommendations to the operator. The operator s actions (whether automatically linked from the DAA or manually entered into the C&C ground functionalities exchange data with the UA. One of the key definitions of ABDAA is that the surveillance sensors (such as Radar) must be on the UA. Radar is being defined as one of the key surveillance detectors for non-cooperative aircraft that feed the Detect and Avoid (DAA) processes. Airborne Radars have a limitation that they do not preform very well as the UA platform gets closer to the ground due to ground clutter processing. As a consequence of this altitude limitation, alternative means must be used to support the UA operations when below this altitude. One of the alternatives is to have a Ground Based DAA (GBDAA). GBDAA using ground based sensors (e.g. Radar, ADS-B, etc.) which does not suffer the serious degradation in performance as the UA nears the ground can provide critical information to the DAA service to low altitude where there is sufficient coverage. Due to size, weight and power implication some UAs will use GBDAA as the sole source of DAA functionality. For other UAs, ABDAA will provide sole source of DAA functionality (using other means to transit to altitudes where the Radar does not meets performance requirements) and yet another scenario where the UA will start with GBDAA, transition to ABDAA and then back to GBDAA during the mission for the UAS. These various scenarios imply connectivity that the IPS system should be able to support. Page 3 of 6

4 2.5 In the early implementations of the UAS, due to limitations of the FAA ground system, the UA will be expected to transfer ATC voice communications (e.g. VHF AM voice) between the UA and the GCS. It is expected that the UA will convert the ATC voice to/from Voice over IP (VOIP) for transfer with the GCS supporting interaction of ATC with the UA operator. Shown as a future flow in Figure 2 is that the method of voice communications between the UA operator and ATC may transition to a ground/ground (G/G) method of communication in the future when the FAA ground voice switches/system can support it. 2.6 The UA will also have one or more user applications on-board to support the collection of payload data. Some of these applications will transfer data real time to applications on the ground. Further these applications are not planned to flow this user data over the same communications links as the RF links that provide the transfer of Safety Services information which includes the C&C, UA Status, ABDAA information, and ATC Voice. 2.7 The UAS operator will also need to communicate via data link to the ATC. The applications for this (e.g. CPDLC and ADS-C) have been worked in the past for manned aircraft. The difference is that in the UAS case, there is not the need to transmit the data link messages in the RF to the pilot. These datalink communications can be linked to the operators GCS over G/G communications. Any data link communications necessary to be transferred to the UA can be forwarded via the C&C functionalities over the appropriate links. This has advantages in the areas of spectral capacity, size weight and power (SWAP), costs, availability, etc. Other ATS services would also be accessed by the UAS operator over G/G links which are labelled as Aeronautical Information Systems (AIS) in Figure The UAS may also have IP communications links with a UAS Traffic Management System (separate from the FAA system) which accepts requests from the UAS flight personnel and provides authorizations for flight of the UAS under quantified conditions. 2.9 In addition, the UAS has a need to provide GCS to GCS handoff communications. This scenario is in addition to the handoff of the UA from one radio ground station to another where the RF ground stations involved might be either ground based radio site, satellite system or both. The longevity of operations of a single UA can be from hours to many days, utilize multiple instances of RF links, multiple GCS and multiple pilots to achieve the mission The final type of communications that will need to be provide is an A/A from one UA to another UA. The A/A is, at a minimum, to support the SWARM concept of UAS operations. A SWARM consists of a number of UAs that work in cooperation with each other to achieve a mission. As a consequence of this type of scenario, low latency links are required to support these kinds of operations and are not perceive to afford the longer latency of transferring the communications thru ground links from one UA to another UA. A second form of SWARM scenario is very similar to the first but in this case the multiple UAs each have separate missions working in the same physical airspace but with different to very similar missions (e.g. multiple news services getting information on an incident of interest) Each of the above information flows should be supported by the IPS. To achieve this information flow, Figure 3 UAS Architecture identifies a high level connectivity diagram that the IPS needs to provide capabilities. Page 4 of 6

Figure 3 UAS Architecture 2.12 Figure 3 UAS Architecture identifies that both an IPS networking capability or an ATN capability may exist in the GCS.

5 Figure 3 UAS Architecture 2.12 Figure 3 UAS Architecture identifies that both an IPS networking capability or an ATN capability may exist in the GCS. In the US, this data link capability may be either ATN or FANS data link networking over ACARS. In Europe it may also include OSI networking capability. Also note that the perceived IPS Security Dialog Services have been noted on the diagram. On the diagram, the identification of the Comm Service Provider (CSP) is not meant to indicate that there is only one or even that on a single UA that is a single CSP to provide all communications over the mission. The CSP may consist of multiple business entities or just a single entity depending on the specific area of operation. In addition the 2 IP networks indicated on the UA are to signify the separation of the Payload data from the Safety Services and not necessarily to imply a separate physical instantiation of IP Networking capabilities The multiple RF links shown on Figure 3 UAS Architecture may all exist on the aircraft simultaneously. Both the Payload link and one or more of the Satellite/CNPC1/CNPC2/CNPC A-A may all be in use at the same time. It is not clear at this time, if CNPC A-A needs to be an IP link but it is assumed that it is. The ATC voice, which is generally perceived as VHF voice in today s system, is expected to be converted to/from a data format such as VOIP for transfer between the GCS and the UA. 3. CONCLUSION 3.1 The required connectivity to support UAS in the airspace is different than the connectivity required to support manned aircraft. Larger volumes of timely information are transferred between the UA and the ground and are transferred to a number of sites. These larger volumes of information are due to the command and control structure of the UA as well as the user data collection Page 5 of 6

6 that occurs on the UA. Simultaneous transfers of Safety information over multiple RF links are perceived for UAS. 4. RECOMMENDATION 4.1 It is recommended that the WG-I consider ensuring that the IPS accommodates the UAS in the standards for A/G IPS. In addition, WG-I should recommend any changes in the G/G IPS necessary to accommodate UAS. Page 6 of 6

INTERNATIONAL CIVIL AVIATION ORGANIZATION WESTERN AND CENTRAL AFRICA OFFICE. Thirteenth Meeting of the FANS I/A Interoperability Team (SAT/FIT/13)

INTERNATIONAL CIVIL AVIATION ORGANIZATION WESTERN AND CENTRAL AFRICA OFFICE Thirteenth Meeting of the FANS I/A Interoperability Team (SAT/FIT/13) Durban, South Africa, 4-5 June 2018 Agenda Item 4: System