Joint Authorities for Rulemaking of Unmanned

Systems

JARUS
RECOMMENDATIONS ON THE USE OF
CONTROLLER PILOT DATA LINK
COMMUNICATIONS (CPDLC) IN THE RPAS
COMMUNICATIONS CONTEXT

DOCUMENT IDENTIFIER : JAR_DEL_WG5_D.04

Edition Number : 1.0

Edition Date : 02/06/2016
Status : Final
Intended for : Publication
Category : Recommendations
WG : 5

Disclaimer: This document makes use of parts of ED-228 / DO-350 and ICAO Doc 4444. It utilizes only what is necessary
for States to formulate a common position on CPDLC for RPAS.
It must be used as a working document. Any user intending to make a further use of this document must comply with the
copyright rules of EUROCAE, RTCA and ICAO.
This document is not allowed to be used for commercial purposes. NO COPYING WITHOUT THE WORKING GROUP
PERMISSION
All rights reserved. Unless otherwise specific, the information in this document may be used but no copy-paste is allowed
without JARUS’s permission.
 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

DOCUMENT CHARACTERISTICS

TITLE

JARUS Recommendations on the use of

Controller Pilot Data Link Communications (CPDLC)
in the RPAS communications context
Publications Reference: JAR_doc_07
ID Number: D.04
Edition: V1.0
Edition Date: 02/06/2016
Abstract

Keywords

Data link, application, system, communication, model, architecture

Contact
Tel WG
Person(s)
Dominique +32 272 93182 Leader WG5
Colin

STATUS, AUDIENCE AND ACCESSIBILITY

Status Intended for Accessible via
Working  General Public  Intranet 
Draft
Final  JARUS members  Extranet 
Proposed Restricted  Web site http://jarus-rpas.org 
Internet
Issue

Released  Internal  Share Point 

Issue consultation
External 
consultation

2
JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

DOCUMENT APPROVAL
The following table identifies the process successively approving the present issue of this
document before public publication.

PROCESS NAME WG leader DATE

WG 5 Dominique Colin 04/05/2015

Internal “ 12/05/2015
Consultation

External “ 06/08/2015
Consultation

Approval “ 15/06/2016
Plenary Team

Published “ 20/06/2016

3
 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present
document.
EDITION EDITION
REASON FOR CHANGE PAGES AFFECTED
NUMBER DATE

JARUS WG 5
Dominique Colin
Tel: +32 (0) 2729 9826
Fax: +32 (0) 2729 9078
E-mail: [email protected]

4
 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

CONTENTS

DOCUMENT APPROVAL ....................................................................................................................................... 3

DOCUMENT CHANGE RECORD .......................................................................................................................... 4
CONTENTS .............................................................................................................................................................. 5
LIST OF FIGURES ................................................................................................................................................... 6
1 CHAPTER 1 - INTRODUCTION .............................................................................................................................. 7
1.1 BACKGROUND ....................................................................................................................................................... 7
1.2 PURPOSE OF THIS DOCUMENT ................................................................................................................................... 7
1.3 EXPLANATION OF TERMS .......................................................................................................................................... 7
1.4 REFERENCE DOCUMENTS ......................................................................................................................................... 8
2 CHAPTER 2 – OVERVIEW OF CPDLC FROM ED-228/DO-350 ................................................................................ 9
2.1 GENERAL .............................................................................................................................................................. 9
2.2 CPDLC PERFORMANCE REQUIREMENTS ................................................................................................................... 12
3 CHAPTER 3 – CPDLC IN THE RPAS CONTEXT .......................................................................................................13
3.1 RPAS COMMUNICATIONS ARCHITECTURE.................................................................................................................. 13
3.2 TRANSPOSITION OF CPDLC TYPOLOGY TO RPAS ........................................................................................................ 14
4 CHAPTER 4 – RECOMMENDATIONS ...................................................................................................................18
4.1 GENERAL ............................................................................................................................................................ 18
4.2 EVOLUTION OF THE REFERENCE DOCUMENTS ............................................................................................................. 18

