AMCP-WG C 1ST MEETING
11 - 19 OCTOBER 2000
Agenda Item 1: Introduction
1.1 The first meeting of the International Civil Aviation Organization (ICAO) Aeronautical
Mobile Communications Panel (AMCP) Working Group C (WG-C) was held 11 - 19 October
2000 at the International Air Transport Association (IATA) Headquarters in Montreal. Mr Kors
van den Boogaard welcomed WG-C to IATA.
1.2 The WG-C thanked IATA for the hospitality received and for the professional manner
and thorough planning evident in Ms. Dorothy Williams‟ preparation for the meeting.
1.3 The Agenda for the meeting and an overview of the working papers were provided (see
Attachment A and B respectively). Attendees introduced themselves and the attendance list is
contained in Attachment C.
Agenda Item 2: Results from AMCP/7 - Inventory of Working Group C activities.
2.1 Working papers (WP) 3, 4, 5 and 9 were presented. It was agreed that the overview of
WG-C activities contained in the report of AMCP/7 (WP 4) will be used as the basis for the work
programme of WG-C, further discussed under Agenda Item 12. The relevant extract from the
AMCP/7 report is in Attachment D.
Agenda Item 3: Operational Requirements.
3.1 No working papers were received under this Agenda Item. The ICAO secretariat stated,
that, after internal co-ordination with the ICAO Air Traffic Management Concepts Panel
(ATMCP) secretary it was agreed that the development of the operational ATM concept for
beyond 2010 per recommendation 4/2 of AMCP/5, did not have the maturity to be considered by
AMCP. The only document that could be of use at present is the draft document on Required
Communication Performance (RCP) (discussed under Agenda Item 4) as developed by ICAO‟s
Operational Data Link Panel (OPLINKP).
3.2 WG-C expressed its disappointment with the lack of a clear ATM concept and questioned
whether WG-C should look at the communication infrastructure beyond 2010. However,
considering the long lead-time in aviation for developing, standardising, certifying and
implementing a new infrastructure it did not have a choice but to start. It was agreed that it
would be necessary to make assumptions on the perceived “ATM requirement”. These
assumptions would be co-ordinated with the appropriate panel.
Agenda Item 4: Required Communication Performance
4.1 WP 8 and WP 7 were presented containing the Concept of Required Communication
Performance Version 1.1 developed by the OPLINK Panel and the comments of the Aeronautical
Telecommunications Network Panel (ATNP) respectively. The meeting was made aware that
the week before WG-C the OPLINK panel held a Working Group meeting in Berlin and issued
Version 1.4 of the RCP requirements. After co-ordination between the ICAO secretaries it was
agreed that WG-C would use Version 1.4 (see WP 23) to provide its comments to the OPLINK
4.2 WG-C comments on the Concept for RCP Version 1.4 are reflected in the communiqué
for AMCP WG-C to the OPLINKP (Attachment E). WG-C questioned the real value of these
comments, as it is very doubtful that the present document can be used to determine the RCP
type in a specific airspace but more importantly how operational approval could be achieved.
Furthermore, it was noted that although OPLINKP worked for more than 4 years after the
request from AMCP the result was only a partial definition of the required communication
ACTION WGC/1-1: The ICAO AMCP secretariat to bring Attachment E to the attention of the
ICAO OPLINK Panel secretariat.
Agenda Item 5: VDL implementation
5.1 No working papers were received on the VDL implementation. At the meeting the FAA
presented its VDL Mode 3 implementation programme (NEXCOM) and the Swedish CAA
presented an update of the VDL Mode 4 programme.
5.2 The FAA intends to implement an initial set of non-time critical controller-to-pilot data
link communications (CPDLC) messages in 2001 (Build 1/A) using VDL Mode 2 via a service
provider. The VDL Mode 3 contract to acquire multi mode radios to support the US NEXCOM
program will be awarded in the same time frame. ATC voice services will begin to use VDL
Mode 3 in the upper airspace in 2008. Migration of ATC VDL Mode 3 data communication
services, such as CPDLC and pre-departure clearance (PDC) are planned to begin in 2010. The
current analogue voice will be supported in the lower classes of airspace at least until 2015.
5.3 Eurocontrol presented the strategy for Mobile sub-networks for Europe based on the
roadmap attached to WP 16. A first endorsed step includes the introduction of VDL Mode 2
starting around 2003 and the horizontal expansion of the 8.33 kHz in the upper airspace of 28
States in October 2002. This stable step is recognised to fulfil the known requirements up to
A second step is currently considered, including the utilisation of 8.33 kHz in lower airspace,
VDL Mode 4 for Communication services and VDL Mode 3 around 2010. Considering the
frequency availability issues in Europe, the assessment of a new system is also included in this
second step. VDL Mode 4 is also considered for ADS services with a potential global
introduction around 2006. No decision has been taken for the introduction of the systems on a
global basis as part of this second step. Local implementation for ADS-B based on VDL Mode 4
will start around 2003.
5.4 On VDL Mode 4 the NEAN (North European ADS Broadcast Network) Update
Programme Phase II (NUP), North Atlantic ADS-B Network Update programme (NAANUP)
and Mediterranean Update Programme (MEDUP) were presented. The programmes are intended
to deliver an extensive pre-operational ADS-B platform in the participating states supporting
various ADS-B applications. It is aimed to integrate ADS-B in some operational ATC centre by
2003 and introduce Air/Air application by 2005.
ACTION WGC/1-2: WG-C to request AMCP Panel members to provide updates on VDL
Agenda Item 6: Review of the Annex 10 radiotelephony procedures
6.1 WP 10 contained proposals to amend the Annex 10 radiotelephony procedures with the
objective to include possible new procedures associated with the introduction of data
communications and satellite communication. Some of the proposed amendments were accepted
by WG-C and would be dealt with by the ICAO secretariat. However there was a general feeling
that there was a certain inconsistency in others.
6.2 For satellite communication a note was already included in Annex 10 stating that the
established VHF procedures for SATCOM shall be used where applicable. In conclusion WG-C
agreed that Annex 10 radiotelephony procedures should be revisited as follows:
a) To address where the present VHF voice procedures would be applicable for satellite
communication and if new specific procedures are required.
b) To address where the present VHF voice procedures would be applicable for VDL Mode 3
and if new specific procedures are required.
c) To address to what extent there is a specific need to include pilot/controller procedures for
the use of data link.
ACTION WGC/1-3: WG-C to revisit the Annex 10 radiotelephony procedures.
Agenda Item 7: Future systems
7.1 WP 6 describing the ICO Aeronautical Services Concept was treated as an information
paper, as no message was received that ICO intended to provide communication to conform to
7.2 WP 11 enhanced by a visual presentation informed the meeting on the status of the
Universal Access Transceiver (UAT). The UAT has been designed from a “clean slate”
specifically for ADS-B and other related broadcast data link applications. UAT operates on a
single common channel in all airspace and the band 960-1215 MHz was chosen for UAT due to
its 1 MHz channelization and its designation as an Aeronautical Radio Navigation Service
More recently, UAT has been selected by the FAA‟s Alaska Region as part of their
Capstone Program. Capstone is a safety improvement initiative, which initially will include the
installation (at FAA expense) of production UAT radios and display systems in approximately
140 air taxi aircraft and establishment of UAT ground stations at approximately 12 sites. A key
operational objective of Capstone is to use UAT/ADS-B in an area of Western Alaska - with
little or no radar coverage - to provide “radar-like” ATC services. Currently about 60 aircraft
installations have been completed and the end-to-end ADS-B system including the Anchorage
Center automation system is being validated. The target date for initial ATC “radar-like”
services is 1 January 2001. Upon successful completion of this initial phase of the program,
plans are to develop infrastructure state-wide in Alaska. Work is continuing on the development
of technical descriptions and validation, which could serve as the foundation for SARPS if they
7.3 WP 17 reported on the progress of the wireless communications around airports. At
present the AEEC (Airlines Electronic Engineering Committee) Aircraft Network File Server
sub committee mainly conducted the developments. WG-C noted four basic issues, which could
significantly reduce the feasibility of the wireless “gate link” as an ATS/AOC data link. These
a) The specific gate link is not designed to be an ATN compatible sub-network but the
internetworking is based on Internet Protocol (IP).
b) It is intended to operate in the 2.4 GHz industrial, scientific, and medical (ISM) equipment
band and thus will not receive the regulatory safety protection for aeronautical
c) There are 13 patents on the DSSS (Direct Sequence Spread Spectrum) mode of operation,
d) The various options for its operation (e.g. FHSS or DSSS) could prevent global
It was noted that a possible introduction of this system might relieve the congestion in the VHF
7.4 WP 19 introduced the dilemma of the fast pace of the technological innovations. This
pace far exceeds the ability of civil aviation to adjust and adapt the aviation regulatory
infrastructure so these new technologies could be properly evaluated for their potential to be
introduced for aeronautical safety services. It is likely that the passengers will enjoy
communication systems that are in some aspects superior to the systems used for ATC safety
services. An illustrative example is the increased offering of broadband communication system
supporting Internet services to passengers, while the access from the cockpit to air ground
databases are not even contemplated. An important element is how future aeronautical safety
communications should be conducted.
7.5 WP 20 addressed the potential of VDL-4 to support communications applications such as
CPDLC.. Although VDL Mode 4 SARPs were validated only for surveillance, they didn‟t
preclude the use of VDL Mode as an ATN sub-network. Since VDL Mode 4 SARPs were
accepted at AMCP/7 and by the ANC, WG-C agreed that WG-M would be appropriate WG for
consideration of the recommendation of WP 20. WG-M has responsibility for maintenance and
changes to all AMCP SARPs. During discussion, one State expressed concern about expanding
use of VDL Mode 4 beyond surveillance without validation of CPDLC and other communication
applications. It was agreed that WG-C would request AMCP WG-M to validate the sue of VDL
Mode 4 as a communication system.
7.6 WP 21 provided an update on the European Space Agency Sponsored development of a
service demonstrator for a future dedicated air/ground safety satellite communication system. A
contract has been awarded to study and design a Satellite Data link System (SDLS) Service
Demonstrator. It is intended that after validation of the technical performance of the SDLS, it
will be offered for operational evaluation.
7.7 WP 22 contained a draft of requirements and key features for a future aeronautical
communication system, either terrestrial or satellite based, to cope with high air traffic density
airspace. It presented some results from an European Community (EC)-funded project on
emerging technologies and more specifically the potential use of next generation satellite
systems (NGSS) for ATM. WG-C felt that this proposal, as well as the ETDMA (Enhanced
Time Division Multiple Access) concept (although this proposal has been put on stand-by), could
be further pursued, if necessary.
7.8 WP 25 reported that the United States Federal Communications Commission moved to
the next step in its process of establishing policies and service rules for the Mobile Satellite
Service in the 2 GHz band by adopting a Report and Order on 14 August 2000. The Boeing
filing in this proceeding proposed to provide AMS(R)S in this band. The Report and Order
states that AMSS is an example of MSS and that AMSS includes AMS(R)S. The meeting noted
that this assertion is not consistent with the present rules within the aviation regulations, such as
ICAO standards and recommended practices.
ACTION WGC/1-4: WG-C to draft a communiqué to WG-M requesting that validation will be
initiated for VDL Mode 4 as a communication system, including the ATN complaint CPDLC
application and the broadcast communication application.
Agenda Item 8: VHF need beyond 2010
8.1 WP 15 and 16 presented the developments with the implementation of 8.33 kHz in the
European Airspace. It is expected that after 2002/3 the demand for voice channels can not be
fulfilled. Increasing the number of sectors using 8.33 kHz both in horizontal and vertical
direction will only provide relieve until 2008. If the request for voice channels does not diminish
alternative ways have to be sought to satisfy the demand. It was noted that it was unlikely that
VDL Mode 3 would provide more voice channels and whether it could be implemented in a band
already congested with 8.33 kHz assignments. Another alternative might be to look at a system
operating outside the VHF communications band.
8.2 WP 18 provided an overview of the use of the 118-137 MHz band in the USA. The
objective of the paper was to inform the group that some countries manage this band differently
than others. It was noted that within the US, 123.45 MHz was assigned to support flight test
communications, but no impact on use of this frequency for air-to-air communications in oceanic
and remote areas was expected. WG-C was informed that the increasing congestion in the 118-
137 MHz portion of the VHF band in the US would be resolved for the foreseeable future with
the implementation of VDL Mode 3. It was also noted that VDL Mode 2 was designed and is
being implemented to satisfy the requirements for AOC data communication whereas VDL
Mode 3 was designed and is being implemented to satisfy the requirements of ATC voice and
data communications service.
8.3 WG-C discussed alternatives, which were contemplated to expand the VHF
communication capacity. The two most likely alternatives are; the extension of the VHF
communications band into the VHF Navigation band, and the transfer of a part of the ATC
communication functions into another aeronautical band to relieve the VHF congestion.
Whether these alternatives can be pursued is dependent on the availability of spectrum in other
aeronautical bands. As the necessary expertise to answer this question would reside in AMCP
WG-F, it was agreed to address this issue to WG-F.
8.4 WG-C having to establish the future VHF communication need beyond 2010 based on
the ATM concept which is to be developed, questioned whether the surge in voice channel
requirements would taper off with the introduction of the new global ATM system. The present
implementation plans are highly dependent on this question. It was agreed that it would be
directed to ATMCP.
8.5 WP 27 introduced some general example requirements for the future aeronautical
communications system for the purpose of exploring band options. WG-C considered these
requirements more of a system nature than a direct regulatory spectrum nature and should be
taken into account in the communication requirements which are to be developed for the year
2010 and beyond.
ACTION WGC/1-5: WG-C to draft a communiqué to WG-F with the request to assess the
possibility of alternative AM (R)S allocations.
ACTION WGC/1-6: WG-C to draft a communiqué to ATMCP to identify the problem of a
shortage of voice channels.
Agenda Item 9: Future VHF frequency selection/usage
9.1 No papers were presented under this Agenda Item. WC-C looked at the assigned
activities by AMCP/7 and agreed that the system aspects of 8.33 kHz and VDL Mode 3 channel
labelling would be a matter of WG-M. Noting that the present VHF system has around 6,080
channels it would be more appropriate for WG-C to look at how the controller and the pilot
could be relieved from the high workload resulting from frequency channel management.
9.2 It was agreed to include this element in the requirements for the VHF need beyond 2010.
The requirements will be developed on the principle of a common simple human interface for all
ACTION WGC/1-7: WG-C to assess the potential of reducing the involvement of pilot and
controller with frequency channel management.
Agenda Item 10: Multi use of vocoders
10.1 WP 24 covered the issue associated with the introduction of end-to-end digital voice
communications. It is proposed that AMCP should investigate the issue further to determine if
development of additional ICAO material is required. Several members indicated they are
presently working on this problem and it was agreed that WG-C would undertake the following
recommendations per WP 24:
a ) introduction of general guidance material cautioning against the potential impact of the use
of tandem vocoders and/or digital/analogue conversions and stressing the need of careful
transmission planning for the end-to-end connection;
b) definition of minimum end-to-end requirements (such as intelligibility and delay) to be
satisfied by all ATS voice connections; and
c) detailed study of specific cases of tandem vocoder connections including digital/analogue
conversions and development of specific guidance material for those cases.
ACTION WGC/1-8: WG-C to develop material to be included in ICAO standard/guidance
material to address the issue of air/ground vocoders in tandem with ground-to-ground vocoders.
Agenda Item 11: Communication scenario’s
11.1 WG-C made an inventory of the discussions and presentations under the previous agenda
items. WP 12, 13 and 14 were briefly introduced, as they were a compilation from previous
work being performed to make an inventory of system alternatives with the objective to reduce
11.2 WG-C discussed the various options on how to address its main task of addressing the
VHF communication need beyond 2010. It was agreed that guided by the material in WP 12, 13
and 14 and the presented working papers, a report would be developed entitled: “Communication
scenarios from present until and beyond 2010”.
11.3 The report should at least include:
a) An inventory of the problem(s).
b) An overview of the alternatives.
c) Considerations on spectrum utilisation.
d) Institutional aspects.
e) The increasing communication usage for navigation and surveillance services.
f) An inventory of perceived and stated communication requirements.
g) Considerations on shared/dedicated or general-purpose systems.
h) A proposed recommendation to ICAO how to proceed to achieve a common
global interoperable communication infrastructure.
ACTION WGC/1-9: WG-C to develop a report with the objective to recommend a scenario in
which a common global interoperable communication infrastructure could be ensured for the
Agenda Item 12:Workprogamme WG-C
12.1 Based on Attachment D, WG-C made an inventory of the remaining activities for which
a task has not been assigned.
12.2 WG-C addressed the concerns expressed in fulfilling the required capacity with the
current VHF systems beyond 2010 in some parts of Europe and North America, as reported in
agenda items 7, 8, and 11. Considering the lead-time required to introduce a new system. WG-
C felt it is necessary to start urgently research and development activities to identify a potential
system operating outside the VHF band.
12.3 For item (d), to consider the need for developing SARPs for UAT, no task has been
assigned yet. Although the meeting recognised that early work is required to ensure the timely
introduction of a new system for 2010, the inventory of the problem is not yet complete enough
to begin UAT SARPs development.
12.4 From an administrative perspective the interoperability issues between MTSAT and
Inmarsat have been resolved. Therefore, there is no need to address the activity under (f) untill
MTSAT is launched.
12.5 On the activity to monitor relevant industrial standardization activities (ref. j) WP 26 was
presented containing mainly the activities of the RTCA. It was agreed to generate an action to
collect information on RTCA, EUROCAE, ETSI and AEEC related activities for which a WG-C
lead person would be assigned. The preferable method of disseminating the information would
be through the ICAO web site. The ICAO secretariat was requested to see if and when ICAO
could provide this support.
12.6 It was agreed that a single person, preferably a small group would lead the individual task
to progress the work initially before the whole of WG-C would be involved.
12.7 A complete overview of tasks, lead and compliance date is in Attachment F of this
ACTION WGC/1-10: WG-C to identify the necessary preliminary tasks and start the most urgent
tasks to identify a mobile communication system operating outside the VHF band beyond 2010.
ACTION WGC/1-11: WG- C identified leads to provide updates on standardization activities
related to the work programme of WG-C.
ACTION WGC/1-12: The ICAO secretary to explore the possibility of making the WG-C
information available through the ICAO web site.
Agenda Item 13: Next Meetings
13.1 As the WG-C intends to increasingly use e-mail, it was decided to schedule future
meetings for only one week duration.
13.2 The next WG-C (WG-C/2) meeting is scheduled for 7 - 11 May 2001 at a location in
Europe (Noordwijk, Brussels, Malmo).
13.3 For WG-C/3 the tentative meeting dates are 5-9 November 2001 with a likely location in
Agenda Item 1: Introduction
Agenda Item 2: Results from AMCP/7/Inventory of working group C activities
Agenda Item 3: Operational Requirements
Agenda Item 4: Required Communication Performance
Agenda Item 5: VDL implementation
Agenda Item 6: Review of the Annex 10 radiotelephony procedures
Agenda Item 7: Future systems
Agenda Item 8: VHF need beyond 2010
Agenda Item 9: Future VHF frequency selection
Agenda Item 10: Multi use of vocoders
Agenda Item 11: Communication scenario’s
Agenda Item 12: Work progamme WG-C
Agenda Item 13: Next Meetings
AERONAUTICAL MOBILE COMMUNICATIONS PANEL
LIST OF WORKING PAPERS
Presented by Title
Paper No. Item
1 AGENDA -
2 LIST OF WORKING PAPERS -
3 AMCP/5 FUTURE OPERATIONAL AND SYSTEMS 2/7
4 AMCP/7 FUTURE WORK WG-C 2
5 AMCP/7 PROPOSED NEW WORK PROGRAMME 2
6 ICO NEW ICO AERONAUTICAL SERVICES 7
7 ATNP COMMENTS ON DRAFT RCP CONCEPT 4
8 OPLINK PANEL CONCEPT OF REQUIRED 4
9 K. Van den Boogaard WORKING GROUP C ACTIVITIES 2
10 B. Phillips REVIEW OF ANNEX 10 6
11 B. Phillips FUTURE SYSTEMS: UAT 7
12 AMCP/5 THE DEVELOPMENT OF DATA LINKS 11
FOR SURVEILLANCE APPLICATIONS
APPENDIX A & B
13 AMCP/5 DEVELOPMENT OF DATA LINKS FOR 11
14 AMCP/5 REPORT ON THE ASSESSMENT OF CNS 11
15 K. Van den Boogaard VHF NEEDS BEYOND 2010 8
16 P. Renaud NEED TO START WORK IN 7/8
CONSIDERING NEW COM SYSTEMS IN
NON VHF BAND
17 P. Renaud PROGRESS ON WIRELESS GATELINK 7
18 Don Willis VHF NEED BEYOND 2010 & FUTURE 8
VHF FREQUENCY SELECTION/USAGE
19 Kris Hutchison THE USE OF BROADBAND 7
COMMUNICATIONS TO SUPPORT
20 Larry Johnsson VDL MODE 4 SUPPORTING COM 7
21 Claude Loisy FUTURE SYSTEMS: SATCOM 7
22 Arnaud Dedryvere AERONAUTICAL ADVANCED 7
REQUIREMENTS & KEY FEATURES
23 OPLINK CONCEPT OF REQUIRED 4
(RCP) - VERSION 1.4
24 AMCP/7 USE OF AIR-GROUND VOCODERS IN 10
TANDEM WITH GROUND-GROUND
25 Al H. Burgemeister STATUS OF UNITED STATES 2 GHZ 7
MOBILE SATELLITE PROCEEDINGS
26 Brent Philips STATUS OF RELATED ACTIVITIES IN 12
27 Chris Moody EXAMPLE REQUIREMENTS FOR 11
FUTURE COMM SYSTEM FOR THE
PURPOSE OF EXPLORING BAND
AMCP – ATTENDEE LIST
NAME COMPANY E-MAIL
Biggs, Michael G. FAA email@example.com
Blake, Bill FAA firstname.lastname@example.org
Burgemeister, Alvin H. B-12 Consulting email@example.com
Capretti, Alessandro ICAO firstname.lastname@example.org
Cochet, Daniel Alcatel Space Industries email@example.com
Crebassa, Philippe Service Technique de la firstname.lastname@example.org
Dedryvere, Arnaud Direction de la Navigation email@example.com
Esteban del Pozo, E. AENA/Spain firstname.lastname@example.org
Farncombe, D.A. National Air Traffic Services Ltd. email@example.com
Guettier, Michel Centre d‟Études de la Navigation firstname.lastname@example.org
Hamelink, Jane Adsytech/FAA email@example.com
Herishen, Stacey Crown Consulting, Inc./FAA Stacey.firstname.lastname@example.org
Hutchison, Kris ARINC email@example.com
Ishide, Akira ENRI – Japan firstname.lastname@example.org
Johnsson, Larry Swedish Civil Aviation email@example.com
Loisy, Claude ESA firstname.lastname@example.org
Marin, Miguel IFALPA email@example.com
Matsushita, Seiji ENRI – Japan firstname.lastname@example.org
Moody, Chris MITRE/CASSO email@example.com
Nakamura, Takefumi OKI Electric Industry Co. Ltd. firstname.lastname@example.org
Nakamura, Toshio NEC Corporation email@example.com
Nascimento, Luiz Ricardo de Souza DEPV – Brazil firstname.lastname@example.org
Norrish, Lindsay Inmarsat email@example.com
Oliveira, Ricardo Senra DEPV – Brazil firstname.lastname@example.org
AMCP – ATTENDEE LIST
Phillips, Brent W. FAA email@example.com
Pickens, R. Andrew AvCom firstname.lastname@example.org
Renaud, Philippe Eurocontrol email@example.com
Sakata, Hideo Mitsubishi Electric Corp. firstname.lastname@example.org
Van den Boogaard, Kors IATA email@example.com
Willis, Don FAA firstname.lastname@example.org
Zemrowski, Kenneth M. TRW/FAA email@example.com
Activities for Working Group C (Ref AMCP/7) report
The following activities were identified for Working Group C:
a) explore the long-term system requirements for aeronautical VHF systems in the light of the ATM
concept, scenarios for all flight and operational requirements for implementation for beyond 2010 to
be developed by the ATMCP;
b) to explore the likely airspace user needs for aeronautical VHF systems beyond 2010;
c) to acquire current implementation plans for aeronautical VHF systems;
d) consider the need for developing SARPs for the UAT system;
e) consider in its work difficulties related to channel labeling;
f) monitor the progress of development of interoperability among AMSS networks complying with
g) review the Annex 10 radio telephony procedures;
h) analyze issues associated with the introduction of end-to-end air-ground digital voice
i) monitor the development of wireless communication systems on airports; and
j) monitor the development of relevant industrial standardization activities.
Communiqué from AMCP WG-C to OPLINKP WG-C
19 October 2000
In April 1996, AMCP/4 (Recommendation 2/2) recommended the development of the Required
Communication Performance (RCP) concept. The task was assigned by the Air Navigation
Commission to the ADSP (later renamed OPLINKP). Further to a request by the Secretary of the
OPLINKP, AMCP WG-C has reviewed the document entitled “Concept of Required
Communication Performance (RCP)” produced by OPLINKP WG-C. A preliminary draft of
version 1.4 of the document was used in the review. This communiqué contains the comments of
AMCP WG-C on the RCP document.
2. General comments
AMCP WGC would like to express its appreciation to OPLINKP WGC for their valuable
contribution to the development of an ICAO RCP concept, as contained in the RCP document
version 1.4, and in particular for the useful insights into the operational communication process
provided by the document.
However, it is the view of AMCP WGC that the RCP document, in its current stage of
development, does not meet in full the expectations associated with the original recommendation
that led to the development of the document. The main reasons for this view are presented in this
2.1 The proposed definition is not readily quantifiable or testable
The original requirement from AMCP/4 was for “objective criteria to evaluate the
communication performance requirements”, and called for the development of a means “to
assess the various technical options of communications systems against the RCP parameters”.
The definition of RCP provided in the RCP document does not appear to provide a practical tool
for objective evaluation of a technical communication system option. The main reason for this is
that the definition includes the human element (pilot, controller) as an integral component of the
communication system. While this is certainly a justifiable view in operational terms, the
practical consequence is that the quantitative values of RCP parameters contain a widely variable
and difficult to quantify component, namely the one attributable to the human element.
For instance, the “process time” parameter includes components such as “thinking time”, made
up of “cognitive processing” and “decision making” times. Such components are lumped
together in the definition with technical components, such as transfer delay over the
communication link. Thus, the required value of the “process time” parameter cannot readily be
used as a technical basis for the development or assessment of a communication system, because
it includes non-technical elements that cannot readily be quantified or tested.
This difficulty is obviously recognized in the RCP document. The documents makes an attempt
to clarify how the overall allowance for an RCP parameter is allotted to the technical and human
components of the overall system (see e.g. Sect. 3.1.18, 6.1.1 – 6.1.3), and how the technical
component is used to assess conformance with the RCP type. It is unclear whether the document
implies that a similar conformance assessment should be carried out for the human component as
well, but AMCP WG- C assumes that testing of individual pilots or controllers for conformance
to RCP would not be meaningful or feasible. On the other hand, the use of “mean values of
human performance”, as advocated in 5.1.4, would not be very meaningful either, given the wide
variability of human performance across different individuals and for the same individual in
different operational situations. Hence, the only testable element of the overall RCP would be the
technical component, while the value of the human component would have to be based on
AMCP WG-C recognises that the draft RCP paper has evolved into a document with multiple
audiences, with varying needs for RCP. If this document were to satisfy only the needs of a
technical communications panel, it would be best to remove the human components from the
definition of RCP parameters, leaving only the technical component, which is the only
quantifiable and testable component.
Presuming that this approach is not acceptable to OPLINKP, it is recommended that the process
of breaking down an RCP type into required technical performance and required human
performance be clarified (specific suggestions are provided in the comments to Section 6.1). We
also suggest that this discussion could be strengthened with a thorough description of ICP and
the relationships of ICP, ACP, and RCP. This would increase the value of the RCP document not
only to AMCP, but also to any other users of the RCP document.
WG-C notes that OPLINKP has not yet developed a naming convention for RCP values. In the
case of RNP, the RNP value associated with an operational requirement is easily associated with
a corresponding set of technical requirements. In the case of RCP, it appears to be very
challenging to develop a naming scheme that can easily address the technical and
procedural/human factors implementation of RCP.
2.2 The proposed definition is not generally applicable to all types of communication
Section 2.3 of the RCP document states that the document “does not yet provide a
comprehensive operational concept for all aspects of ATM communications". AMCP WG-C
recognises the complexity of the task associated with the definition of a generally applicable
RCP concept and understands the difficulty of providing a comprehensive operational concept.
This difficulty certainly justifies the strategy adopted by OPLINKP, whereby, as stated in
Section 2.3.1 the initial goal is to work out the issues associated with controller/pilot
communications (as opposed to all possible types of communications), while developing a
flexible framework which can be expanded to cover all communications. A consequence of this
strategy, however, is that the proposed definition fails to meet in full the requirements associated
with the original recommendation for the development of the RCP concept.
In order to clarify the scope and limitations of the definition, the following clarifications are
requested from OPLINKP:
- are all types of controller-pilot communications (both voice and data) addressed by the RCP
- what elements of the RCP concept as developed in the document are actually based on the
specific assumption of controller/pilot communications (and are therefore not generally valid)?
- conversely, what elements of the concept are of general validity?
- when does OPLINKP intend to complete the development of the concept to cover all
- when and where will the actual RCP types be developed and where will the task for partitioning
of the contributing subsystems reside?
2.3 Analogy with RNP concept is not fully applicable
The development of the RCP concept was originally undertaken on the basis of an assumed
analogy with the RNP concept, which had proved to offer great practical benefits to airspace
designers and users. As a result of its review of the RCP document, AMCP WG-C has come to
question that initial assumption. The central role of the human element in the general definition
of RCP (as recognized by OPLINKP) has only a partial analogy in the definition of RNP. The
fundamental difficulties encountered in the attempt to define measurable and testable parameters
for the human performance component of RCP would lead to the tentative conclusion that a
definition of RCP would not be as beneficial in practice as the established definition of RNP.
3. Detailed comments
Detailed inline comments are provided in the attachment.
19 October 2000
AMCP WGC COMMENTS ON DOCUMENT
“CONCEPT OF REQUIRED COMMUNICATION PERFORMANCE (RCP)”
DRAFT Version 1.4, dated Tuesday, October 3, 2000(output of OPLINKP Berlin meeting
before OPLINKP Secretary’s review)
(to be provided)
The International Civil Aviation Organization (ICAO) has recognized a need for major
improvements to the existing air navigation system. First addressed by the ICAO Special
Committee on Future Air Navigation Systems (FANS), this need was expressed in terms of
communications, navigation, surveillance and air traffic management (CNS/ATM) enhancement,
including introduction of data links
<<<The WG feels that the level of this section is too detailed for a general introduction and that
it appears superfluous (in fact, this section could be skipped without affecting the meaning of the
remainder of the document). More importantly, the text only applies to VHF voice, and appears
incorrect, as congestion/unavailability is not obvious to pilot, only to controller.>>>
The acceptance of data communication as a technology for ATM, in addition to voice
communication, means that a technology independent method of determining and specifying
communication performance is desired. This will allow flexibility in selecting either the voice or
data provided that it has been shown to meet the required communication performance. <<<It is
not clear in the following whether the RCP document addresses voice>>>.
At the fourth meeting of the Aeronautical Mobile Communications Panel (AMCP/4) (Montreal,
April 1996), the urgent need for objective criteria to evaluate the performance requirements for
communication systems was recognized. It was noted that the concept of required
communication performance (RCP) was already under consideration in ICAO.
Recommendation 2/2 was prepared which invited ICAO to arrange that an appropriate ICAO
body progress, with urgency, the development of the concept of RCP by 1999. <<<It is
recommended that Sect. 1.1.4, 1.1.5, 1.1.6 be moved to the foreword, because they are purely
When reviewing the report of AMCP/4, the Air Navigation Commission (ANC) approved
Recommendation 2/2 and requested the Automatic Dependent Surveillance Panel (ADSP) to
develop the operational concept of RCP in time for ADSP/5 in 1999. At the fourth meeting of
ADSP (ADSP/4) (Montreal, September 1996), the panel accepted a work programme to develop
the concept, but not the types, of RCP by the desired completion date. The ANC emphasized the
need for the ADSP to co-operate closely with other panels as appropriate and, in particular, with
AMCP with regard to the activities on the comparative analysis of the various communication
The development of the RCP concept by ADSP has been progressed in co-ordination with other
groups both within ICAO and outside of ICAO (e.g. RTCA, EUROCAE). AMCP had made the
following recommendations which have been taken into consideration by the ADSP in its
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 1 of 18
development of the RCP concept:
a) all groups (e.g. RGCSP, AMCP, ADSP, RTCA, EUROCAE, etc.) use the same
set of parameters;
b) all groups should have the same understanding of the meaning of the parameters;
c) all parameter values used for a particular airspace or function are consistent,
justified, and the least stringent to meet the operational need. <<Chris here>>>
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 2 of 18
Air Traffic Management is comprised of Air Traffic Services and other services. Air Traffic
Services consists of Air Traffic Control Service, Flight Information Service and Alerting Service
(Annex 11). Each of these Services can be broken down into specific functions. In this
document, the term ATM function will be used to denote these components of Services.
Communications, navigation, and surveillance support these functions. Figure 1-1 <<< For
clarity, the stack of non-ATS Services (Service, A, B etc) in the figure should be raised to the
level of the ATM text box (or labelled as ATM Service A, B etc>>>Illustrates the notional
relationship between Air Traffic Management and Communications, Navigation and
Air Traffic Management
Air Traffic Services
AIR TRAFFIC FLIGHT ALERTING SERVICE C
CONTROL INFORMATION SERVICE SERVICE B
Area Control Traffic S/R S/R SERVICE A
Service information … … …
Approach Control ATIS …
Aerodrome Control information
Comm Communication capability and performance will depend
upon environment and level of service
Navigation capability and performance will depend
Nav upon environment and level of service
Surveillance capability and performance will depend
upon environment and level of service
Surveillance. RCP will be used to specify communications performance where necessary to
support functions within a designated environment, taking into account, for example, traffic
density, separation minima, message volume, etc.<<<Chris to work on this>>>
The elements of the CNS/ATM system are interrelated. Figure 1-2 illustrates this
interrelationship. There are areas wherein communications may be needed to support the
navigation or surveillance element or both at the same time. It can also be pointed out that, in
some cases, such as an automatic dependent surveillance (ADS) application, the navigation
element also provides information to the surveillance element. To try to develop an RCP concept
which would encompass all of these possible interactions was determined, from an initial
perspective, to be too complex a task. <<<The difficulties in the development of an RCP concept
Figure 0-1 Notional Relationship between ATM and C, N, and S
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 3 of 18
do not appear to derive from functional mix, so why is this stressed here? >>><<<should it be
noted here that controller/pilot communications will be the focus of the document?>>><<Is
overlapping Venn diagram appropriate?>>>
Air Traffic Management
Figure 1-2 CNS Functional Interrelationship
The elements of the CNS/ATM system are used in combination to provide functions supporting
ATM. There are functions that use communications, navigation, and surveillance elements. For
example, as illustrated in Figure 1-3, a separation assurance function is supported by a controller
using the surveillance element to detect discrepancies in a flight path. The controller uses
communication, to initiate corrective action, e.g., to issue a re-clearance. The navigation
element, in effect, contributes to keeping the aircraft on the intended flight path.
<<<perhaps the second diagram should be deleted, it does not add much to the information in
the document. Does the picture cover free flight – diagram may not be generic enough>>>
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 4 of 18
Air Traffic Management
Figure 1-3 CNS Functional Relationships
Purpose AND scope of this document
The purpose of this document is to provide guidance material to explain the operational concept
of required communication performance (RCP), identify how RCP affects the airspace managers
and the airspace users, and provide regional planning groups with a basis for the development of
documents, procedures, and programmes to introduce the use of RCP in airspace planning
methodology.<<<Clarify scope: Voice, data, both? Point-to-point, broadcast, both?>>>
The development of RCP will ultimately enable airspace managers, certifying authorities, and
aircraft operators to formalize performance aspects of the communication element of the
CNS/ATM system. This formalization must take into account State and regional circumstances
as well as global interoperability requirements for civil aviation operations. <<<If we have a
limitation, as stated in 2.3 below, the document should clearly explain what is missing in order to
develop a complete RCP concept, what assumptions apply to only controller/pilot
communications , which ones are general etc,>>>
Note: The RCP concept works in concert with the interoperability requirements
associated with specific communication equipment. The RCP concept provides
performance requirements for operational communication, independent of
technologies used. Therefore, interoperability is assumed in the RCP
concept.<<< interoperability Is a necessary con1dition for communication, therefore it is
an underlying assumption to the RCP concept>>>
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 5 of 18
It should be noted that this document does not yet provide a comprehensive operational concept
for all aspects of ATM communications. It does, however, provide a foundation upon which the
operational concept described herein may be extended.
Communications can be used to exchange information between: controller and pilot, controller
and controller, human and machine, machine to machine, etc. <<<pilot-pilot should be included,
some things are air-to-air (note that machine-machine could be a-g,g-g,a-a) Should have place
holders for areas (e.g. air-air applications) not yet defined>>>See Figure 2-1
Figure 2-1 Examples ofCommunication Exchange
Some of these information exchanges are in direct support of the operational communication
element of the CNS/ATM system; others are characteristic of technical communication, which is
associated with any of the elements of the CNS/ATM system, including navigation and
surveillance. The RCP concept must ultimately cover all of these types of communications.
Because of the complexity of the issues involved in creating a concept which can be applied to
all of the possible types of communications, using the following two strategies:
develop a flexible framework which can be expanded to cover all of communications
work out the issues associated with controller-pilot communications as an initial
It is beyond the scope of this document to specify RCP type(s), allocations for an RCP type, or
the qualification process.
OPERATIONAL CONCEPT OF RCP
(this section is a duplication of the following one)Within defined airspaces and for specified
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 6 of 18
operations, RCP is a statement of the performance requirements for operational communication
in support of specific ATM functions, operations, or procedures. RCP is specified in terms of
communications process time, integrity, availability, and continuity of function.
An RCP type is used to designate a specific RCP according to the following naming convention:
<<< results of naming convention WP goes here>>
For communications to support operational enhancements to the air navigation system through
the implementation of the CNS/ATM system, a framework is needed to:
a) Determine and specify minimum operational performance requirements for
communications that support air traffic management (ATM) functions.
b) Qualify elements of a CNS/ATM system in support of State responsibilities to
approve the provision and use of ATM functions.
c) Monitor and assess the impact of changes on system performance as new operational
functions are added, improved, or revised.
An operational characterisation of communication performance needs to be determined and
specified for an ATM function in such a way as to enable the qualification and monitoring of
different communication technologies in different airspace or along the route of flight.
A specified RCP type is intended to define the communication performance required of a
communication process to support a particular ATM function. An RCP type is comprises values
assigned to the parameters (i.e. communication process time, integrity, availability, and
continuity of function) which are the minimum number of values consistent with the proper
characterization of the operational requirements. <<<Naming convention WP intro text here,
appropriate modifications to these words will be made>>>
<<<Ed <note<< fix this from Naming convention WP into the note we want to make: What is
the notation for an RCP type where the communication process time is the same, but one or more
of the other parameters are different. Perhaps we should consider an alternative labelling that is
not associated with any of the parameters, such as RCP types A, B, C, D, and E. Otherwise, we
should provide additional material to denote the differences between, for instance, and RCP type
300 with integrity 10**-5 and an RCP type 300 with integrity 10**-3.)>>>>
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 7 of 18
RCP type Communication Integrity Availability Continuity of
Process Time Function
RCP m m seconds value 2/1 value 3/1 value 4/1
RCP n n seconds value 2/2 value 3/2 value 4/2
RCP o o seconds value 2/3 value 3/3 value 4/3
RCP p p seconds value 2/4 value 3/4 value 4/4
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 8 of 18
Overview of the RCP Concept
1 The RCP concept will provide a basis for increased flexibility of application of
communication technologies. It will permit an evaluation of their suitability to deliver
required communication performance in support of ATM. It should be possible to
establish a global RCP type for certain selected functions functions..<<<RCP types
should be function based andairspace based>>>
2 RCP types are prescribed by states based on the criticality of the function provided.
For example, the performance required of the communication process used to support
particular separation minima. The State or group of States will specify that RCP type
to apply that separation minima.
3 The RCP type is applied to the airspace, route, or procedure based on the most
stringent RCP type of the required ATM functions. It may not be necessary to
objectively assess the RCP type for all required ATM functions. A qualitative
assessment of ATM functions, taking into account ATM system architecture, may
conclude which ATM functions need to be assigned an RCP type.<<<Determining
which is the “most stringent” may not always be possible (RCP is a multidimensional
concept, and an RCP type con be more stringent with regard to one parameter but less
stringent with regard to another). In a given airspace all the operators may not
require the same services, and thus may not need to meet the same RCP.>>>
4 For RCP to have value, ATS providers must be able to verify that the message, not just
the data, was received in a form comprehensible to the receiver. The level of
performance to be achieved must be stated clearly and unambiguously and be specified
in a technology-independent manner so that it covers all existing and emerging
systems.<<<There is no practical way to quantifiably measure whether the data is
5 Different functions could have different RCP types and the same function in
operational environments with different characteristics could have different RCP
types. It would be expected that a limited set of RCP types would capture all
communication requirements across all operational environments. That is, an RCP
type developed for a specific function in a specific environment would be uniformly
applicable. <<<Have operational environments been defined – or mapped to what is in
the ADSP Manual?>>>
6 A communication system process that qualifies for a specified RCP type would not
necessarily mean that the same communication process automatically qualifies for an
apparently less rigorous RCP type (e.g. a particular implementation of a
communication process may meet transfer time requirements but might not meet
integrity or availability requirements). <<<Unless parameters are ranked by relative
importance, it is in general not possible to tell if an RCP type is more or less rigorous
than another (see comment to 220.127.116.11 above)
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 9 of 18
7 The contribution of the human element can be significant to RCP. Communication is
more than the transmission of a set of words, characters, tones, or electronic data
bytes; it is the accurate transfer of information between sender and receiver, the
content of which can be readily understood by both. This transfer of information must
meet the RCP type for the designated airspace, route, or procedure.<<<How can this
be measured?; see above similar comment.>>>
8 In order to complete the transfer of information, communications may not always
consist of a round-trip dialogue. However, the RCP concept demands a unique
beginning and ending point. Thus:
a) when RCP relates to one-way communications the beginning is when the
sender initiates the communication and the end is when the receiver is
capable of using the information; or
Figure 3-1 One-Way Communication
b) when RCP relates to two-way communications, it begins when the sender initiates
the communication, then the receiver, receives, processes, and replies to the
information, and ends when the sender receives the reply.
Note: For both voice and data a “stand-by” message may be appropriate to end the
communication process. This may happen when the traffic situation requires a human
processing time incompatible with the specified RCP type. There may be a separate
Figure 3-2 Two-Way Communication
communication process which will begin with the appropriate response, e.g. WILCO or
9 Regardless of whether the end systems are humans or systems the communication that
takes place between them may or may not require a two way communication
depending on whether or not there is an operational requirement for positive
assurance that the communication process transferred the information. Without the
reply, the sender has no positive assurance that the recipient received the information.
Positive communication assurance is a performance measure of the communication
process and should be specified as part of the RCP type. If positive communication
assurance is not a requirement then the communication may be considered a one-way
communication. RCP seeks to quantify the operational communication process as
depicted in Figure 3-3. <<<Assurance is, like other RCP parameters, a continuous
variable, not a binary one. For instance, assurance can be achieved by technical
acknowledgement, by logical acknowledgement, by user acknowledgement (eg
9323c4ee-135c-416d-8eab-bff528b6c9ad.doc Page 10 of 18
ROGER/WILCO) and/or by surveillance (eg observation of a radar track change after
a vector clearance is given).>>>
<<<This diagram has been termed the „Lafferton Model‟ for its author.>>>
Thinking Cognitive Processing
Technical Inform. Transfer over
Communication Communication Links
OPERATIONAL COMMUNICATION PROCESS
Page 0 of 18
Figure 0-3 The Operational Communication Process
Technical F Inform. Transfer over
Communication Communication Links
Levels 4 through n
Thinking Decision Making
10 Figure 3-3 shows a framework with four levels of increasing detail of the overall
communication process. Each point between separate elements of the process at
whatever level is identified by a letter within a triangle. The operational
communication process considered by RCP is symbolically flanked by the letters A and
Z. Level 1 shows the first major breakdown of the process into three components; the
sending of information to the recipient, the processing of the information by the
recipient, and the return of an operational reply to the originator. At level 2 and 3
there are increasing levels of detail displayed. It is envisioned that further levels of
detailed decomposition will be prepared by other specialist bodies as necessary to
support an allocation of an RCP type.
11 The framework presented in Figure 3-3 has the flexibility to address either two-way or
one-way communications scenarios as appropriate to the function or procedure for
which an RCP type is being specified. Furthermore, various methods of
communication may have different decompositions at a given level. Some of the
elements at a given level may not apply and may have these components of the
12 Both the human and technical elements should be included within the RCP by:
a) determining an RCP type for the entire operational communication process;
b) allocate the RCP type by:
determining technical communication performance;
determining representative human-machine interaction time;
determining representative thinking times;
c) assessing the assigned RCP type to determine technical and human processing
parameter values for suitability of operation; and
d) developing operational procedures as necessary for those occasions when actual
communication performance does not meet the specified RCP type.
13 It is essential that States appropriately monitor conformance to the applicable RCP
type and take the necessary action should the actual level of performance not meet the
Basis of application of RCP
The RCP concept is intended for use by those responsible for the planning, determination,
specification, qualification, and monitoring of ATM functions or procedures that require
Once an RCP type has been specified for a given airspace, route, or procedure, any single
communication system or combination of systems meeting the RCP type can be considered
operationally acceptable.<<<is it true to say that if you meet RCP, that„s all you need? What
we may really need to say is that RCP is one criterion you must meet, but there may be others
(eg SARPs compliance, security etc).>>>
RCP specifies the operational performance of the communications means used to support a
function or procedure. Planning and implementation regional groups (PIRGs) may prescribe an
RCP type to be met by the aircraft system, the ATS end-system, and the remainder of the
communication system . Therefore, RCP will permit the determination of whether different
communications technologies satisfy those performance requirements.
The RCP type will be determined based on the operational criticality of the function or procedure
to which it is applied. This RCP type defines the performance required of the operational
Note. The term operational communications process may be either one-way or two-way as
appropriate to the particular function or procedure (as per Figures 3-1 and 3-2).
In an airspace where several services are provided by a common communication infrastructure,
the characteristics of the communication infrastructure must accommodate all applicable RCP
Note: The communication process time parameter includes times required by humans to initiate
and complete the communication process. All other parameters do not consider human
performance.<<<Note that other parameters assume that human component value is 1 (no
Number of parameters
The RCP concept includes the minimum number of parameter values consistent with the proper
characterization of the operational requirements.<<< AMCP WGA in September 1999
recommended for inclusion two new parameters - capacity channel throughput, operational range
of communication; some discussion indicated that these may be already dependent on 4 already
provided. Alternatively, a traffic model for area should be stipulated instead, in order to specify
the conditions for applicability of the concept.>>>
Note: Additional requirements (e.g. information security) beyond those parameters included in
the RCP type may need to be prescribed.
Operational Communication process time
The operational communication process time specifies the time for the completion of the
operational communication process. This parameter is an indication of time criticality.
“Maximum time”should this be a 95% with latency? Max cannot be measured.>>>
RCP integrity is the probability that errors in the communication process will be undetected.
This occurs when a message containing one or more errors is indicated as being correct.
Note: Integrity does not take into account when messages are correct but detected as being
in error. These errors would be accounted for in continuity of function. <<<When delay
exceeds the 95% value, this would become would become an availability/continuity issue
RCP availability is defined as the ability of the communication system to perform its required
function at the initiation of an operational communication process. <<<why is this parameter not
straightforwardly defined as a probability, like continuity? Role of scheduled time must be
accounted for. Mean time between failure, mean time to restore>>>
Note: The availability requirement for the operational communication process is determined
from an assessment of the effects of loss of that communication process. The duration of this
lack of availability, and how frequently the loss can be tolerated from both a safety and
efficiency perspective is quantified as a probability. <<<Availability is comprised of two
components, mean time between failures (how often the loss occurs) and mean time to repair
(how long the loss is). When converted to a single parameter (probability), an important part of
the information provided by the two components is lost.>>>Availability is defined as the
proportion of the time the system is available to the time the system is required to be available.
RCP availability includes all elements within the end systems, networks, intermediate systems
Continuity of function
RCP continuity of function is defined as the probability that an operational communication
process can be completed without unscheduled interruptions given that the communication
process was successfully initiated
Note: The continuity requirement for the communication process is determined from an
assessment of the effects of an unscheduled interruption of the communication process. How
frequently the effect of unscheduled interruptions can be tolerated from a safety and efficiency
perspective is quantified. The continuity requirement is a function of the tolerable unscheduled
<<<Continuity of Function as defined here is the probability that the communication system will
fail during the period of the communication process. This probability is a function of the failure
rate of the communication system and the duration of the particular communication process.
(i.e. The probability of failure will increase in proportion with the length of the communication
process.) Continuity of Function cannot therefore be defined unless the duration of the
communication process is also defined.>>>
RCP includes human factors that are limited only to the human performance required to
complete an operational communication process. There is inherent flexibility such that, when
there is a communication process that does not require a human in the loop, then an RCP not
including the human element can be defined.
Human performance should take into account the action to answer a message received by an
appropriate return message. Task management should always be left to the discretion of the
user, within the scope of defined task priorities.
It should be noted that the time required by the human to complete the communication process
requires the HMI to be designed to allow the user to be able to react within an appropriate
amount of time.
The human performance component of an RCP should be based on the mean values of human
performance, and should not assume best or worst case values.
Measuring representative times for human-machine interaction processes is state-of-the-art in
applied psychology. Such measurements have been performed already for several years in a
diversity of environments, including industrial applications. “Thinking time” however is still
outside the scope of such measurements. Thus, whereas “human machine interaction time” can
be measured, “thinking time” should be specified as a maximum permissible amount of time
taking into consideration the minimum time needed for a specific task.
Human-machine interface (HMI) considerations
The overall philosophy of the HMI is one of the main issues allowing consistent measurement of
RCP time values, taking into account human performance variability.
Two of the main issues in the conceptual design of an HMI that interfaces to data link are:
a) how to provide access to more than one means of communication (e.g. VHF
voice and data link) for a given user; and
b) how to reduce the workload related to human machine interaction. .
Note. The time necessary for message composition and recognition, which is determined by the
effectiveness of the HMI, is critical.
The introduction of data link has put more visual information on the HMI, due to human
limitations, this inflation of information needs particular efforts to structure what is displayed in
a manner which enhances understandability. A categorization and hierarchical organization of
the information can resolve this problem. To know what information is required for display, one
must know the needs of the users for each type of task.
Before any HMI conceptual design is developed that includes data link functionalities, there are
many levels of constraints that must all be taken into account:
a) technical constraints, for example constraints linked to the ATC system itself and
constraints that are linked specifically to the use of data link;
b) constraints linked to the task; the main task that should always be done first (for
example, to guarantee aircraft separation) and then sub-tasks more specific to the
use of data link, (for example, the management of asynchronous data link
c) constraints that are purely human factors such as perception or memorization (for
example, the increase in visual information as a result of introducing data link
may have an impact on human perceptive performance).
The information displayed on the HMI for data link will be of a different nature than voice. In
order to guarantee an acceptable level of consistency, the logic designed to perform the actions
must be as common as possible.
Human processing/reaction time
The specification of human reaction time is more important in situations where the user receives
information that was not foreseen. The concept of reaction time must be placed in the context of
the activity at a specific time. This point makes reaction time less relevant in a situation where
the user expects the information. Therefore, making an evaluation of the reaction time in a
realistic environment is crucial (i.e. real users, heavy traffic, etc.) and should take into account
A data link message, as compared to a voice radio message, gives less information. Implicit
information such as tone of voice, rapid delivery of messages and explicit information such as
qualifications to standard phraseology are lost. As a consequence, in order to get consistent time
values for the RCP, the messages should not always be displayed in a generic format but more in
a specific format that will minimize this loss of information. For example, the use of specific
colours in the display of a message, or particular text formats are means to add more information
than the raw message alone.
Human Performance Variability
Attention to the above principles should increase the consistency and contribute to a reduction of
the variability of the human response time contribution to the RCP.
RCP Type Determination
- Coordinated requirements developing
Best efforts should be made by those determination HMI to minimize the variability of the human
performance. -- Identify Functions
-- Identify Comm transactions
EXAMPLEs -- Determine most stringent transactions
Example Overall Process for the Application of RCP
- Analyze function time
- Determine RCP type
framework for the
Since the RCP concept is aApproval/Qualification expression of the operational performance
requirements for ATM communications in support of specific functions, operations, or
- Identify human/technical system elements
procedures within defined airspaces, the first step in the use of the RCP concept will be to
- Determine human capability/performance
- Determine including the specific functions
identify the operational environment, technical capability/performance (ICP) to be covered by the
- Prepare evidence of conformance to RCP type
- Flight test in operational environment
- Demonstrate achieved communication performance (ACP)
specified RCP type. Once the operational environment is identified, the specific RCP type to be
prescribed must be determined. It should be emphasized that RCP type, while characterized by a
number representing the time parameter (e.g., RCP 185 meaning 185 seconds), includes the
requisite availability, integrity, and continuity of function parameters as well (i.e., RCP 185
would also specify a level of availability, integrity and continuity in addition to the 185 seconds).
In order to determine an appropriate RCP type, a process of co-ordinated requirements
determination may be used. ATM communications, however, is implemented across varied
domains (e.g., ATS service provider, aircraft operator, perhaps communications service
provider) and has many more directly affected parties (i.e., avionics manufacturers, aircraft
integrators, ATM ground automation suppliers, etc). A process of co-ordinated requirements
determination can allow an aircraft operator to reasonably acquire data to illustrate initial
conformance with the requisite RCP for a specific function. This process must involve the co-
operation of all of the affected parties. One method to acquire this data is by separating the
overall RCP requirement into first human and technical components and then further dividing
those components into finer subdivisions. The term Installed Communication Performance (ICP)
is used to describe the way in which the technical elements (i.e., non-human system elements)
may be scrutinized to develop data in support of RCP qualification.<<<ACP is introduced, but
not previously defined. Also ICP needs a definition. In addition to clear definitions of ICP/ACP,
additional terminology will need to be introduced to clarify that RCP needs to be split into RTP
(required technical performance) and RHP (required human performance). The recommended
Figure 0-1 Overall Process for Application of RCP
solution would be to limit the definition of RCP to the technical element (RTP) , as it is the only
testable and quantifiable one. Furthermore, split of overall RCP (or RTP, RHP) into component
elements should be done taking into account the applicable theoretical assumptions. For instance,
theoretically, 95% delays cannot simply be added; instead, convolution of time delay probability
distributions needs to be done, based on assumptions on the applicable distribution laws and on
lack of correlation between the different elements. In turn, all assumptions need to be confirmed
as applicable to the communication process under consideration. As a result, the fewer
components are encompassed by the RCP, the simpler and the more reliable the associated
analysis. As stated in the general comments, one possible solution recommended by AMCP
WGC would be that the RCP definition should not include the human component, ie should be
limited to the RTP/ICP component, as the only testable one in practice>>
Example method of identifying communication system elements
By following a process, such as co-ordinated requirements determination, it will be possible to
identify methods for the performance of the various elements of the system to be determined in
order for the overall compliance with the RCP type to be validated. A first step in this process
could be to separate the human and technical performance elements. The technical performance
would then be further subdivided among aircraft, network and ATS provider components as
shown in Figure 6-2.
OPERATIONAL COMMUNICATION PROCESS
Figure 0-2 Communication Process Performance Elements
<<< Figure 6-2: The word “Required” needs to be added to “Technical performance” and
“human performance” boxes. Also, inside the Required Human Performance box,
recovery/maintenance actions to handle outages may need to included>>>
Monitoring Achieved Communication Performance
It will be necessary to monitor the communication performance to determine adherence to the
appropriate RCP type. The monitoring process is called Achieved Communication Performance
RCP Framework ACP
Beginning of Beginning of
ACP Measured Human
RCP Transaction Performance
Figure 0-3 Relationship Between RCP and ACP
In order to verify that all elements of the communication system combined perform to a level
which meets an RCP type, it will be necessary to monitor that performance in operation. An
appropriate means would have to be used to demonstrate, along with the other components of the
communication process, the necessary performance.
Example of an Operational Data Communication Service
A typical operational data communication transaction is a request by the flight crew for
clearance, followed by the delivery of clearance. The flight crew needs to know if the request
for clearance was received, or if they should use alternate communications procedures to deliver
the request. The controller needs to know if the clearance was received, and what actions the
flight crew has taken subsequent to the receipt of the clearance. This operational data transaction
should be thought of as two separate transactions. (See Figure 6-4.)<<<AMCP WGC is not
confortable with the lack of consideration of LACKs in this scenario>>>
The majority of pilot-controller data link communications is interactive. The timely delivery of a
message is closely monitored to determine the applicability of recovery procedures before safety
margins are compromised.
The first transaction is the delivery of the request for clearance, the receipt by the controller, the
formulation of the clearance, followed by the transmission and delivery of the clearance.
The second transaction is the receipt of the clearance on the flight deck, the formulation of the
response by the flight crew, followed by transmission and delivery of the flight crew response
and the receipt by the controller.
Each of these two transactions would have to be evaluated (along with all of the other possible
transactions) to determine the most stringent transaction. Once that transaction has been
identified, the performance characteristics needed to successfully conclude that transaction will
become the basis for the RCP type assigned. In general, other existing RCP types should be
evaluated in an effort to reduce unnecessary proliferation of RCP types. However, the
operational performance requirements will take precedence in this evaluation.
The flight crew initiates the first transaction, and the flight crew must become aware when to
abandon the transaction and utilize alternate procedures. If this transaction is deemed critical
enough that an RCP type needs to be assigned and that the resultant performance needs to be
monitored, then a process similar to that outlined in section 6.1 would have to be undertaken.
Transaction 1 begins when the flight crew initiates a data link message requesting a clearance
and ends when the message containing the clearance response is received.
Typically, a timer will start when the request is initiated, and the timer stops when the clearance
is received. This would represent the monitoring of the transaction time performance of
Transaction 1. Should the timer expire, the flight crew may be alerted. This may be the result of
slow or failed message delivery, or even slow controller response to the request. When an alert
occurs, a flight crew procedure should be defined which is specific to the operation.
Transaction 2 begins when the data link message containing the clearance is received and ends
when the response to the clearance is received. There is overlap between these processes but it
should be clear that these are two different transactions. In general, this transaction will be
deemed critical enough for an RCP type to be determined and a process similar to that outlined
in section 6.1 will be followed to determine the appropriate RCP type.
Typically, a timer will start when the clearance is initiated, and the timer stops when the response
to the clearance is received. This would represent the monitoring of the transaction time
performance. Should the timer expire, the controller may be alerted. This may be the result of
slow or failed message delivery, or even slow flight crew response to the clearance. When an
alert occurs, a controller procedure should be defined which is specific to the operation.
Figure 0-4 Example Operational Service: Clearance Request/Response
For transaction 1, if the timer expires, the flight crew will re-initiate the clearance request using
other procedures. For transaction 2, if the timer expires, the controller will initiate alternate
procedures to contact the flight crew and then take appropriate action regarding the clearance.
It should be noted that if the flight crew receives a clearance in a timely manner, it is considered
valid and they can accept it and comply with it immediately. If the controller fails to receive the
response to the clearance, the controller cannot necessarily assume that either the clearance was
not delivered or that the response was not delivered; it is indeterminate.
Another Example of the application of RCP
Specification of RCP for the provision of a collision avoidance function.
14 Communication requirements are only one of many considerations in developing a
separation minimum. The ATM communication capability has heretofore been
expressed as an intervention capability, i.e. the ability to intervene to prevent a loss of
separation. An increase in traffic in particular airspace can result in airspace planners
considering a change in airspace utilization (e.g. separation minima, route
configuration) while maintaining an acceptable level of risk. In collision risk analysis,
this acceptable level of risk is most frequently referred to as the target level of safety
15 Once the separation minimum and the TLS are determined, a minimum level of
performance can be set for the air navigation system parameters of navigation,
surveillance, and communication. In the case of a remote oceanic environment for 50
nautical mile lateral separation, the airspace requirements may be stated as:
b) Surveillance comprised of position reports every y minutes, i.e. via voice, CPDLC
or ADS; and <<<how can ADS have a role here – since the scope of the
document is restricted to controller/pilot communications? (see 2.3.1 above)RCP
x for communication system performance.
16 RCP x for that airspace (i.e. remote, oceanic/50 lateral separation) indicates that the
minimum combined performance of all the elements will not exceed x seconds. This
figure was determined in order to meet the most stringent situation, e.g. controller
intervention and pilot action to avoid collision. Routine messages using that technology
will also arrive in the specified communication process time.
Action Item List WG-C dated 19 October 2000-10-17
Refnr Task Description Status Completion date Lead
WGC/1-1 The ICAO AMCP secretariat to bring 31/10/00 Secretary
Attachment E to the attention of the ICAO
OPLINK Panel secretariat.
WGC/1-2 ACTION WGC/1-2: WG-C to request AMCP 31/10/00 Rapporteur
Panel members to provide updates on VDL
WGC/1-3 WG-C to revisit the Annex 10 radiotelephony WG-C2 L.Norrish/P.Renaud/
WGC/1-4 WG-C to draft a communiqué to WG-M First draft to WG-C 31/10/00 L.Johnsson/B.
requesting that validation will be initiated for Submission to WG-M 30/11/00 Phillips
VDL Mode 4 as a communication system,
including the ATN complaint CPDLC
application and the broadcast communication
WGC/1-5 WG-C to draft a communiqué to WG-F with First Draft circulated 31 Oct 2000 30/11/00 P.Renaud/D. Willis
the request to asses the possibility of
alternative AM (R)S allocations
WGC/1-6 WG-C to draft a communiqué to ATMCP to First Draft circulated 31 Oct 2000 30/11/00 P.Renaud/M.Marin/
identify the problem of a shortage of voice
WGC/1-7 WG-C to assess the potential of reducing the 31/12/01 M.Marin/
involvement of pilot and controller with
frequency channel management
WGC/1-8 To develop material to be included in ICAO First step:making an inventory of WGC-2 UK/Japan/USA
standard/guidance material to address the issue the issues.
of air-ground vocoders in tandem with ground
to ground vocoders
WGC/1-9 To develop a report with the objective to First step: provide an outline by AMCP/8 Secretary/Rapporteur
recommend a scenario in which a common mid November
Refnr Task Description Status Completion date Lead
global interoperable communication
infrastructure could be ensured for the future.
WGC/1-10 WG C to identify the necessary preliminary WGC-2 P.Renaud/Rapporteur
tasks and start the most urgent tasks to identify
a mobile communication system operating
outside the VHF band beyond 2010.
WGC/1-11 WG C identified lead to provide updates on Continuous P.Renaud/FAA/L.Joh
standardisation activities related to the work nsson/Rapporteur
programme of WG-C.
WGC/1-12 The ICAO secretary to explore the possibility 31/11/00 Secretary
to make the WG-C information available
through the ICAO web site