5
JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

LIST OF FIGURES
Figure 1 Overview of the CNS/ATM system (ED-228) ...................................................... 10
Figure 2 Performance and allocation model from ED-228 / DO-350 ................................. 12
Figure 3 RPAS communications ....................................................................................... 13
Figure 4 CPDLC application systems and services in the RPAS context (architecture 1) . 14
Figure 5 RPAS CPDLC architecture ................................................................................. 15
Figure 6 RPAS CPDLC performance and allocation model .............................................. 16
Figure 7 Time sequence diagram for CPDLC in RPAS context ........................................ 16

6
 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

1 Chapter 1 - Introduction
1.1 Background
1.1.1 The CPDLC application provides a means of communication between the controller and
pilot, using data link for ATC communication. CPDLC is a mature technology supported by
the appropriate spectrum and an increasing number of aircraft capable of using it.

1.1.2 CPDLC has been developed and regulated for non-RPAS aviation. It is appropriate to
observe how CPDLC is defined and operated today, look at the impact of RPAS on this
technology and find the best way to accommodate RPAS in the CPDLC environment.

1.1.3 CPDLC is accepted and standardized at the ICAO and regional levels, therefore, it is
recommended that any proposed changes to CPDLC be initiated by the ICAO RPAS panel.

1.1.4 RPAS drives a need for a careful look at operational safety within the context of available
capability of commercial C2 service provider. Since the critical command-control link of the
aircraft system depends on RF performance of RPS-UA radio link, it is bound to impact
RPIL-ATC communication and hence the CPDLC messages.

1.2 Purpose of this document

1.2.1 The purpose of this document is to summarize the most relevant information about CPDLC
and the supported ATS services, and to associate them with RPAS operations.

1.2.2 This document will propose a set of recommendations to review and change EUROCAE
standard ED-228 / RTCA standard DO-350 to cope with the specifics of RPAS. It is
recommended by WG 5 that this document be made available to EUROCAE and RTCA.

1.3 Explanation of terms

1.3.1 Acronyms

ATC Air traffic control

ATS Ait traffic services
ATSP Air traffic services provider
ATSU Air traffic service unit
CPDLC Controller-pilot data link communications
C2 Command and control
ET Expiration time
RCP Required communication performance
RCTP Required communications technical performance
RPA Remotely piloted aircraft
RPAS Remotely piloted aircraft system
RPIL Remote pilot
RPS Remote pilot station
TRN Transaction

Edition: v1.0 Page 7

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

TSD Time sequence diagram

TT Transaction time

1.3.2 Definitions

Term Definition (from ED-228/DO-350)

End System A system that contains the human-machine interface, application

processing, and is distinct from system components interfacing
the communication services.
Note: This definition is modified from RTCA DO-264 /
EUROCAE ED-78A to remove technological dependencies.

Initiator The human and/or machine that initiates a transaction.

NOTE: In some cases a human and a machine may both
contribute to the initiation of a message. For example, a human
may create a route clearance message and a machine may
conduct a conflict probe check on that message and/or append
an altimeter setting before it is released

Required Required Communication Performance is a statement of the

communication performance requirements for operational communication in
performance (RCP) support of specific ATS functions.

Required Required Communication Technical Performance is the set of

communication performance requirements bearing on the technical
communication ATM/CNS elements within RCP.
technical performance
(RCTP) NOTE: RCTP is a statement of the performance requirements
for operational communication limited to the technical
communication portions of the communication process. (ICAO)

Responder A human and/or machine party that is the target of a transaction

and is required to provide an operational response.

TRN Symbol used to designate monitored operational performance.

1.4 Reference documents

The references in this document are listed below:
a. ICAO Doc 4444
b. ICAO Doc 9869
c. ICAO Doc 10019
d. JARUS RPAS C2 Link RCP concept V1.0
e. EUROCAE ED 228 / RTCA DO-350
f. EUROCAE C3 CONOPS

Edition: v1.0 Page 8

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

2 Chapter 2 – Overview of CPDLC FROM ED-

228/DO-350
2.1 General
2.1.1 Description

2.1.1.1 The data link services provide communication and surveillance capabilities for the ATSU
to perform the following ATS services:
a) provide supplemental means to the controller to obtain information on the current
position, actual progress, and intended movement of each aircraft for performing
separation management;
b) provide supplemental means to the controller to issue clearances and information
for performing separation management;
c) provide supplemental means to the flight crew to obtain clearances and instructions;
and
d) provide primary or supplemental means to the flight crew to obtain flight information.

2.1.1.2 Data link services for ATS applications are characterized as follows:
a) used in situations where the delay or loss in operational data communications is not
significant to the safety of operations. Delay or loss in operational data
communications may be significant to operational usefulness of the system.
b) procedures are established to revert to ATC voice communications, as required by
operating rules, and within acceptable time limits when data link service can no
longer be provided.
c) required ATC communication, e.g., VHF voice, has the functionality and
performance to satisfy the operational capability provided by the data link services
in the event of loss of those data link services.
d) provides sufficient integrity of operational communications to avoid the need for
procedural mitigation of anomalous

2.1.1.3 The CPDLC application provides a means of communication between the controller and
the pilot, using data link for ATC communication. This application includes a set of
clearance / information / request message elements which correspond to the
phraseologies used in the radiotelephony environment.
a) The controller is provided with the capability to respond to messages, including
emergencies, to issue clearances, instructions and advisories, and to request and
provide information, as appropriate.
b) The pilot is provided with the capability to respond to messages, to request
clearances and information, to report information, and to declare or cancel an
emergency.
c) The pilot and the controller are provided with the capability to exchange messages
which do not conform to defined formats (i.e. free text messages).

Edition: v1.0 Page 9

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

2.1.1.4 Ground and airborne systems allow for messages to be appropriately displayed, printed
when required and stored in a manner that permits timely and convenient retrieval should
such action be necessary.
2.1.1.5 The high level description of the systems and services involved in support of the CPDLC
application is provided by figure 1.

Figure 1 Overview of the CNS/ATM system (ED-228)

2.1.1.6 Stakeholders roles and responsibilities and their interrelationships to ensure the
compatibility and interoperability of the system elements are described in ED-228/DO-
350.

Edition: v1.0 Page 10

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

2.1.2 Apportionment of CPDLC

2.1.2.1 Annex D / page D-10 of ED-228 describes the allocation for CPDLC. The performance
requirements are provided against human and ATM/CNS elements of the data
communication transaction.
- The ATM/CNS elements are:
- Aircraft system
- Aircraft operator
- ATS provider
- Communication service provider
2.1.2.2 A CPDLC transaction is apportioned into ATM/CNS components for
- Composition and recognition processing (initiator)
- Monitor transaction (TRN)
- Reaction (responder)
- Technical communication (Technical system)
2.1.2.3 The technical system is further broken down into 3 technical sub-systems:
- Aircraft system
- Air traffic service unit (ATSU)
- Communication service provider (CSP)
Each portion has to comply with performance requirements defined by the supported Air
Traffic Service (ATS) function and desired operational environment.

2.1.3 Required communication performance (RCP)

2.1.3.1 The Required communication performance (RCP) is composed of the requirements of

each of these three portions.
For transaction time, the formula used is:
RCP = Initiator + (RCTP + Responder) = Initiator + TRN

Edition: v1.0 Page 11

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

2.1.3.2 The TRN (transaction)

- starts when the initiator portion ends
- ends when the initiator receives an indication of the operational reply.

2.2 CPDLC Performance requirements

2.2.1 The performance requirements are stated in terms of RCP parameters, RCP 1 allocations
and TRN allocations.

The allocation table clarifies the sequence and the RCTP apportioned to each of the 3
technical sub-systems (ATSU, CSP and aircraft):

RCP specification (transaction time, continuity, availability, integrity)

Monitored operational performance (TRN)

Flight crew reads and

Aircraft system Aircraft system ATSU decodes
responds to the ATSU CSP sends Controller reads
Controller ATSU encodes CSP transmits decodes ATSU encodes response response
message (i.e. a response the response
composes message and ATSU message to message and message and message and
composed response message to the message (if
message send it to the CSP the aircraft gives it to the flight transmits to the gives it to the
message or a wilco ATSU present)
crew CSP Controller
response)

A B C D E F G H J K
performance

performance
Initiator

Initiator
RCTP RCTP RCTP RCTP
ATSU CSP CSP ATSU
Responder
performance
RCTP RCTP RCTP RCTP
Aircraft ATSP
ATSP Aircraft

Figure 2 Performance and allocation model from ED-228 / DO-350

2.2.2 The RCP specification parameters described in the standard are:

- delay values for expiration time (ET),

- Transaction time for 95% of all transactions (TT(95%)),
Note : Transaction time are apportioned per components and
technical systems
- Continuity (ATSU, CSP and Aircraft),
- Availability (ATSU, CSP and Aircraft) and additional outage parameters
for ATSU and CSP,
- Integrity (ATSU, CSP and Aircraft).

1
as described in ICAO Doc 9869.

Edition: v1.0 Page 12

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

3 Chapter 3 – CPDLC in the RPAS context

3.1 RPAS communications architecture
3.1.1 RPAS communications are commonly broken down as depicted in figure 3. RPAS
communication architecture regarding data communications with ATC is one of the
following:

- The RPA receives information directly from the ATSP communication

service provider and relays it to the remote pilot (architecture type 1,
similar to manned aviation), or
- There is an additional network, separate from the ATSP communication
service provider, that passes the information to the RPA before the RPA
relays it to the remote pilot (architecture type 2) , or
- A direct communication line, which is not relayed by the RPA, is set
between ATC and the remote pilot (architecture type 3).

3.1.2 Architecture type 1 has the most similarity with the current ATS data link communications
architecture. Architecture types 2 and 3 are of a totally different nature and no standards
have been developed yet to support them.

3.1.3 This document will focus on architecture type 1 only. Architecture types 2 and 3 will have to
be considered in the future, when RPAS deployment will:

- be mature enough to justify investing into this new communications

system architecture, or
- generate a saturation effect on available communications spectrum due
to a dramatic increase of the overall traffic.

RPAS
datalink

* RPAS C2 link is sometimes RPAS C2 RPAS

called CNPC link
link* payload link

Remote pilot / ATC

RPAS
communications
control link
link**
** This describes architecture 1. With architectures 2
and 3, this link is not supported by the RPAS C2 link

Telecommand Telemetry
link link

Figure 3 RPAS communications

Edition: v1.0 Page 13

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

3.1.4 The ED-228/DO-350 time sequence diagram describing the CPDLC transaction should be
modified to be compatible with the RPAS communication system architecture.

3.1.5 It is assumed that an RPAS will have to meet the same CPDLC RCP than manned aviation
in the same operational context (e.g. RCP 240, RCP 400…).

3.2 Transposition of CPDLC typology to RPAS

3.2.1 Description of the elements

3.2.1.1 According to ICAO Document 10019, RPA is the aircraft. But substituting “aircraft” by
“RPA” in ED/228/DO350 would be functionally inoperative because the ATM data could
not reach the remote pilot.
3.2.1.2 To meet the functionalities of the CPDLC operational capability, and to be in line with
ICAO Doc 10019, the aircraft system element from figure 1 must be replaced by a RPA
element, a command and control link (C2 link) and a RPS element. Those substituting
elements must meet the same performance requirements as the former “aircraft”. All the
other elements remain the same as components of the current service (figure 4).
3.2.1.3 The main differences to address in the RPAS context are:
- There is another communications service (RPAS C2 datalink) between the aircraft
communications system and the remote pilot/HMI. This communication service is
of the responsibility (contracted or directly provided) of the RPAS operator; it is not
the same communication service provider described in ED-228 / DO-350.
- There are communication systems, data processing and interfaces on board the
RPA and in the RPS.
Operator

RPS Element RPA Element

Procedures
(Flight deck) RPA Communication System

RPS data Interface to Interface to

Interface to
processing C2 link C2 link Data
Communication
Communication Communication processing
Services
Remote pilot HMI Services Services

RPAS C2 Air-Ground Communication

link

Communication
Air Traffic Service Services
Provider Air Traffic Service Unit (ATSU) B

Air Traffic Service Unit (ATSU) A

Ground-Ground
Procedures Communications
(ATSU)
ATSU system
End system
Flight
(ATSU) Data
information
Communication
data sources
Controller HMI Interfacility
Communications

Figure 4 CPDLC application systems and services in the RPAS context (architecture 1)

Edition: v1.0 Page 14

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

3.2.2 Description of the portions of the CPDLC RCP model

3.2.2.1 The current apportionment of RCTP in ED-228 / DO-350 to the aircraft implies that the
RPA, the RPAS C2 link and the RPS are composing the aircraft allocation, each of them
being allocated with a RCTP. It leads to an updated architecture model (figure 5).

Responder
RPAS performance
crew
F
E
RLTP (RPS)
F’

D’’
RPAS RPAS C2 link
RLTP (C2 link SP) RCTP
F’’
Aircraft
G RLTP (RPA) TRN
D’
D RCP
CSP ATS RCTP (CSP) specification
datalink

H RCTP
ATSP
C
RCTP (ATSU)

J
ATSU B

Initiator
performance
K
A

Figure 5 RPAS CPDLC architecture

The C2 Link RCP parts are being changed into RLP to be consistent with the approved
JARUS terminology on the “RCP” concept applicable to the C2 Link.

Edition: v1.0 Page 15

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

3.2.2.2 The apportionment has to be refined as there are additional sub-systems contributing to
the performance at the aircraft level. The [D,E] and the [F,G] portions have to be broken
down in 3 sub-portions. The letters D’ and D’’ (respectively F’ and F’’) are introduced to
take into account the RPA, the C2 link and the RPS sub-systems (figure 6). Figure 4
describes the RPA, the C2 link and the RPS parts as the “RPA communication system”,
the “RPAS C2 link” and the “RPS element”.

RCP specification (transaction time, continuity, availability, integrity)

Monitored operational performance (TRN)

Flight crew reads and

Aircraft system Aircraft system ATSU decodes
responds to the ATSU CSP sends Controller reads
Controller ATSU encodes CSP transmits decodes ATSU encodes response response
message (i.e. a response the response
composes message and ATSU message to message and message and message and
composed response message to the message (if
message send it to the CSP the aircraft gives it to the flight transmits to the gives it to the
message or a wilco ATSU present)
crew CSP Controller
response)

A B C D E F G H J K
performance

performance
Initiator

Initiator
RCTP RCTP RCTP RCTP
ATSU CSP CSP ATSU
Responder
performance
RCTP RLTP RLTP RCTP
Aircraft ATSP
ATSP RPAS

RLTP RLTP RLTP RLTP RLTP RLTP

RPA C2 link CSP RPS RPS C2 link CSP RPA

D’ D’’ F’ F’’
[Aircraft = RPAS = RPS + C2 link + RPA]

Figure 6 RPAS CPDLC performance and allocation model

The CPDLC time sequence diagram (TSD) is therefore refined as depicted in figure 7:
RPAS ATSP

ATSU

RPA Communications
Remote pilot RPS data RPAS C2 Communication Service Encoding and Controller
/HMI processing datalink system Provision transmission /HMI

Relationship of the portion requirements to TSD

A
Time, continuity, availibility & integrity

C B
D
RLTP D’’ D’
RCP E
TRN Responder
Initiator
F F’ F’’ G H J

Figure 7 Time sequence diagram for CPDLC in RPAS context

Edition: v1.0 Page 16

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

3.2.2.3 In ED-228/DO-350, the performance parameters are set taking into account the safety
levels and the operational environment. It is very unlikely that the values will be increased
to accommodate the additional RPAS sub-systems and especially the C2 datalink
performance, when used for CPDLC purposes.
3.2.2.4 This means that if the C2 link is used to support ATS/voice data services, the RPAS
design (and C2 link service provision) will have to comply with the aircraft performance
parameter from ED-228/DO350 (RCTPaircraft) and its associated availability, continuity and
integrity requirements, regardless of the specific design of an RPAS compared to a
manned aircraft.
3.2.2.5 Future work plan for JARUS WG 5 could include a study on the relevance of setting
availability, continuity and integrity parameters for the C2 link provision unplanned outage.

3.2.3 Demonstration of compliance

3.2.3.1 The aircraft installer should demonstrate compliance to RCP aircraft allocations, and
necessary interoperability to provide assurance that the ground control station and UA are
compatible with other components of the CPDLC system with which they interface with,
as well as post implementation monitoring and corrective action of the RCP aircraft
allocations.
3.2.3.2 In accordance with existing acceptable practices, when the operator establishes their
contracts with the Communication Service Providers (CSP) it is imperative that they
include the required RCP criteria allocated to CSP; and the operator’s responsibilities
include operationally monitor, detect and resolve non-compliant performance for the RCP
operator allocations.

Edition: v1.0 Page 17

 JARUS Recommendations on the use of Controller Pilot Data Link Communications (CPDLC)

4 Chapter 4 – Recommendations
4.1 General
4.1.1 Chapter 3 demonstrated that the application of ED-228 / DO-350 in the RPAS context
includes additional sub-systems, internal to the RPAS. Those sub-systems have to comply
with the aircraft performance parameters

4.1.2 This is a design constraint for the RPAS manufacturers. If the C2 link communication
provision is contracted, the operator must demand the C2 Communication Service Provider
to comply with the RCP.

4.1.3 JARUS recommends having a harmonized approach towards this issue in order to have a
consistent C2 communications service provision contractual framework for all operations.

4.1.4 For the RPAS, the “aircraft system” is composed of three sub-systems. The design of the
RPAS will need to consider criticality of the communication transaction time in the
performance assessment.

4.2 Evolution of the reference documents

4.2.1 ED 228 / DO 350 standards

4.2.1.1 Some changes would be necessary in ED-228 / DO-350 to better take into account the
RPAS operations.
4.2.1.2 It is recommended that ED-228 / DO-350 be amended to include a new section describing
the sub-allocation of RCTPaircraft (becoming RLTPRPAS).
4.2.1.3 It is recommended that when updating the standard performance metrics, the working
groups take into account RPAS as new airspace user when apportioning the performance
to the different sub-systems (especially the aircraft component).
4.2.1.4 It is recommended that the standardization working group discuss the relevance of setting
availability, continuity and integrity parameters for the C2 link provision unplanned outage,
creating a new set of parameters in a standard.
4.2.1.5 It is recommended that CPDLC message specifications in ED-228/DO-350 on
phraseology and protocol are updated to accommodate CPDLC RPAS comm.

4.2.2 ICAO Documents

4.2.2.1 As a first assessment, nothing fundamental will be required. The documents mainly
requires including RPAS terms and specifics.
4.2.2.2 For Example PANS ATM section 14.1.3 states “Ground and airborne systems shall allow
for messages to be appropriately displayed, printed when required and stored in a
manner that permits timely and convenient retrieval should such action be necessary”.
For RPAS, the notions of ground and airborne are blurred, especially because the remote
pilot could be on the surface (ground, maritime), or airborne in another aircraft. Such
sentences could either be modified or a note could be added to adapt to RPAS.
4.2.2.3 In general, any text referring to “airborne” or “pilot” (e.g. title of PANS ATM 14.2.2 section)
has to checked and be adapted accordingly.

Edition: v1.0 Page 18