Provision of ATN / VDL Mode 2 services for Riga
Flight Information Region in order to fulfil
Commission Regulation (EC) No 29/2009 on data link
services for Single European Sky (identification Nr.
LGS 2013/61)
Annex 4
Technical specification
Issue 1.1
Commercial In Confidence - Borealis Alliance
Issue 1.1
Notices
Any copies printed from the online version are to be treated as uncontrolled.
Publication history
Issue
Month/Year
Change Requests in this issue
Issue 0.1
February 2013
First issue for review
Issue 0.2
March 2013
Updating of appendices
Issue 1.0
March 2013
Update of references
Issue 1.1
September 2013
Updated by LGS
Reviewers/Distribution
Reviewers
Name of individual
Role
Referenced documents
List of documents referenced in this publication:
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
EU Commission Implementing Rule:
http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:013:0003:0019:EN:PDF
LINK 2000+ Generic Requirements for a CSP Version 1.6
Link 2000+ Network Planning Document V 3.4 EUROCONTROL May 2007
EUROCONTROL SPECIFICATION on Datalink Services EUROCONTROL-SPEC-0116 V 2.1
EUROCONTROL January 2009
Supplement 5 to ARINC Specification 631: VHF Digital Link (VDL) Mode 2 Implementation:
Provisions. ARINC 631-5 ARINC Inc. December 2008
ICAO document 9880, Manual on Detailed Technical Specifications for the Aeronautical
Telecommunication Network (ATN) using ISO/OSI Standards and Protocols
ICAO, Aeronautical Telecommunication Network (ATN) Manual for the ATN using
IPS Standards and Protocols (Doc 9896)
Guidelines for CNS/ATM Systems Software Integrity Assurance - EUROCAE ED-109
[9]
Safety and Performance Requirements Standard For Initial Air Traffic Data Link Services In
Continental Airspace - EUROCAE ED-120
[10] Interoperability Requirements Standard for Aeronautical Telecommunication Network
Baseline 1 (Interop ATN B1) - EUROCAE ED-110B
[11] Future Air Navigation System 1/A – Aeronautical Telecommunication Network
Interoperability Standard (FANS 1/A – ATN B1 Interop Standard) - EUROCAE ED-154
[12] Interoperability Requirements for ATS Applications using ARINC 622 Data
Communications - EUROCAE ED-100A
[13] Functional specifications for CNS/ATM Recording - EUROCAE ED-111
[14] Interpretation of EUROCAE ED-120/RTCA DO-290 Performance Requirements. V1.3
EUROCONTROL May 2007
[15] ETSI Standards EN 301 841-1 (V1.2.1) and EN 301 841-2 (V1.1.1)
(applicable to the Physical/MAC layers and higher layers respectively of ground based VDL
Mode 2 equipment)
P a g e | ii
Commercial In Confidence - Borealis Alliance
Issue 1.1
P a g e | iii
Commercial In Confidence - Borealis Alliance
Issue 1.1
Contents
PAGE
ii
Notices
1.
2.
3.
4.
5.
6.
Publication history
ii
Reviewers/Distribution
ii
Referenced documents
ii
Contents
iv
Introduction
6
1.1
Scope
6
1.2
Conventions
6
Managed Datalink Services
7
2.1
Preamble
7
2.2
Service Provision
7
2.3
Service Volume
7
Functional Requirements
9
3.1
General
9
3.2
Service Boundaries
9
3.3
Reference Point ‘A’ Connection to ANSP
10
3.4
Reference Point ‘B’ Service Provision to Participating Aircraft
11
3.5
Reference Point ‘C’ CSP Inter-Connection
13
Service Level Requirements
14
4.1
Capacity
14
4.2
Performance
14
4.3
Availability, Reliability and Continuity of Service
15
4.4
Integrity
15
4.5
Priority
16
4.6
Safety and Security
16
4.7
Maintenance
16
Performance Monitoring and Network Management
17
5.1
Technical Support
17
5.2
Problem Reporting
17
5.3
Performance Reporting
18
5.4
Planned Engineering Work
18
Communication Service Evaluation
19
6.1
Evaluation Process
19
6.2
Delivery of Documentary Evidence
19
6.3
Laboratory Acceptance Tests
19
6.4
Flight Tests
20
6.5
Observation Process
21
A.1
Overall Report on Quality of Service
22
A.2
Statistics
22
P a g e | iv
Commercial In Confidence - Borealis Alliance
Issue 1.1
B.1
Introduction
23
B.2
Functional Requirements
23
B.3
Capacity
23
B.4
Performance
23
B.5
Priority
23
B.6
Safety and Security Policy
24
B.7
Availability, Reliability and Continuity
24
B.8
VDL Coverage
24
D.1
ATN Ground/Ground Routing Services
27
D.2
Integration in the IP Wide Area Network infrastructure
28
D.3
Availability, Reliability & Maintainability Requirements
28
D.4
Capacity & ATN Router Processing Performance
29
D.5
Software assurance level
29
E.1
Scope
Error! Bookmark not defined.
E.2
Requirements
Error! Bookmark not defined.
E.3
LGS application of Eurocontrol Specification
Error! Bookmark not defined.
E.4
Data Link Services General Requirements
Error! Bookmark not defined.
E.5
Specification of Data link Service ACM
Error! Bookmark not defined.
E.6
Specification of Data Link Service ACL
Error! Bookmark not defined.
E.7
Specification of Data link Service AMC
Error! Bookmark not defined.
E.8
Specification of Data link Service DLIC
Error! Bookmark not defined.
E.9
End-To-End Communications General Requirements
Error! Bookmark not defined.
E.10
Specification of Data link Application CPDLC
Error! Bookmark not defined.
E.11
Specification of Data Link Application CM
Error! Bookmark not defined.
E.12
ATN Upper Layer Communications Service Requirements
Error! Bookmark not defined.
E.13
ATN Internet Communications Service requirements
Error! Bookmark not defined.
E.14
Ground Recording Requirements
Error! Bookmark not defined.
E.15
Naming and Addressing Requirements
Error! Bookmark not defined.
E.16
Conformity Assessment Requirements
Error! Bookmark not defined.
P a g e |v
Commercial In Confidence - Borealis Alliance
Issue 1.1
1. Introduction
1.1
Scope
1.1.1
The Link 2000+ Programme has established a number of principles governing the
provision of ATN/VDL2 service to ANSPs and participating aircraft. These principles are
intended to preserve the necessary freedom for participating aircraft to contract with
their preferred CSP for Airline Operational Communications (AOC).
1.1.2
The specification for the provision of VDL Mode 2 Service supporting ATC data link
services, in the context of the Eurocontrol Link2000+ Programme, are contained in
Generic Requirements for a LINK 2000+ Air/Ground Communications Service Provider
(CSP) [2]. This document provides the requirements specification for the provision of
ATN CPDLC services to airlines and aircraft that use the data link ATC services in the
airspace managed by LGS.
1.1.3
The requirements captured in this document represent particular needs, modes of
operation and business benefits to the LGS which, in some instances, may exceed the
minimum requirements stipulated in the Implementing Rule [1].
1.1.4
Specifically this document calls for the provision of either a managed service or
a partnership arrangement with the CSPs, instead of the ANSPs taking
ownership of radio equipment.
1.1.5
The document aims to specify the requirements to be satisfied by each CSP, and makes
reference to the following LGS Specific Requirements:
1.2

Service Volume – throughout which the CSP is required to provide the service. In addition, it also
specifies the minimum number of flights within that volume that the CSP is required to support.

Capacity – stating the minimum number of uplink and downlink ATC application messages per hour that
the CSP is required to support.
Conventions
Shall
Indicates that the requirement is mandatory; e.g. the paper shall be A4 size
Will
Indicates an intention or assumption for something out of scope of the project; e.g. the
system will provide the HMI for data entry to the system.
Should
Indicates a desirable requirement that cannot be justifiably mandated; e.g. the system
emergency ‘off’ button should be coloured red.
May
Indicates that may be at the choice of the supplier; e.g. the colour of the paper may be
either white or cream.
P a g e |6
Commercial In Confidence - Borealis Alliance
Issue 1.1
2. Managed Datalink Services
2.1
Preamble
2.1.1
The Link 2000+ Programme has established a number of principles governing the
provision of ATN/VDL2 and FANS/ACARS services to ANSPs and participating aircraft. A
full explanation of the principles and their impact can be found in the Link 2000+
Network Planning Document [3].
There are technical obstacles preventing an aircraft to use one VDL2 service provider for its AOC
communications and another for its ATC Communications.
2.1.2
In accordance with these principles LGS will contract both CSPs to provide ATN/VDL2
managed services to participating aircraft in the airspace under the jurisdiction of the
LGS who will connect directly to the CSPs. Any participating aircraft may choose to use
the ATN/VDL2 services available from either CSP to provide ATC Datalink Services
offered by the LGS.
2.1.3
This document identifies the ATN/VDL2 service requirements that each CSP must comply
with, in order to offer connectivity to provide ATC Datalink Services to participating
aircraft.
2.2
Service Provision
2.2.1
The CSPs shall offer connectivity to provide ATC Datalink Services for the Specified
Airspace only when written authorisation has been issued by the LGS who may further
specify the participating aircraft to which the connectivity will be offered.
LGS
understands the impact of requiring that an aircraft be blocked from the service, and will
only request it in extreme circumstances in consultation with the CSP. This requirement
is not intended to impact on the CSP’s AOC traffic.
2.2.2
Such authorisation will not be given until the CSP has demonstrated compliance with this
specification by successful completion of the Validation Procedures specified in Section 6
of this document as well as compliance with any additional requirements specified by the
LGS.
2.2.3
The CSPs shall provide a written undertaking to LGS to maintain compliance with the
requirements of this document during contracted period of service and such an
undertaking will form part of the contract with the LGS.
2.2.4
The CSPs shall offer connectivity to provide ATC Datalink Services to any participating
aircraft, including non-AOC aircraft, operating under the jurisdiction of the LGS, in
accordance with the Link 2000+ Rules of Engagement for non-AOC aircraft.
2.3
Service Volume
2.3.1
This is the expected geographical coverage from the CSP’s individual VDL Ground
Stations providing the service within the volume of airspace in which LGS require
P a g e |7
Commercial In Confidence - Borealis Alliance
Issue 1.1
ATN/VDL services,
topography.
2.3.2
taking
into
account
line-of-sight
considerations
and
ground
The CSPs shall provide service within LGS Specified Service Volume. This airspace is
defined by flight level limits and geographical points shown in Appendix C.
P a g e |8
Commercial In Confidence - Borealis Alliance
Issue 1.1
3. Functional Requirements
3.1
General
3.1.1
The CSPs shall comply with all applicable requirements specified by the EUROCONTROL
Specification on Datalink Services [4] that defines detailed requirements, explanatory
materials and conformity assessment material providing means of compliance associated
with the Single European Sky Implementing Rule on Datalink Services.
3.1.2
The EUROCONTROL Specification includes requirements for compliance with ICAO Annex
10 and Supplement 5 of ARINC 631 [5].
3.2
Service Boundaries
3.2.1
Figure 1 illustrates the scope of the service and the service boundaries for ATN Datalink
services.
Figure 1 Service Interfaces
P a g e |9
Commercial In Confidence - Borealis Alliance
Issue 1.1
3.2.2
The CSPs shall provide the service to participating airlines (Reference Point ‘B’ in Figure
1) as specified below in section 3.4.
3.2.3
Service shall be an ICAO ATN compliant communications service permitting
communication between LGS and suitably equipped aircraft using VDL Mode 2 as the
air/ground communications service.
Note that Reference point ‘B’ is assumed to be located at the aircraft’s VHF antenna.
3.2.4
The CSPs shall be responsible for configuring and maintaining its systems in order to
ensure that the required communications service is provided in accordance with the
Service Level requirements given in section 4.
3.3
Reference Point ‘A’ Connection to ANSP
The following requirements will ensure interoperability between the ATN Ground/Ground routers
of the CSP and the ANSP (LGS). It places interoperability requirements on the interface to the
CSP network’s Ground/ground routers. This will ensure that application level hand-over (relying
on the ACM service) with neighbouring ANSPs can be performed. Indeed, an aircraft flying
between the airspace boundaries of two ANSPs shall be able to exchange at the same time
application level messages with both its Current Data Authority and with its Next Data Authority.
3.3.1
The service interface at Reference Point ‘A’ shall comply with the requirements to use the
existing IP gateway links between the LGS and CSP networks as appropriate.
3.3.2
The Network Terminating Unit (NTU) shall provide a CLNP communications path between
at least two ATN Routers (for redundancy) provided by the CSP and the ATN Routers
operated by the Borealis ANSP.
3.3.3
The service offered by the CSP ATN Routers shall be compliant with ICAO Doc 9880
(ATN-OSI Manual) [6] for a Class 4 Router and the Eurocontrol Specification on Data Link
Services [4].
3.3.4
The CLNP communication paths shall be compliant with the Eurocontrol Specification on
Data Link Services [4].
3.3.5
The interface shall be the IP SNDCF. This shall be compliant with the draft SARPs for the
IP SNDCF [SNDCF-IP].
3.3.6
The CSP shall operate its adjacency with the Borealis ANSP ATN Routers in the passive
role. The Borealis ANSP ATN Routers will be responsible for initiating BIS-BIS
communications.
3.3.7
The CPS’s ATN Routers shall advertise a route for each aircraft to the LGS ATN Router.
3.3.8
The tenderer shall provide a completed Protocol Implementation Compliance Statement
(PICS) for the ATN service provided by their ATN Routers and CLNP communications
path, including the IP SNDCF interface and IDRP compliance.
P a g e | 10
Commercial In Confidence - Borealis Alliance
Issue 1.1
3.4
Reference Point ‘B’ Service Provision to Participating Aircraft
3.4.1
Any CSP providing ATN/VDL2 services to participating aircraft under the jurisdiction of
LGS shall provide an interface at Reference Point ‘B’ in accordance with the following
requirements.
3.4.2
The VDL Mode 2 Service provided shall be compliant with ARINC Specification 631 “VHF
Digital Link Implementation Provisions” [5]. The CSP shall support all functionality
specified by ARINC 631 [5] PICS as Mandatory for a Ground provider, and shall not
implement functionality prohibited by these PICS.
3.4.3
The CSP shall initially support VDL Mode 2 operation on a single frequency but there is a
requirement to evolve to multi-frequency environment necessary to ensure that the
Service Level Requirements specified by Section 4 are maintained, subject to the
allocation of VHF frequencies to VDL Mode 2 by the appropriate regulatory authorities
and commercial terms and conditions when such additional frequencies become are
requested.
Note: EUROCONTROL simulations indicate that at least three frequencies will be required to support
VDL Mode 2 operation following the LINK 2000+ Mandate.
3.4.4
The CSP shall implement the Autotune procedure specified in ARINC 631 [5] to maintain
the Service Level Requirements of Section 4 for communication with airborne aircraft,
whenever this cannot be achieved on a single frequency. When so required, the CSP
shall be capable of sending an Autotune command in an uplinked Ground Requested Air
Initiated Handoff command, as well as in the uplink response to both a Link
Establishment request and Air Initiated Handoff request.
3.4.5
The CSP shall implement the Autotune procedures in advance of the preceding
requirements, if required by LGS or the local regulatory authority.
3.4.6
Subject to the availability of appropriate frequencies, the CSP may also support
dedicated ground frequencies, by means of the Frequency Support List, in accordance
with ARINC 631 [5].
3.4.7
When multi-frequency operation is in use, the CSP shall take all practicable measures to
avoid degradation of VDL Mode 2 performance and/or capacity arising from co-site
effects between VDL Ground Stations operating on different frequencies.
3.4.8
When multi-frequency operation is in use, the CSP shall implement a frequency
management strategy to ensure that continuous VDL connectivity is maintained when an
aircraft leaves the coverage of its current frequency while remaining in the CSP’s CSC
coverage.
Note: In the event that an aircraft loses VDL connectivity due to flying out of coverage of its current
frequency, the aircraft will perform Frequency Recovery by reference to an airborne FSL, or else will return to
the Common Signalling Channel (CSC). Either of these actions will generally lead to an interruption in VDL
connectivity. If the aircraft reverts to the CSC, restoration of connectivity will be delayed due to the time
taken to acquire the PECT. The CSP is required to avoid any such interruption, for example by autotuning the
aircraft to another frequency before loss of connectivity occurs.
P a g e | 11
Commercial In Confidence - Borealis Alliance
Issue 1.1
3.4.9
The VDL Mode 2 Service shall provide access to an ICAO ATN compliant communications
service provided by the CSP in accordance with the requirements of the EUROCONTROL
Specification [4].
3.4.10
The service offered by the CSP’s ATN Ground/Ground Router shall be compliant with
ICAO ATN standards for a Class 4 Router in accordance with the requirements of the
EUROCONTROL Specification [4].
3.4.11
The CSP’s ATN Ground/Ground Router should implement the agreed resolution of PDR
M2110003 (“IDRP Connection Recovery Problem”).
Note that this particular PDR is mandatory for Aircraft and Air/Ground Routers.
3.4.12
The CSP shall propagate IDRP routes to aircraft over the air-ground link using the
generic prefixes ‘All AINSC’ fixed (47002701) and ‘All ATSC’ fixed (47002781), with route
aggregation applied in both cases.
However, the above requirement is not intended to prohibit temporary advertisement of nonaggregated routes for testing or troubleshooting purposes, provided that any such temporary condition
avoids any significant effect on the performance of the operational network.
3.4.13
It is recommended that routes using the generic prefixes ‘All AINSC’ and ‘All ATSC’
should be statically configured in the CSP’s Air/Ground router(s), to avoid the reduction
process and ensure that only one advertisement of the routes occurs after IDRP
connectivity has been established between air and ground.
3.4.14
The CSP’s Air/Ground router(s) shall never propagate to an aircraft (AINSC or ATSC
mobile) any route prefixes received from an aircraft in IDRP UPDATE PDUs.
Note: This requirement is aimed at ensuring robustness of the ATN Routing environment. It prevents
erroneous propagation of both ground routes (i.e. with ground route in the NLRI and airborne RDI in the RD
Path attributes) and airborne routes (i.e. with airborne route in the NLRI and airborne RDI in the RD Path
attributes).
3.4.15
The CSP’s Air/Ground router(s) shall never propagate to a ground adjacency (AINSC or
ATSC fixed) any route prefixes received from an aircraft in IDRP UPDATE PDUs, except
for those carrying the aircraft’s own RDI route prefix.
Note: This requirement is also aimed at ensuring robustness of the ATN Routing environment. It prevents
erroneous propagation of both ground routes (i.e. with ground route in the NLRI - airborne in the RD Path
attributes), and airborne routes unrelated to the connected aircraft RDI (i.e. with a different RDI prefix in the
NLRI and RD PATH attributes).
3.4.16
The CSP’s VDL Mode 2 Service and ATN Air/Ground Router shall provide a
communications path between participating aircraft and LGS ATN Ground/Ground Router.
The CSP’s ATN Air/Ground Router(s) shall advertise to each aircraft, using IDRP, a route
capable of reaching LGS Routing Domains.
3.4.17
If the CSP operates more than one A/G Router, then following a VDL handoff between
VGSs connected to different A/G Routers, the CSP shall take measures to minimise the
time during which an obsolete air-ground IDRP route is maintained via an A/G Router
through which an aircraft is no longer reachable.
Note: When an aircraft performs a handoff from one VGS to another, the old link is maintained for the value of
TG5, with a default value of 60s on the ground. If the new VGS is connected to a different A/G router, then in
the worst case, an obsolete IDRP route via the old A/G Router could be advertised to adjacent G/G Routers
during this period. If this route has equal merit to the IDRP route via the new A/G Router, then uplink traffic
may continue to be routed via the old A/G Router. Since the old link may no longer be functional (the default
value of TG5 on the aircraft is only 20s) this is likely to lead to undesirable delays and/or TP4 re-transmissions.
P a g e | 12
Commercial In Confidence - Borealis Alliance
Issue 1.1
3.5
Reference Point ‘C’ CSP Inter-Connection
3.5.1
The service interface at Reference Point ‘C’ will be subject to commercial and technical
agreement between the two CSPs.
3.5.2
The CSPs shall implement a technical means to allow other CSP to interconnect with it,
so as to provide a communications path to LGS. This shall only be under network failure
conditions. LGS do not wish to contract to a service via the CSP interconnection,
however wish to acknowledge its presence should it be needed in extenuating
circumstances Interconnected CSPs shall establish Service Level Agreements and
Operating Procedures between them to ensure that overall service level requirements of
section 4 are satisfied when the end-to-end path traverses the network of both CSPs.
3.5.3
The CSPs providing an interconnection at Reference Point ‘C’ shall design and maintain
their system so as to route communication traffic bi-directionally via that interface
without imposition of any deficit in performance or quality of service compared to
communication traffic to/from its own network, except when such a deficit arises from
external factors outside the CSP’s control.
P a g e | 13
Commercial In Confidence - Borealis Alliance
Issue 1.1
4. Service Level Requirements
The level of service provided shall conform to the applicable parts of the EUROCONTROL
Specification [4], and to the specific requirements listed below.
4.1
Capacity
4.1.1
The service provided shall be capable of maintaining the service level requirements while
carrying the minimum number of uplink and downlink application level messages (inc.
LACK) specified by the LGS per aircraft per unit of time in support of the ATC Data link
Service.
4.1.2
The requirement for uplink and downlink application messages per flight hour should
enable a CPDLC message load of 100 messages per minute at peak times per centre
(Riga ACCs) in the ATN path(s).
4.1.3
The CSP shall be capable of supporting 100 flights simultaneously logged-on within the
Service Volume in the ATN path(s).
4.1.4
The above figures are based on LGS traffic forecasts for the year 2020.
4.1.5
CSP is required to make ATC Data link Services accessible to aircraft which are not
customers of the CSP’s AOC service, in accordance with the Eurocontrol Rules of
Engagement for non-AOC aircraft.
It is the CSP’s responsibility to ensure that its service has sufficient capacity to meet these requirements,
for all the aircraft customers to which it offers a service, and irrespective of the level of demand for AOC
services.
4.2
Performance
4.2.1
The transit delay shall meet, or be better than, the transit delay specified in Table 1
measured between Reference Point ‘A’ and an aircraft using the service, taking into
account any delay introduced by the ground network of any CSPs providing an
interconnection.
95% of all messages
99 % of all messages
Ground to air transit delay
4 seconds
8 seconds
Air to ground transit delay
4 seconds
8 seconds
Table 1 Transit Delay Requirements
4.2.2
The transit delay requirements of Table 1 shall be satisfied throughout the Service
Volume specified by section 2.3.
Note: For practical purposes, the above transit delay requirements will be expected to be satisfied, aggregated
between uplink and downlink directions, between Reference Point ‘A’ and the ARINC 750/429 interface of
an ARINC 750 compliant VHF Data Radio (VDR). In the event that the requirements are not met due to
an excessive Media Access Delay reported by the VDR, additional investigation will be necessary to ascertain
P a g e | 14
Commercial In Confidence - Borealis Alliance
Issue 1.1
the origin of the delay.
4.3
Availability, Reliability and Continuity of Service
4.3.1
The Availability, Reliability and Continuity of Service shall be as specified in the following
Tables for the end-to-end communications path segment between reference points ‘B’
and ‘A’.
4.3.2
The CSPs shall ensure that the applicable requirements are met at all times during which
LGS provides an operational ATC Service.
Requirement
Interpretation
Availability
99.99%
The proportion of the scheduled hours of operation during
which the data link service shall be available, over the entire
area in which service is provided and at adequate power
levels required for normal operations.
Reliability
99.99%
The probability that the system will successfully deliver a
message within 40 seconds.
Continuity of Service
6 min max. outage
The maximum permitted time between service failure and
the restoration of the service.
Table 2 Availability, Reliability and Continuity of Service Requirements
4.4
Integrity
4.4.1
The CSPs shall satisfy the Integrity requirements specified by Table 3 below.
Requirement
Integrity
Interpretation
The undetected bit error rate for the service shall be better
5
than 1 in 10 for network level packets transferred between
reference points ‘B’ and ‘A’.
Table 3 Data Integrity Requirements
-5
10
P a g e | 15
Commercial In Confidence - Borealis Alliance
Issue 1.1
4.5
Priority
4.5.1
The CSPs’s ATN Routers shall enforce CLNP packet priority.
4.5.2
Higher priority packets shall be forwarded before lower priority packets in the same
outgoing queue.
4.5.3
If an ATN Router discards packets due to congestion then lower priority packets shall be
discarded before the higher priority packets.
4.5.4
The VDL Mode 2 Ground Station should uplink any ATC messages queued for uplink
before uplinking other messages.
Note: This desirable requirement is intended to differentiate between ATN and e.g. AOA messages. It is not
intended to require that the VGS references or even has access to CLNP priority.
4.6
Safety and Security
4.6.1
The CSPs shall ensure that only authorised users have access to their part of the
Aeronautical Telecommunication Network.
4.6.2
In consultation with LGS, the CSP shall establish procedures and rules for users that
want to use the ATN/VDL Mode-2 network for test purposes, which have potential to
impact on the operational service provided by LGS.
4.6.3
The CSPs shall ensure that test users do not interfere with the operational users of the
network.
4.7
Maintenance
4.7.1
The CSPs shall monitor and maintain the communications service and the systems used
to provide the service in order to ensure that the specified service levels are achieved.
4.7.2
The CSPs shall undertake to correct in a timely fashion any significant non-compliance
with applicable Standards (including any subsidiary normative standard) discovered
during provision of the Service.
P a g e | 16
Commercial In Confidence - Borealis Alliance
Issue 1.1
5. Performance Monitoring and Network Management
5.1
Technical Support
5.1.1
The CSPs shall monitor all system functions within the scope of the service level
requirements.
5.1.2
The CSPs shall identify to LGS all recording and data logging mechanisms currently
supported by their ATN/VDL Mode 2 network.
5.1.3
In addition, the CSP shall nominate a Manager who is personally accountable for the
delivery and maintenance of the specified Services in accordance with the requirements
of this document.
5.1.4
The CSP shall develop and agree with LGS prior to commencing the service a manual of
fault reporting procedures and escalation procedures to define, communicate and
remedy faults and deficiencies.
5.1.5
The CSP shall install data recording and logging functions at critical points of observation
in the network to support fault and performance analysis. Logging of network activity
shall be performed against UTC time to facilitate correlation with other sources of
information. The CSP shall agree with LGS which points of observation will be subject to
logging, but as a minimum, it is expected that they will include the VGS, the A/G Router,
and where implemented, Reference Point ‘C’.
5.1.6
The CSP shall provide upon user request (i.e. LGS and Airline customer) all necessary
technical assistance, normally within one working day, including (but not limited to)
provision of logs of ATN, VDL and ACARS traffic against UTC time, to facilitate technical
investigations into performance of the Service.
5.2
Problem Reporting
5.2.1
The CSPs shall develop and agree with LGS a problem reporting procedure to notify the
users (i.e. LGS and Airline customer) of detected problems, including any degradation in
the service, impact on the service and progress regarding problem resolution. The CSP
shall respond to reasonable requests from LGS to minimise the operational impact of any
problem or degradation.
5.2.2
The CSP shall provide a clearly identified “Point of Contact” that can be contacted
whenever LGS experiences technical problems with the services provided by the CSP.
5.2.3
The CSP shall analyse and attempt to resolve the reported problems and, if appropriate,
take the required corrective actions needed to maintain the service.
5.2.4
The CSP providing an interconnection with the other CSP shall co-operate fully with LGS
and interconnected CSP to achieve a timely resolution of any technical problems
identified in the service level of data traffic carried through the interconnection.
5.2.5
The identified “Point of Contact” shall be available at all times during which the LGS is
providing an operational ATC Service
P a g e | 17
Commercial In Confidence - Borealis Alliance
Issue 1.1
5.3
Performance Reporting
5.3.1
The CSPs shall provide a monthly Performance Level Report showing the service level
achieved for the service provided. The required content of the Report will be established
by LGS; it should contain as much as practicable the information specified in Appendix A.
5.3.2
This report shall be sent to LGS electronically within 10 (ten) calendar days from the end
of the subject month.
5.4
Planned Engineering Work
5.4.1
The CSPs shall give at least 10 working days advanced notice of scheduled network
maintenance activities and the type of activity. The CSP shall highlight any degradation
in service expected from the activity and shall respond to reasonable requests from LGS
to minimise the operational impact of such degradation.
5.4.2
The CSP shall provide to LGS at least 10 working days notice of any changes to the
architecture, configuration or software versions of any component of the ATN, VDL and
ACARS networks involved in provision of the Service, where that change impacts upon
the Service. The CSP shall highlight any degradation in Service expected from the
activity, and shall respond to reasonable requests from LGS to minimise the operational
impact of such degradation.
P a g e | 18
Commercial In Confidence - Borealis Alliance
Issue 1.1
6. Communication Service Evaluation
6.1
Evaluation Process
6.1.1
Prior to offering an operational managed datalink service, each CSP shall complete a
process of evaluation to the satisfaction of LGS. The evaluation process shall consist of
the following steps:
a)
b)
c)
Delivery of documentary evidence to LGS
Completion of laboratory acceptance tests
Completion of flight tests demonstrating fitness-for-purpose
6.2
Delivery of Documentary Evidence
6.2.1
The CSP shall deliver to LGS the appropriate documentation providing evidence of the
ability of the CSP’s ATN/VDL Mode 2 systems to satisfy the end-to-end functional and
service level requirements specified by this document. The documentation delivered
shall include (but not be limited to) the items listed in Appendix B.
6.2.2
LGS will review this documentation to verify that it includes the necessary evidence of
conformance with the end-to-end requirements.
6.2.3
The CSP shall provide any additional evidence of conformance with requirements
specified by this document as required by LGS.
6.3
Laboratory Acceptance Tests
6.3.1
The CSP shall perform a series of Laboratory Acceptance Tests to demonstrate end-toend ATN connectivity with LGS systems, together with performance and robustness of
the VDL Mode 2 Service. The expected configuration and scope of these Acceptance
Tests is described in Annex C of LINK 2000+ Generic Requirements for a CSP [2].
6.3.2
Prior to conduct of the Acceptance Tests, the CSP shall prepare an Acceptance Test
Specification detailing the configuration and conduct of all tests to be performed. The
Acceptance Test Specification shall include (but not be limited to) the tests described in
Annex C of Generic Requirements document [2].
6.3.3
This testing aims to verify the CSP’s end-to-end ATN VDL-M2 communication chain, by
performing CM/CPDLC exchanges between air and ground applications. In addition, it
seeks to demonstrate the robustness of VDL Mode 2 handoffs under a variety of
conditions.
6.3.4
The Acceptance Test Specification shall be subject to review by LGS. Any additional
tests reasonably required by LGS to demonstrate interoperability with the LGS system
shall be included.
6.3.5
LGS may require its representatives to witness the conduct of Acceptance Tests by the
CSP.
P a g e | 19
Commercial In Confidence - Borealis Alliance
Issue 1.1
6.3.6
Following completion of the Acceptance Tests, the CSP shall deliver an Acceptance Test
Report to LGS, detailing all results. The CSP shall also make available all logs and
records collected during the conduct of the tests.
6.3.7
LGS may elect, at its sole discretion, to accept documentary evidence of satisfactory
completion of certain Acceptance Tests by the CSP on a previous occasion, without
requiring further conduct of such Tests.
6.4
Flight Tests
6.4.1
The CSP shall co-operate with LGS in arranging the conduct of flight tests to demonstrate
that the specified Services are fit for the intended purpose. The flight testing shall be
performed over routes specified by LGS.
Note 1: Flight testing is intended to demonstrate that adequate coverage is provided by the CSP’s
VGSs along major ATS routes through airspace under the jurisdiction of LGS. In addition, it seeks to give
confidence that functionality such as VDL handoffs are robust under operational conditions. LGS will take into
account the size and architecture of the airspace when specifying the duration and routes over which flight
trials are required.
Note 2: The arrangements for flight testing, including commercial considerations, will be the subject of
agreement between LGS and the CSP. Either a dedicated flight test or else conduct of tests with an airline
customer’s aircraft on revenue earning flights will be considered suitable to meet the requirements. This will
be organised by LGS.
6.4.2
Throughout every flight test, a continuous exchange of uplink and downlink CPDLC
messages shall be maintained, at a nominal rate of not less than one message every 10
seconds in each direction.
Note: The requirement for a continuous exchange of CPDLC messages may be achieved by a ‘tuning test’
involving an uplink of an erroneous CPDLC message, soliciting a downlink CPDLC ERROR response, without
involvement of the CDU or the aircrew.
6.4.3
Prior to conduct of the flight test, a Flight Test Specification shall be prepared detailing
the configuration, and conduct of the proposed flight tests, including the aircraft and the
routes to be flown. The Flight Test Specification shall be subject to review of LGS and all
reasonable requests for change shall be incorporated.
6.4.4
The pass criteria for the flight tests shall be that while the aircraft remains in airspace
within which the CSP is required to provide coverage:
a)
b)
c)
d)
an IDRP adjacency shall be maintained with the aircraft
No interruption shall occur to the continuous exchange of CPDLC messages
No CPDLC message shall fail to be delivered
The Transit Delay requirements specified by this document shall be satisfied over each individual ATS
route along which the test aircraft has flown.
6.4.5
Following completion of the Flight Tests, a Flight Test Report shall be prepared, detailing
all results. The CSP shall also make available all logs and records collected during the
conduct of the tests.
6.4.6
LGS may elect, at their sole discretion, to accept documentary evidence of satisfactory
completion of certain Flight Tests by the CSP on a previous occasion, without requiring
further conduct of such Tests.
P a g e | 20
Commercial In Confidence - Borealis Alliance
Issue 1.1
6.5
Observation Process
6.5.1
Following successful completion of the evaluation process in accordance with Section 6
above, the CSP will be permitted to offer an operational service for a limited period
constituting the Observation Period. The Observation Period shall last for a period
specified by LGS.
6.5.2
During the observation period, LGS will monitor the functionality and performance of the
Service provided by the CSP, and also the compliance of the CSP with the performance
monitoring and network management requirements (Section 5 refers).
6.5.3
LGS may impose certain constraints on the service to be offered during the observation
period (e.g. limits to the airlines permitted to use the Service) in order to facilitate the
monitoring of the service.
6.5.4
Any shortcomings detected in the Service during the observation period will be
addressed by means of the procedures outlined in Section 5 of this document.
6.5.5
Once all outstanding issues have been resolved to the satisfaction of LGS, the CSP’s
Services as described in this document will be declared fully operational, and any
remaining constraints will be withdrawn.
P a g e | 21
Commercial In Confidence - Borealis Alliance
Issue 1.1
APPENDIX A Contents of CSP Monthly Performance Reports
A.1
Overall Report on Quality of Service




Availability of VGSs ( percentage, failure)
Availability of AGR routers processors (percentage, failure)
Availability of Network Infrastructure
Explanations of failures (if any).
A.2
Statistics
A.2.1
Statistics on Aircraft


Number of aircraft connected and handled
Graphical representation of the trend for aircraft.
A.2.2
Statistics on VGSs
A.2.2.1
At AVLC layer






A.2.2.2
At 8208 layer



A.2.3
Per VGS, number of 8208 PDUs sent to/received from aircraft
Per VGS, number of 8208 PDUs sent to/received from AGR routers
Graphical representation of the trend for 8208 PDUs.
Statistics on AGRs




A.2.4
Per VGS, number of Link Establishments (Received, Rejected, Accepted)
Per VGS, number of Handoffs (Received, Rejected, Accepted)
Graphical representation of the trend for LE/HO
Analysis when LE/HO rejected (Which VGS, Aircraft ID, Date/Time, LE/HO, Reason)
Per VGS, statistics per frame type exchanged with aircraft : INFO (sent, received) - SREJ (sent, received) FRMR (sent, received)
Graphical representation of the trend for AVLC frames (INFO, SREJ, FRMR).
Per AGR, number of 8208 PDUs sent to/received from VGSs
Graphical representation of the trend for 8208 PDUs
Per AGR, number of CLNP DT and ER NPDUs (sent, received)
Graphical representation of the trend for CLNP DT and ER NPDUs .
Report of executed and planned changes to the network
P a g e | 22
Commercial In Confidence - Borealis Alliance
Issue 1.1
APPENDIX B Documentation Requirements
B.1
Introduction
The CSP is required to provide LGS with documentary evidence that the CSP’s ATN/VDL Mode 2 systems are
capable of satisfying the end-to-end functional and service level requirements specified by this document.
Where necessary, the CSP will be expected to make an appropriate allocation of service level requirements
(e.g. performance, availability, reliability and continuity) between the different components of the system,
and to provide evidence that each component is capable of meeting the relevant allocation.
B.2
Functional Requirements





CLNP and IDRP PICS for both CSP Air/Ground and ground routers
Reference Documentation of the CSP Air/Ground Router
Reference Documentation of the CSP Ground Router
VDL Mode 2 PICS for the VGS
Reference Documentation of the VGS
The above documentations shall specify the implemented values of all configurable timers, counters and
other parameters defined by ICAO and/or other applicable normative standards.
B.3
Capacity



B.4
A report showing the CSP has performed testing while simulating establishment of multiple aircraft
mobile links and IDRP adjacencies on their Air/Ground router, demonstrating compliance with the
Capacity Requirements stated in this document.
A report showing the CSP has performed testing with multiple simulated aircraft IDRP routes received on
their ground router, including a repetitive exercise consisting of adding IDRP routes, checking IDRP
routes prefixes and removing IDRP routes, demonstrating compliance with the Capacity Requirements
stated in this document.
A report showing the CSP has performed testing while simulating establishment of multiple mobile links,
traffic exchanges and clear of connectivity on one VGS, demonstrating compliance with the Capacity
Requirements stated in this document.
Performance



B.5
A report on performance tests done by the CSP on their Air/Ground ATN Router, demonstrating
consistency with the Performance Requirements stated in this document.
A report on performance tests done by the CSP on their Ground ATN Processor, demonstrating
consistency with the Performance Requirements stated in this document.
A report on performance tests performed by the CSP on their VGSs, demonstrating consistency with the
Performance Requirements specified by this document.
Priority


A functional description of the CSP’s ATN priority management mechanism.
A/G and Ground Routers logs from simulations performed in the CSP’s Laboratory illustrating the action
of the priority management mechanism.
P a g e | 23
Commercial In Confidence - Borealis Alliance
Issue 1.1


B.6
A functional description of the implementation of priority management within the CSP’s VDL Mode 2
system.
VGS traces illustrating the action of priority management with both ATC and AOC traffic involved.
Safety and Security Policy



B.7
IDRP policy rules put in place on both Air/Ground and Ground routers.
RIF Known BIS attributes defined by the CSP in the Air/Ground router configuration.
Mechanisms / rules put in place at VGSs to satisfy safety and security requirements.
Availability, Reliability and Continuity







B.8
An overall description of the CSP’s technical measures to satisfy the Availability, Reliability and
Continuity requirements.
Results on Endurance Tests performed by the CSP in their laboratory on Air/Ground and Ground
ATN, supplemented by operational experience where possible.
A description of redundancy systems/mechanisms which are put in place for both Air/Ground and
Ground ATN.
A description of the recovery procedure for both Air/Ground and Ground ATN in case of software and
hardware failures.
Results on Endurance Tests performed by the CSP in their laboratory on VDL Mode 2 VGSs and other
components, supplemented by operational experience where possible.
A description of redundancy systems/mechanisms which are put in place for VDL Mode 2 VGSs and
other components.
A description of the recovery procedure for VDL Mode 2 VGSs and other components in case of
software and hardware failures.
VDL Coverage

Expected geographical coverage from the CSP’s individual VDL transmitters providing the service within
the volume of airspace in which LGS requires ATN/VDL Services, taking into account line-of-sight
considerations and ground topography where applicable.
P a g e | 24
Commercial In Confidence - Borealis Alliance
Issue 1.1
APPENDIX C Required Coverage – Riga (LGS) FIR
1. The sufficient VDL coverage shall be provided in Riga FIR started from FL-195 and above
2. Co-ordinates of Riga FIR
RIGA FIR
582448N 0203834E - 580700N 0212900E - 575342N 0213648E - 575124N 0213848E - 574712N
0214300E - 574547N 0215034E -574458N 0215458E - 574645N 0220836E - 574930N 0221644E 575539N 0223501E -575627N 0224227E - 574650N 0225428E -574208N 0225957E - 573511N
0231051E - 573538N 0232422E - 574011N 0233456E -574658N 0233855E - 575357N 0233604E 575357N 0241234E - 575502N 0241540E - 575228N 0242123E Along the common Latvian/Estonian state boundary to 575112N 0255552E
Along the common Latvian/Estonian state boundary to 573103N 0272105E
Along the common Latvian/Russian existing administrative boundary to 564506N 0275406E
Along the common Latvian/Russian existing administrative boundary to 562843N 0280833E
Along the common Latvian/Russian existing administrative boundary to 561024N 0280848E
Along the common Latvian/Belarus existing administrative boundary to 554050N 0263750E
Along the common Latvian/Lithuanian state boundary to 555908N 0255651E
Along the common Latvian/Lithuanian state boundary to 562208N 0243749E
Along the common Latvian/Lithuanian state boundary to 562217N 0234520E
Along the common Latvian/Lithuanian state boundary to 562216N 0231222E
Along the common Latvian/Lithuanian state boundary to 560426N 0210537E 560409N 0210352E - 560402N 0204452E -560400N 0204000E - 560846N 0200456E 561752N 0185354E - 562043N 0183023E - 565217N 0193400E - 570000N 0195000E 571800N 0200000E - 581816N 0203443E -582448N 0203834E
P a g e | 25
Commercial In Confidence - Borealis Alliance
Issue 1.1
3. Diagram
Proposed timetable:Date
Functionality
Rationale
May 2014
ATN connectivity to LGS test
implementation (Riga).
Initial connectivity by this
date. Initially “ping” testing.
CSP support to LGS test
activities will ramp up from
March to August with a view to
having a system ready for
flight testing in September.
Exact
timetable
and
capabilities to be determined.
September 2014
Full ATN service availability to
support validation.
Flight testing will take place
after this date in various parts
of Latvian airspace, therefore
the full coverage must be
available.
October 2014
Connectivity
centre.
Full
infrastructure
deployed and ready.
November 2014
Full system to support limited
operational service from ACC
centre
7th February 2015
EU Mandate.
Service
to
Riga
ACC
now
Full service in place by this
date – training complete (if
necessary), support in place.
Full Operational
P a g e | 26
Commercial In Confidence - Borealis Alliance
Issue 1.1
APPENDIX D ATN Ground/Ground Router Provision
D.1
ATN Ground/Ground Routing Services
The services implemented in the ATN Router shall be compliant with all the
requirements applicable to the ATN Ground/Ground routing function (class 4 router)
presented in the Eurocontrol Specification on Data Link Services, [4] and in the ICAO
Documents 9896 [7] and 9880 [6].
The ISO/IEC 9542 (ES/IS) shall be implemented as defined in the ICAO Documents
9896 [7] and 9880 [6] and in the Eurocontrol Specification [4].
The ISO/IEC 10589 (IS/IS) should be implemented as defined in the ICAO Documents
9896 [7] and 9880 [6] and in the Eurocontrol Specification [4].
For the interface with the ATN End-Systems,

the 8802-2 SNDCF shall be implemented in compliance with the ICAO Documents
9896 [7] and 9880 [6],

the IP SNDCF shall be implemented in compliance with the ICAO document
[SNDCF-IP].
The ATN routers shall provide the following standard interfaces to connect them to the
ANSP networks:

100 Base-T Ethernet Interface,

Internet Protocol version 4,
The tenderer shall provide information on the migration towards the version 6 of the
Internet Protocols and especially on the appropriateness of his technical proposal.
The tenderer shall provide the completed Protocol Implementation Conformance
Statement (PICS) for its implementation of the Class 4 router as defined in this
paragraph (including the IP SNDCF).
The tenderer shall detail all the protocols/services supported by its implementation(s)
of the ATN ICS standard.
The tenderer shall state the software of the ATN routers.
The tenderer shall specify the minimum requirements (e.g. hardware, Operating
System…) to operate the software of the ATN routers.
The tenderer shall quote separately the Hardware/Operating System for ATN routers.
P a g e | 27
Commercial In Confidence - Borealis Alliance
Issue 1.1
D.2
Integration in the IP Wide Area Network infrastructure
I
N
T
E
R
F
A
C
E
I
N
T
E
R
F
A
C
E
WAN
ATN routers
The ATN routers should provide doubled physical and logical interfaces to the Network.
The failure of only one point of attachment should not impact the services supported
by the equipment (all the connections supported at 8208, IDRP or TP4 levels shall be
maintained). The tenderer should detail the proposed technical solution and, if any,
the functions which shall be supported by the WAN IP to handle such redundancy
mechanism.
D.3
Availability, Reliability & Maintainability Requirements
As a component of the overall technical system, the ATN routers contribute to the end-to-end
technical performances. The following requirements have been derived to ensure that the ATN
routers meet the required performance, in terms of availability, continuity of service, integrity,
reliability and transit delays, without jeopardizing compliance with ED-120 Required
Communication Technical Performances.
The Mean Time Between Failure (MTBF) of the service provided by an ATN router,
including the interfaces to the IP network should be greater than 50 000 (fifty
thousand) operating hours.
The tenderer shall provide the theoretical MTBF of the ATN routers and the IP
interfaces.
The Mean Time To Repair the ATN routers and the IP interfaces shall be less than 20
(twenty) minutes for level 2 maintenance.
ATN routers shall display unambiguous information about their status on their front
panel.
The Control & Monitoring System shall provide unambiguous information about the
status of the ATN routers.
Each software component being involved in the ATN service provision shall be
monitored by automated means (watchdog mechanism…) for detection of critical
conditions, abnormal process termination (crash, fatal error…) and process
misbehaviours (infinite loop, deadlocks…). When such a condition is encountered the
software shall be automatically restarted using the latest configuration successfully
P a g e | 28
Commercial In Confidence - Borealis Alliance
Issue 1.1
activated. The interruption of service (including detection and recovery) should not
exceed 6 minutes.
When an ATN router or an IP interface experiences one of the following critical events,
power reset, loss of communication link and failure in attempting to activate a
configuration , the equipment shall be automatically restarted using the latest
configuration successfully activated. The interruption of service (including detection
and recovery) should not exceed 6 minutes.
D.4
Capacity & ATN Router Processing Performance
The capacity of the ATN router in terms of simultaneous connections shall be sufficient
to prevent denial of service in LGS airspace.
The ATN router should support (work properly) at least 20 adjacent IDRP ground
neighbors at the same time.
The ATN router should support (work properly) at least 30 adjacent network systems
(End-system) at the same time.
The ATN router should support (work properly) at least 500 routes learned from IDRP
at the same time; this includes routes from aircrafts and routes from other service
providers (ANSP, ACSP).
The ATN Air/Ground router should support at least 1000 air/ground connections
(8208) at the same time.
Any processing performed by the ATN router including the interface to the IP network
should not jeopardize the compliance with the following performance requirement; the
probability that the ATN/VDL Mode 2 infrastructure will successfully deliver a packet
within 40 seconds shall be greater than 99.99%.
Any processing performed by the ATN router including the interface to the IP network
shall not affect the payload of the exchanged packets (8208 and IP).
Whatever the number of connections currently supported, any processing performed
by the ATN router including the interface to the IP network should not delay an
exchanged packet for more than 50 milliseconds.
In line with the requirements above, the tenderer shall detail in his tender the
limitations in terms of capacity of his ATN routers.
D.5
Software assurance level
The ATN router including the interface to the IP network should be compliant with the
Assurance Level 4 as defined in the EUROCAE Document ED-109 [8].
P a g e | 29
Commercial In Confidence - Borealis Alliance
Issue 1.1
APPENDIX E Datalink Front End Processor Requirements
Specification
E.1
Scope
E.1.1
The Specified Sub-System: the Datalink FEP
The Datalink Front-End Processor (FEP) is a key part of the ANSP datalink system. It provides
the communications gateway between the ANSP internal ATM systems, the ATN datalink world
and the FANS datalink world. This Appendix is the Sub System Requirements Specification
(SSRS) for the Datalink FEP. The Datalink FEP itself breaks down into three components: The ATN End System - this is a communications gateway that joins the LGS internal
systems to the ATN and, by standards-driven accommodation, FANS network. It contains
the functionality required to present the CM and Protected Mode-CPDLC applications to the
ATN network and the equivalent FANS AFN and CPDLC applications to the ACARS network.
Both network interfaces support connection to multiple CSPs, in the case of ATN by the
fact that it is a routable network protocol, and in the case of ACARS via multiple ACARS
interfaces. The data within these applications is then presented to an interface by which
the LGS internal systems can implement the functionality needed to support these
applications. The FEP itself may implement some of the functionality of these applications,
where it is necessary to do so to fulfil its role as communications gateway, or in addition to
this basic functionality, for convenience.
 ATN Router - as ATN is a routable network protocol, this functions as an ATN intermediate
system (i.e. a router) and allows the connection of the ATN end system to multiple CSP
ATN networks.
 Test support system (optional)- both GUI-based and script-based tools that allow the full
testing of the ATN server by emulation of interfacing ground systems, ATN airborne
systems and FANS airborne systems.
The following show the proposed ANSP architecture in diagrammatic form:-
P a g e | 30
Commercial In Confidence - Borealis Alliance
Issue 1.0
SITA ATN Aircraft
ARINC ATN Aircraft
ARINC FANS Aircraft
AT
N
SITA FANS Aircraft
PO
A
N
AT
AOA
AOA
AGR
AGR
AGR
ACARS
CSP-1
ATN Network
ACARS
Processor
MATIP / TCPIP
AGR
CSP-2
ATN Network
Internetwork
gateway
link
ACARS
ACARS
Processor
LGS premises
RIGA
ATN
G/G Router
FEP
Fig 1.1 – LGS Functional Architecture
PO
A
ATRACC
LGS ATM system
All routers symbols denote ATN routers
POA = Plain old ACARS
AOA = ACARS over ATN (VDL Mode 2)
ATN = Aeronautical Teleccomunications Network
(VDL Mode 2)
CSP = Communication Service Provider
LGS is going to purchase ATN G/G router and FEP
from CSP (CSP should indicate optional prices for
ATN G/G router and FEP)
P a g e | 31
Commercial In Confidence - Borealis Alliance
Issue 1.0
E.1.2
Redundancy and Availability
The ANSP intends to implement a system in compliance with the performance
parameters detailed in EUROCAE ED-120 [9]. As the Datalink FEPs will be a part of a
wider system, this means that the requirements placed on the FEP are one order of
magnitude higher than the ED-120 [9] requirements, to support a system-wide budget
that allows allocation to all the subsystems within the wider Datalink system.
The ANSP’s Business Continuity requires that each implementation of the system is a
redundant cluster. The ANSP’s installation practice means that each part of the cluster
can be installed in a separate equipment room with a significant distance (of the order of
30m) between the parts. The installation design and connectivity needed to support the
redundant clustering must support this configuration.
E.1.3
COTS versus Custom Solution
As an overriding principle, the ANSP wishes to procure COTS products, to de-risk the
project and to obtain benefit from best practice in the field. However the ANSP is
mindful that there is no standard offering in the marketplace and that due to the nature
of its legacy systems the ANSP has clear architectural requirements in some areas. Both
of these requirements mean that some customisation of COTS products may be
necessary to meet the ANSP’s requirements. Therefore, where distinct requirements do
not exist in this document, the supplier should offer what they have already
implemented in their product rather than propose a custom solution, unless there is
good reason to do the latter.
E.2
Requirements
E.2.1
System capability requirements
FEP001
The Datalink FEP shall be a communications gateway between the ANSP’s
internal systems, ATN networks and ACARS networks.
The Datalink FEP shall act as a communications gateway by implementing
application layer interfaces to the ANSP’s internal systems, by acting as an
ATN End System able to connect to the SITA and ARINC ATN networks, and
by providing interfaces to the SITA and ARINC ACARS networks.
The Datalink FEP shall implement an interface to the ANSP’s Control and
Monitoring system to supply system data to that system and to accept control
commands.
The Datalink FEP shall implement an interface to the ANSP’s Time Distribution
System for synchronisation of its system time.
The Datalink FEP shall implement an interface for the purposes of recording
operational data.
Each FEP shall be a redundant "hot standby" cluster.
The separate instances of a redundant cluster shall be able to be located in
separate equipment rooms of the order of 30m distance apart.
FEP002
FEP003
FEP004
FEP005
FEP006
FEP007
E.2.1.1
Communications Gateway functional requirements
FEP008
The Datalink FEP shall implement gateway functionality to support the
provision of the ATN Context Manager application by the ANSP’s systems, in
accordance with EUROCAE ED-110B [10] and EUROCAE ED-120 [9].
The Datalink FEP shall implement gateway functionality to support the
provision of the ATN Protected Mode CPDLC application by the ANSP’s
systems, in accordance with EUROCAE ED-110B [10] and EUROCAE ED-120
[9].
FEP009
P a g e | 32
Commercial In Confidence - Borealis Alliance
Issue 1.0
FEP010
FEP011
FEP012
FEP013
FEP014
FEP015
FEP016
FEP017
FEP018
FEP019
FEP020
FEP021
FEP022
The Datalink FEP shall implement gateway functionality to accommodate the
FANS AFN application, in accordance with EUROCAE ED-100A [12], EUROCAE
ED-154 [11] and ARINC 622 [6].
The Datalink FEP shall implement gateway functionality to accommodate the
FANS CPDLC application, in accordance with EUROCAE ED-100A [12],
EUROCAE ED-154 [11] and ARINC 622 [6].
The Datalink FEP shall present an interface to the ANSP’s systems that allows
those systems to provide ATN Context Manager functionality to aircraft that
request a login.
The DLIC Flight Plan correlation function shall be carried out by the ANSP’s
FDP systems, not the Datalink FEP.
Ground-Ground forwarding of logins shall be carried out by the LGS FDP
systems, not the Datalink FEP.
[Each ANSP to review the appropriateness of this to their FDP system:]The
Datalink FEP shall present an interface to the ANSP’s systems that allows
those systems to forward such ATN or FANS login data to the FEP as is
required for aircraft to successfully login via CM or AFN, where that
information has been forwarded to LGS systems via ground-ground
forwarding.
The Datalink FEP shall present an interface to the ANSP’s systems that allows
the LGS systems to inform the FEP when a particular aircraft can be
considered as having successfully logged in to the CM/AFN application.
The Datalink FEP shall present an interface to the ANSP’s systems that allows
those systems to generate CPDLC uplink messages for forwarding to aircraft,
and for interfacing the ANSP’s systems to receive downlinked CPDLC
messages from aircraft.
The Datalink FEP shall present an interface to the ANSP’s systems that allows
those systems to receive downlinked CPDLC messages from aircraft.
The structure of the above interface(s) shall be defined in an Interface
Control Document to be agreed with the ANSP at project kick-off.
The Datalink FEP shall implement blacklist functionality, allowing individual
aircraft to be excluded from connecting via (either) ATN or FANS.
The Datalink FEP shall implement white-list functionality, where all aircraft
can be blocked from connecting via individual aircraft to be excluded from
connecting via either ATN or FANS. It shall be possible to turn this function
on and off in adaptation.
The Datalink FEP shall implement a mechanism that allows both the ANSP’s
Systems and the FEP to monitor the interface between the two systems to
maintain an active session.
E.2.1.2
Control and Monitoring requirements
FEP023
The integrity of the interconnection between the Management System and
the Datalink FEP shall support the integrity levels of the Datalink System.
On an initial start up or after a long outage the Datalink FEP shall support
polling by the Management System in order to obtain the current status of all
monitored points.
The SNMP MIBs shall support management of all elements of the Datalink
FEP, including Operating System and hardware elements.
The Datalink FEP shall provide all the necessary information to the
Management System by using the SNMP protocol in order to diagnose faults
at an LRU level.
The Datalink FEP shall time stamp all event data with UTC time derived from
a central time source.
The Datalink FEP shall be capable of accepting from Monitoring System and
actioning a set of pre-defined commands such as start, stop, reboot etc. of
the system.
FEP024
FEP025
FEP026
FEP027
FEP028
P a g e | 33
Commercial In Confidence - Borealis Alliance
Issue 1.0
FEP029
FEP030
FEP031
FEP032
FEP033
The Datalink FEP shall provide a local console that provides, as a minimum,
access to all commands available via SNMP.
All data supplied to the Management System by the Datalink FEP shall be
time stamped with UTC time derived from a central time source.
Any console commands that result in reduction of service or shutdown shall
require an "are you sure" or similar confirmation prompt before the action is
instigated.
The loss or corruption of the Datalink FEP shall have no effect on the
operation of the Management System.
The Datalink FEP shall facilitate protection against electronic attack by use of
(where applicable):
- Managed network security solutions
- Data encryption
- Intrusion detection systems.
- Segregation of operational communications from other types of data and service.
- Passwords and Access Rights
FEP034
Only authorised users shall be able to access the configuration of the Datalink
FEP.
E.2.1.3
Recording requirements
FEP035
The Datalink FEP shall present all CM, AFN and CPDLC primitives and
messages to the recording interface.
The Datalink FEP shall record these messages in the format in which they are
communicated to the CSPs.
The Datalink FEP shall timestamp these messages with UTC at the recording
interface.
The Datalink FEP shall provide the addressed aircraft details and a human
readable format of the message contents.
The Datalink FEP shall record all Context Manager primitives and CPDLC
messages in LISAT Interchange XML format.
FEP036
FEP037
FEP038
FEP039
E.2.2
System external interface requirements
FEP040
The Datalink FEP shall support connection to a minimum of two CSPs' ATN
networks.
The Datalink FEP shall support connection to a minimum of two CSPs for
FANS.
Each connection mentioned in the three requirements above shall support
redundancy through multiple links between the connected systems.
The Datalink FEP shall support connection to a minimum of two interfacing
ANSP FDP systems.
The Datalink FEP shall be able to continue operating upon the loss of one or
more of its interfaces.
The Datalink FEP shall synchronise its system time via NTP version 4.
The Datalink FEP shall receive control commands from the Monitoring System
and provide monitoring information via SNMP v1.3 or later.
FEP041
FEP042
FEP043
FEP044
FEP045
FEP046
E.2.3
System internal data requirements
FEP047
FEP048
The Datalink FEP shall store the minimum of data internally necessary for its
role as a communications gateway.
The Datalink FEP shall use a primary key to identify all flights at its interfaces
to the ANSP’s systems. The structure of this key shall be agreed with the
ANSP.
E.2.4
Adaptation requirements
P a g e | 34
Commercial In Confidence - Borealis Alliance
Issue 1.0
FEP049
The Datalink FEP shall support by adaptation the capability for individual
CPDLC message types to be enabled and disabled. This shall include the
ability to enable messages for FANS only, ATN only or both.
E.2.5
Safety requirements
FEP050
The Datalink FEP shall be assured to EUROCAE ED-109 [8] Software
Assurance Level 4, or equivalent.
FEP051
The provider shall present the ANSP with relevant assurance artefacts as a
part of this tender process.
To mitigate risk, the ANSP considers that safety-critical systems should
implement features including but not limited to the following:-
FEP052
- Data range checking
- Data Error Detection, e.g. Cyclic Redundancy Checks, Checksums
- Exception Handling
- Failure handing and fallback modes
- Mechanisms that prevent contention for resources.
FEP053
The supplier shall supply evidence of where these risk-mitigating features are
incorporated into the design of the Datalink FEP.
E.2.6
Security and privacy requirements
FEP054
The Datalink FEP shall protect the ANSP’s internal systems from threats that
may be transmitted via the ATN and ACARS networks.
E.2.7
System location requirements
FEP055
FEP056
An operational FEP shall be deployed to the ANSP RIGA ACC
.
E.2.8
Test support system requirements (optional)
FEP057
A test support system shall be provided to support the testing, validation and
verification of the ANSP’s Datalink system
The test support system shall be capable of emulating the interfaces on which
the CM, AFN and CPDLC applications are presented to the ANSP’s systems.
The test support system shall be capable of emulating FANS and ATN
equipped aircraft.
The test support system shall be capable of running in a Graphical User
Interface (GUI) mode.
The test support system shall be capable of injecting data via scenario scripts
which can be created in and injected from the test tools.
The scenario scripted mode of the test support system shall be designed to
support stress testing. This shall include support for multiple logged-in
aircraft.
The test support system shall support the testing of error conditions by
allowing the injection of errors and out-of-sequence messages.
The stress testing support capability in the test support system shall be able
to stress the Datalink FEP to 150% of the agreed service capacity.
The test support system shall support simultaneous testing of two Datalink
FEPs.
The test support system shall be assured to the same level as the operational
software.
The test support system shall provide tools to analyse output from scripted
tests.
FEP058
FEP059
FEP060
FEP061
FEP062
FEP063
FEP064
FEP065
FEP066
FEP067
P a g e | 35
Commercial In Confidence - Borealis Alliance
Issue 1.0
E.2.9
Performance, Capacity and Resource requirements
E.2.9.1
Performance requirements
FEP068
The Datalink FEP shall have an availability of 99.99%
E.2.9.2
Service capacity requirements
FEP069
The Datalink FEP shall support a peak throughput of 200 CPDLC messages
per minute on all interfaces.
FEP070
The Datalink FEP shall support up to 400 logged in aircraft.
E.2.9.3
Computer hardware requirements
FEP071
Delivered hardware shall be commercially available.
FEP072
Delivered hardware shall be supported and upgradeable for a minimum of 7
years from the date of purchase.
FEP073
The preferred manufacturers for PC-based COTS components shall be Hewlett
Packard and Dell in that order.
FEP074
The preferred manufacturer for network switch/router and similar COTS
components shall be Cisco.
E.2.9.4
Computer hardware resource utilization requirements
FEP075
The Datalink FEP hardware resource utilisation shall be no greater than 50%
under the normal peak service load.
E.2.9.5
Computer software requirements
FEP076
Delivered software shall be supported and upgradeable for a minimum of 7
years from the date of purchase.
E.2.9.6
Computer communications requirements
FEP077
The Datalink FEP shall connect physically to other systems using Category 5e
STP cable and RJ45 termination.
FEP078
The Datalink FEP shall communicate with other systems using IP version 4
with a migration path to IP version 6.
E.2.10
System quality factors
FEP079
Quality documentation shall be provided for all delivered systems.
E.2.11
Design, construction and installation requirements
FEP080
The design of new equipment shall minimise the probability of single point
failures whether through fault or human error.
FEP081
Floor fixing of new equipment shall be undertaken where there is any risk of
toppling with high level sections withdrawn.
FEP082
The supplier shall specify the distributed floor loading of the equipment to be
installed.
P a g e | 36
Commercial In Confidence - Borealis Alliance
Issue 1.0
FEP083
Any equipment exceeding a point load of 4.5 kilo-Newtons (kN) shall be
provided with a plinth or other means of spreading the load.
FEP084
In accordance with Health and Safety Regulations, heavy items of equipment
(greater than 18Kg) should only be mounted at waist level or below (i.e.,
approximately 1 metre above floor level).
FEP085
Mechanical methods of lifting and moving heavy loads shall be employed in
line with manual handling procedures.
FEP086
Rack mounted keyboards and consoles shall be installed at a height between
1050mm and 1150mm above finished floor level.
FEP087
Cabling systems shall be installed using Low Smoke and Zero Halogen (LS0H)
cable sheaths.
FEP088
All Data and Communication cabling systems shall be installed using shielded
cables.
FEP089
All Patch Panels, Patch Leads and connectors shall be shielded to match the
cabling systems used.
FEP090
Designs shall enable replacement of faulty items with minimum disruption to
Operations and other equipment.
FEP091
It shall not be necessary to withdraw power from, or otherwise interrupt the
service given by, complete systems in order to remove or replace modules or
to repair faults that do not in themselves cause loss of system service.
FEP092
Equipment layout and implementation shall enable routine maintenance, and
replacement of faulty items with minimum disruption to the operation and
other equipment.
FEP093
Individual items of equipment shall be capable of operating when being
supplied with power having the following electrical characteristics:
Three phase 400 volts nominal
Tolerance for 400 volts is +10%/-6%
Single phase 230 volts nominal
Tolerance for 230 volts is +10%/-6%
50Hz frequency
Tolerance for 50Hz is +1%/-1%.
FEP094
The installed sub-system shall operate with a transient voltage condition not
exceeding 10% fluctuation of nominal volts that does return to steady state
tolerance of nominal volts within 0.5 seconds.
FEP095
The system shall operate with phase to phase voltages within 2.5% of the
summated average of the three voltages. All three phase-to-phase voltages
will be within +10%/-6% of nominal volts.
FEP096
The system shall be installed such that load distribution between phases is
reasonably balanced and out of balance neutral current does not exceed 5%
of lowest line current.
FEP097
The equipment shall operate with the maximum harmonic content of source
voltage not exceeding 5% total under resistive load test conditions between
no load and full load.
FEP098
The system shall operate with short term transient conditions in the form of
“spikes” in the order of 50% changes of voltage with duration of from 1
microsecond to 1 millisecond.
FEP099
The acoustic noise levels in unmanned Operational areas shall not exceed a
general level of 65 dbA.
FEP100
Systems shall be able to operate continuously in ambient temperatures
between 16-32 degrees C.
P a g e | 37
Commercial In Confidence - Borealis Alliance
Issue 1.0
FEP101
The assignment of electrical systems to each area shall not exceed the Design
Envelope of the Power and HVAC provision.
FEP102
Components shall be capable of operating continuously in ambient humidity
ranging from 20-80% non-condensing.
FEP103
Whenever possible, common parts, modules, assemblies, enclosures,
elements, and power supplies shall be used.
FEP104
Equipment, display units, chassis and modules shall be detachable from their
position to a diagnostic and repair location.
FEP105
Sufficient shielding shall be provided to prevent electromagnetic interference
with adjacent equipment.
FEP106
The Electrical Equipment Power Factor (PF) shall be not less than 0.85 for all
equipment.
FEP107
The electrical power input protection rating, type and circuit design shall be
provided during the design period.
FEP108
The steady load current and start up in rush current shall be quoted for the
equipment during the design period.
FEP109
All systems to be installed shall satisfy the ANSP Installation Manual, a copy
of which shall be furnished to the supplier.
FEP110
FEP111
Materials used shall be chosen with due consideration for safety, durability,
reliability, retention of appearance, and avoidance of corrosion, of fire, of
smoke, or other chemical or physical affects.
FEP112
The installed systems shall meet the requirements of EC directives on
Electromagnetic Compatibility and all relevant country standards.
FEP113
The system shall comply with the best prevailing and anticipated health and
safety standards for:a) The X-ray levels radiated from equipment
b) The electrostatic field generated by display equipment.
c)
The electromagnetic field generated by display equipment.
For the appropriate equipment, actual levels as well as compliance with
standards should be stated.
FEP114
All equipment units or sub-units shall be marked with their weight where it
exceeds 10 kg (22 lbs.).
FEP115
Workmanship shall meet the requirements defined in the ANSP’s Installation
Manual.
FEP116
All equipment and parts, including maintenance and test equipment supplied
by the project, that are interchangeable or replaceable shall satisfy the
requirements through the EC regulations and carry a CE Marking.
FEP117
The design of equipment both bespoke and off-the-shelf, shall facilitate safe
and efficient maintenance.
FEP118
The installed systems shall comply with the provisions of the the ANSP’s
Health and Safety plan and the ANSP’s Fire Safety and Fire Protection policy.
FEP119
The system shall be provided with power supplies from 2 independent UPS
sources.
FEP120
In so far as reasonably practicable, all operational, support and
administrative systems, equipment and associated cabling systems to be
installed shall be constructed, installed and protected and shall be capable of
being maintained, inspected and tested so as to prevent danger to staff and
risk to operational systems.
FEP121
Cabling to equipment shall as far as is practicable be terminated either on the
supporting racks or on the back plane. Cable connections directly into slideP a g e | 38
Commercial In Confidence - Borealis Alliance
Issue 1.0
in-units shall be avoided as this prevents easy removal of units and over time
reduces the reliability of the connections.
FEP122
The supplier shall furnish the ANSP with the total electrical load and heat load
of delivered systems.
E.2.12
Documentation requirements
E.2.12.1 General
FEP123
Technical Documentation shall be provided for the Datalink FEP.
FEP124
All deliverable documentation shall be written in English, using standardised
presentation and notation.
FEP125
All deliverable Technical documentation shall be provided as paper copy and
in an editable electronic format (e.g. Microsoft Word .doc).
E.2.12.2 Technical Documentation
FEP126
The Technical documentation provided by the supplier shall enable operation,
maintenance, fault diagnosis and repair of the equipment by trained
personnel within the ANSP.
FEP127
The Technical documentation shall provide sufficient information to enable
repair to a level appropriate with the agreed maintenance policy.
FEP128
The Technical documentation shall clearly describe the function of all
hardware items.
FEP129
The Technical documentation shall clearly describe all internal and external
interfaces.
FEP130
The Technical documentation shall include a clear and concise description of
any setting up procedures for equipment.
FEP131
The Technical documentation shall include full details on how to configure the
system, e.g. change link/ switch setting on cards.
FEP132
A User Guide shall be provided which shall contain information as to the
operation and management of the system.
FEP133
Documentation on COTS hardware and OS components shall be provided
E.3
LGS application of Eurocontrol Specification
The following requirements have been taken from the Eurocontrol Specification on Data
Link Services and placed here as LGS understands they apply to the Datalink FEP and so
must be included in any requirement specification. LGS is utilising these requirements
as a part of its evidence of compliance with the Datalink Services Implementing Rule.
FEP134
The Datalink FEP shall adhere to the requirements laid down in the
Eurocontrol Specification on Datalink Services [4], where these apply to the
Datalink FEP component of the overall Datalink system.
The application of these requirements to the supplier's product depends on the actual
functionality that is offered as COTS. The supplier will be required to provide analysis
against these requirements early in the project. Performance data is left as "XX"
placeholders as it is anticipated that the requirements will be clarified during the project
as it is further understood how the FEP interacts with the broader system and
contributes to the system-wide performance requirements.
P a g e | 39
Commercial In Confidence - Borealis Alliance
Issue 1.0
E.4
Data Link Services General Requirements
E.4.1
Ground Systems
FEP135
All CPDLC downlink message (DM) elements that are implemented in support
of the ACL, ACM and AMC services shall be passed by the Datalink FEP on to
the LGS ATM System.
FEP136
Downlink CPDLC messages not supported by the implementation shall result
in an appropriate error response being sent by the Datalink FEP, as defined in
ED-110B [10], being sent to the airborne system.
FEP137
All uplink message (UM) elements that are implemented in support of the
Link 2000+ ACL, ACM and AMC services shall be accepted by the Datalink FEP
from the LGS ATM System.
FEP138
When latitude and longitude are included in CPDLC message elements, the
Datalink FEP shall use the (degrees, minutes, seconds) format.
E.4.2
Common Interoperability Requirements
FEP139
The Logical Acknowledgement (LACK) messages (downlink message element
DM100 and uplink message element UM227) shall be used in ACL and ACM
message exchanges.
E.4.3
Common Performance Requirements
FEP140
Implementations of Systems and Services shall be compliant with the
associated Performance Requirements specified by EUROCAE ED-120 [9].
E.4.4
Common Safety Requirements
FEP141
Implementations of Systems and Services shall be compliant with the
associated Safety Requirements specified by EUROCAE ED-120 [9].
E.5
Specification of Data link Service ACM
E.5.1
Specific Interoperability Requirements
FEP142
Implementations of the ACM service shall comply with the air-ground
interoperability requirements specified in ED-110B [10] chapter 4.2 and 4.3,
except where indicated otherwise in this specification.
FEP143
The ACM service shall be implemented in compliance with “Case A” as
specified in ED-110B [10], paragraph 4.3.4.
FEP144
When issuing a data link transfer instruction, compliant ground systems shall
therefore send the requisite message element (UM117 CONTACT or UM120
MONITOR) in a CPDLC-End Request without concatenating a UM135 CONFIRM
ASSIGNED LEVEL message element.
E.5.2
Uplink Message Elements
FEP145
The Datalink FEP shall allow the sending of the CPDLC message elements in
section E.4, with valid parameters where applicable.
E.5.3
Downlink Message Elements
FEP146
The Datalink FEP shall have the capability to receive and forward to LGS
systems the message elements in section E.10.
P a g e | 40
Commercial In Confidence - Borealis Alliance
Issue 1.0
E.5.4
Specific Performance Requirements
FEP147
ACM implementations shall satisfy the performance requirements specified in
ED-120 [9] chapter 5.1.3.2. As the ED-120 parameters are system-wide, to
meet these, the following requirements are placed upon the Datalink FEP:Continuity C XX
Availability A(USE) XX
Availability A(PROVISION) XX
Integrity I XX
E.5.5
Specific Safety Requirements
FEP148
ACM implementations shall satisfy the safety requirements specified in ED120 [9] chapter 5.1.2.3, excluding requirements relating to downstream
clearance.
FEP149
The Datalink FEP shall facilitate the sending of operational CPDLC messages
to an aircraft when it has control of that aircraft unless it is a D-ATSU
conducting DSC.
FEP150
The Datalink FEP shall facilitate the rejection of any aircraft request for
CPDLC establishment when appropriate.
FEP151
When a request for CPDLC establishment is rejected by an ATSU, an
indication of the rejection shall be provided to the aircraft.
FEP152
The Datalink FEP shall faciltitate the termination of CPDLC at the request of
LGS systems.
FEP153
Any processing (data entry/encoding/ transmitting/ decoding/displaying) shall
not affect the intent of the message.
E.6
Specification of Data Link Service ACL
E.6.1
Specific Interoperability Requirements
FEP154
Implementations of the ACL service shall comply with the air-ground
interoperability requirements specified in ED-110B [10] chapter 4.2 and 4.4,
except where indicated otherwise in this specification.
E.6.2
Uplink Message Elements
FEP155
The Datalink FEP shall allow the sending of the CPDLC message elements in
section E.10, with valid parameters where applicable.
E.6.3
Downlink Message Elements
FEP156
The Datalink FEP shall have the capability to receive and forward to LGS
systems the CPDLC message elements in section E.10, with valid parameters
where applicable.
E.6.4
Implementation Issues
FEP157
The Datalink FEP shall ignore the Alert attribute on received CPDLC
messages.
FEP158
The Datalink FEP shall ignore the Urgency attribute on received CPDLC
messages.
P a g e | 41
Commercial In Confidence - Borealis Alliance
Issue 1.0
E.6.5
Specific Performance Requirements
FEP159
ACL implementations shall satisfy the performance requirements specified in
ED-120 [9], chapter 5.2.3.2. As the ED-120 parameters are system-wide, to
meet these the following requirements are placed upon the Datalink FEP:Continuity C XX
Availability A(USE) XX
Availability A(PROVISION) XX
Integrity I XX
E.6.6
Specific Safety Requirements
FEP160
ACL implementations shall satisfy the safety requirements specified below
(ED-120 [9], chapter 5.2.2.3.)
FEP161
Each uplink message shall be uniquely identified for a given aircraft-ATSU
pair.
FEP162
Each downlink message shall be uniquely identified for a given aircraft-ATSU
pair.
FEP163
A response message shall indicate to which message it refers.
FEP164
Each message shall be time stamped.
FEP165
The time stamp shall indicate the time that the message is released by the
initiator for onward transmission.
FEP166
Any processing (data entry/encoding/ transmitting/ decoding/displaying) shall
not affect the intent of the message.
FEP167
The initiator shall transmit messages to the designated end system.
FEP168
The Datalink FEP shall be synchronized to within one second of UTC.
FEP169
The Datalink FEP shall prohibit operational processing of detected corrupted
messages.
FEP170
The recipient shall be able to determine the message initiator.
FEP171
Whenever an operational message is discarded an indication shall be provided
to the initiator.
FEP172
Messages shall be transmitted/received in the order that they are sent.
E.7
Specification of Data link Service AMC
E.7.1
Specific Interoperability Requirements
FEP173
Implementations of the AMC service shall comply with the interoperability
requirements specified in ED-110B [10] chapter 4.2 and 4.5, except where
indicated otherwise in this specification.
E.7.2
Uplink Message Set
FEP174
The Datalink FEP shall allow the sending of the messages UM157 and UM183,
with valid parameters where applicable. See section E.10 of this document
for a full list of CPDLC messages to be supported.
E.7.3
Specific Performance Requirements
FEP175
AMC implementations shall satisfy the performance requirements specified
below (ED-120 [3] chapter 5.3.3.2). As the ED-120 parameters are systemwide, to meet these, the following requirements are placed upon the Datalink
FEP:P a g e | 42
Commercial In Confidence - Borealis Alliance
Issue 1.0
The AMC service shall exhibit an integrity of XX.
E.7.4
Specific Safety Requirements
FEP176
AMC implementations shall satisfy the safety requirements specified below
(ED-120 [9] chapter 5.3.2.3)
FEP177
Each uplink message shall be uniquely identified for a given aircraft-ATSU
pair.
FEP178
Each message shall be time stamped
FEP179
The time stamp shall indicate the time that the message is released by the
initiator for onward transmission.
FEP180
Any processing (data entry/encoding/ transmitting/ decoding/displaying) shall
not affect the intent of the message.
FEP181
The initiator shall transmit messages to the designated end system.
FEP182
The Datalink FEP shall be synchronized to within one second of UTC.
E.8
Specification of Data link Service DLIC
E.8.1
Specific Interoperability Requirements
FEP183
Implementations of the DLIC service shall comply with the interoperability
requirements specified in ED-110B [10] chapter 4.1, except where indicated
otherwise in this specification.
E.8.2
Specific Performance Requirements
FEP184
DLIC implementations shall satisfy the performance requirements specified
below (ED-120 [9] chapter 4.3.2). As the ED-120 parameters are systemwide, to meet these, the following requirements are placed upon the Datalink
FEP:Continuity C XX
Availability A(USE) XX
Availability A(PROVISION) XX
Integrity I XX
E.8.3
Specific Safety Requirements
FEP185
DLIC implementations shall satisfy the safety requirements specified below
(ED-120 [9] chapter 4.2.2.)
FEP186
Any processing (data entry/encoding/transmitting/decoding/displaying) shall
not affect the intent of the DLIC message.
E.9
End-To-End Communications General Requirements
E.9.1
Common Interoperability Requirements
FEP187
The Datalink FEP shall implement a Ground-Ground ATN Router, as defined
by ICAO Doc 9896 [7], in order to support interoperations with each other.
FEP188
ATN Routers and Systems incorporating an ATN End System shall comply
with the requirements of ED-110B [10] chapters 2 and 3 that are applicable
to ATN communications services (ICS and ULCS), CM Application and CPDLC
Applications, and amended as described in this document.
FEP189
ATN Routers and Systems incorporating an ATN End System shall comply
with the requirements of ED-110B [10] chapters 2 and 3 that are applicable
P a g e | 43
Commercial In Confidence - Borealis Alliance
Issue 1.0
to ATN communications services (ICS and ULCS), CM Application and CPDLC
Applications, and amended as described in this Annex.
FEP190
In addition to the Doc 9896 updates specified in ED-110B [10], chapter 2.4,
implementations should additionally incorporate all defect resolutions listed in
Table B-1.
Table B-1: Modifications to ICAO Doc 9896 - General
PDR ref
PDR
Description
(Ed 2)
Applies To
99070001
ICAO 9705 Edition 2
- Editorial Errors
All Systems
M1050001
Correction of CLNP
Priority
All Systems
M0060001
ICAO 9705 Edition 2
- Editorial Errors
All Systems
Notes
Documents
restriction of CLNP
priorities on VHF
data links.
E.10
Specification of Data link Application CPDLC
FEP191
The Datalink FEP shall support the following CPDLC messages:-
DM0 WILCO
DM1 UNABLE
DM2 STANDBY
DM3 ROGER
DM4 AFFIRM
DM5 NEGATIVE
DM6 REQUEST [level]
DM7 REQUEST BLOCK [level] TO [level]
DM8 REQUEST CRUISE CLIMB TO level]
DM9 REQUEST CLIMB TO [level]
DM10 REQUEST DECENT TO [level]
DM11 AT [position] REQUEST CLIMB TO [level]
DM12 AT [position] REQUEST DESCENT TO [level]
DM13 AT [time] REQUEST CLIMB TO [level]
DM14 AT [time] REQUEST DESCENT TO [level]
DM15 REQUEST OFFSET [specified distance] [direction] OF ROUTE
DM16 AT [position] REQUEST OFFSET [specified distance] [direction] OF ROUTE
DM17 AT [time] REQUEST OFFSET [specified distance] [direction] OF ROUTE
DM18 REQUEST [speed]
DM19 REQUEST [speed] TO [speed]
P a g e | 44
Commercial In Confidence - Borealis Alliance
Issue 1.0
DM20 REQUEST VOICE CONTACT
DM21 REQUEST VOICE CONTACT [frequency]
DM22 REQUEST DIRECT TO [position]
DM23 REQUEST [procedure name]
DM24 REQUEST CLEARANCE [route clearance]
DM25 REQUEST [clearance type] CLEARANCE
DM26 REQUEST WEATHER DEVIATION TO [position] VIA [route clearance]
DM27 REQUEST WEATHER DEVIATION UP TO [specifiedDistance] [direction] OF ROUTE
DM28 LEAVING [level]
DM29 CLIMBING TO [level]
DM30 DESCENDING TO [level]
DM31 PASSING [position]
DM32 PRESENT LEVEL [level]
DM33 PRESENT POSITION [position]
DM34 PRESENT SPEED [speed]
DM35 PRESENT HEADING [degrees]
DM36 PRESENT GROUND TRACK [degrees]
DM37 MAINTAINING [level]
DM38 ASSIGNED LEVEL [level]
DM39 ASSIGNED SPEED [speed]
DM40 ASSIGNED ROUTE [route clearance]
DM41 BACK ON ROUTE
DM42 NEXT WAYPOINT [position]
DM43 NEXT WAYPOINT ETA [time]
DM44 ENSUING WAYPOINT [position]
DM45 REPORTED WAYPOINT [position]
DM46 REPORTED WAYPOINT [time]
DM47 SQUAWKING [code]
DM48 POSITION REPORT [position report]
DM49 WHEN CAN WE EXPECT [speed]
DM50 WHEN CAN WE EXPECT [speed] TO [speed]
DM51 WHEN CAN WE EXPECT BACK ON ROUTE
DM52 WHEN CAN WE EXPECT LOWER LEVEL
DM53 WHEN CAN WE EXPECT HIGHER LEVEL
DM54 WHEN CAN WE EXPECT CRUISE CLIMB TO [level]
DM55 PAN PAN PAN
DM56 MAYDAY MAYDAY MAYDAY
DM57 remaining fuel] OF FUEL REMAINING AND [persons on board] PERSONS ON
BOARD
P a g e | 45
Commercial In Confidence - Borealis Alliance
Issue 1.0
DM58 CANCEL EMERGENCY
DM59 DIVERTING TO [position] VIA [route clearance]
DM60 OFFSETTING [specified distance] [direction] OF ROUTE
DM61 DESCENDING TO [level]
DM62 ERROR [errorInformation]
DM63 NOT CURRENT DATA AUTHORITY
DM64 [facility designation]
DM65 DUE TO WEATHER
DM66 DUE TO AIRCRAFT PERFORMANCE
DM67 [free text]
DM68 [free text]
DM69 REQUEST VMC DESCENT
DM70 REQUEST HEADING [degrees]
DM71 REQUEST GROUND TRACK [degrees]
DM72 REACHING [level]
DM73 [version number]
DM74 REQUEST TO MAINTAIN OWN SEPARATION AND VMC
DM75 AT PILOTS DISCRETION
DM76 REACHING BLOCK [level] TO [level]
DM77 ASSIGNED BLOCK [level] TO [level]
DM78 AT [time] [distance] [to/from] [position]
DM79 ATIS [atis code]
DM80 DEVIATING UP TO [specified distance] [direction] OF ROUTE
DM81 WE CAN ACCEPT [level] AT [time]
DM82 WE CANNOT ACCEPT [level]
DM83 WE CAN ACCEPT [speed] AT [time]
DM84 WE CANNOT ACCEPT [speed]
DM85 WE CAN ACCEPT [specified distance] [direction] at [time]
DM86 WE CANNOT ACCEPT [specified distance] [direction]
DM87 WHEN CAN WE EXPECT CLIMB TO [level]
DM88 WHEN CAN WE EXPECT DESCENT TO [level]
DM89 MONITORING [unitname] [frequency]
DM90 [free text]
DM91 [free text]
DM92 [free text]
DM93 [free text]
DM94 [free text]
DM95 [free text]
P a g e | 46
Commercial In Confidence - Borealis Alliance
Issue 1.0
DM96 [free text]
DM97 [free text]
DM98 [freetext]
DM99 CURRENT DATA AUTHORITY
DM100 LOGICAL ACKNOWLEDGMENT
DM101 REQUEST END OF SERVICE
DM102 LANDING REPORT
DN103 CANCELLING IFR
DM104 ETA [position][time]
DM105 ALTERNATE AERODROME [airport]
DM106 PREFERRED LEVEL [level]
DM107 NOT AUTHORIZED NEXT DATA AUTHORITY
DM108 DE-ICING COMPLETE
DM109 TOP OF DESCENT [time]
DM110 TOP OF DESCENT [position]
DM111 TOP OF DESCENT [time] [position]
DM112 SQUAWKING 7500
DM113 [speed type] [speed type] [speed type] SPEED [speed]
FEP192
The Datalink FEP shall support the following CPDLC uplink messages:-
UM0 UNABLE
UM1 STANDBY
UM3 ROGER
UM4 AFFIRM
UM5 NEGATIVE
UM19 MAINTAIN [level]
UM20 CLIMB TO [level]
UM23 DESCEND TO [level]
UM26 CLIMB TO REACH [level] BY [time]
UM27 CLIMB TO REACH [level] BY [position]
UM28 DESCEND TO REACH [level] BY [time]
UM29 DESCEND TO REACH [level] BY [position]
UM46 CROSS [position] AT [level]
UM47 CROSS [position] AT OR ABOVE [level]
UM48 CROSS [position] AT OR BELOW [level]
UM51 CROSS [position] AT [time]
UM52 CROSS [position] AT OR BEFORE [time]
UM53 CROSS [position] AT OR AFTER [time]
P a g e | 47
Commercial In Confidence - Borealis Alliance
Issue 1.0
UM54 CROSS [position] BETWEEN [time] AND [time]
UM55 CROSS [position] AT [speed]
UM61 CROSS [position] AT AND MAINTAIN [level] AT [speed]
UM64 OFFSET [specifiedDistance] [direction] OF ROUTE
UM72 RESUME OWN NAVIGATION
UM74 PROCEED DIRECT TO [position]
UM79 CLEARED TO [position] VIA [routeClearance]
UM80 CLEARED [route clearance]
UM82 CLEARED TO DEVIATE UP TO [specifiedDistance] [direction] OF ROUTE
UM92 HOLD AT [position] AS PUBLISHED MAINTAIN [level]
UM94 TURN [direction] HEADING [degrees]
UM96 CONTINUE PRESENT HEADING
UM106 MAINTAIN [speed]
UM107 MAINTAIN PRESENT SPEED
UM108 MAINTAIN [speed] OR GREATER
UM109 MAINTAIN [speed] OR LESS
UM116 RESUME NORMAL SPEED
UM117 CONTACT [unitname] [frequency]
UM120 MONITOR [unitname] [frequency]
UM123 SQUAWK [code]
UM133 REPORT PRESENT LEVEL
UM148 WHEN CAN YOU ACCEPT [level]
UM157 CHECK STUCK MICROPHONE [frequency]
UM159 ERROR [errorInformation]
UM160 NEXT DATA AUTHORITY [facility]
UM162 SERVICE UNAVAILABLE
UM165 THEN
UM171 CLIMB AT [verticalRate] MINIMUM
UM172 CLIMB AT [verticalRate] MAXIMUM
UM173 DESCEND AT [verticalRate] MINIMUM
UM174 DESCEND AT [verticalRate] MAXIMUM
UM179 SQUAWK IDENT
UM183 [freetext]
UM190 FLY HEADING [degrees]
UM196 [freetext]
UM203 [freetext]
UM205 [freetext]
UM211 REQUEST FORWARDED
UM213 [facilitydesignation] ALTIMETER [altimeter]
P a g e | 48
Commercial In Confidence - Borealis Alliance
Issue 1.0
UM215 TURN [direction] [degrees]
UM222 NO SPEED RESTRICTION
UM227 LOGICAL ACKNOWLEDGMENT
UM231 STATE PREFERRED LEVEL
UM232 STATE-TOP-OF-DESCENT
UM237 REQUEST AGAIN WITH NEXT UNIT
E.10.1
Specific Interoperability Requirements
FEP193
The Datalink FEP shall support the use of the CPDLC application message
integrity check mechanism.
FEP194
Where ED-110B [10] refers to CPDLC as specified in ICAO Doc. 9705 (SubVolume II, chapter 2.3, modified by the specified defect resolutions), the
provisions of ICAO Doc. 9880, Part I, Chapter 3 [6] may be taken as
equivalent.
E.11
Specification of Data Link Application CM
E.11.1
Specific Interoperability Requirements
FEP195
Implementations of the CM air and ground application entities shall comply
with the interoperability requirements applicable to the CM-logon, CMcontact, CM-update, CM-end, CM-user-abort and CM-provider-abort services
specified in ED-110B [10] chapter 3.1, except where indicated otherwise in
this specification.
FEP196
The CM-update service will not be requested by the LGS systems nor shall be
triggered by the Datalink FEP.
Note 1: Minimal ground system support requirements for handling received CMupdate primitives are given in ED-110B [10] Note after paragraph 3.1.3.3.1.1.1.
Note 2: The CM-forward service is outside the scope of this specification.
E.12
ATN Upper Layer Communications Service
Requirements
E.12.1
Specific Interoperability Requirements
FEP197
ULCS implementations shall conform to the requirements of ED-110B [10]
(which refers to ICAO Doc. 9705, Sub-Volume IV), except where indicated
otherwise in this specification.
FEP198
Where ICAO Doc 9880 [6] specifies the base standard for the ATN session
protocol, the phrase “together with all approved amendments and defect
report resolutions” shall be taken to mean “including Technical Corrigendum 1
(2002)”.
FEP199
Implementations of the ATN session protocol shall be capable of supporting
the session protocol data units (SPDUs) listed in Table B-2, any other SPDUs
being out of scope of this specification:
Table B-2: SPDU Support Requirements
Value
(Hex)
E8
F0
Abbreviation
Full SPDU Name
SCN
SAC
Short Connect
Short Accept
P a g e | 49
Commercial In Confidence - Borealis Alliance
Issue 1.0
D8
E0 – E3
SACC
SRF
A0
SRFC
Short Accept Continue
Short Refuse
E0: TC retained, transient refusal
E1: TC retained, persistent refusal
E2: TC released, transient refusal
E3: TC released, persistent refusal
Short Refuse Continue
FEP200
It is recommended that the value “E3” should be used for encoding the SRF
SPDU.
FEP201
Where ICAO Doc 9880 [6] specifies the base standard for the ATN
presentation protocol, the phrase “together with all approved amendments
and defect report resolutions” shall be ignored.
FEP202
Implementations of the ATN presentation protocol shall be capable of
supporting the presentation protocol data units (PPDUs) listed in Table B-3,
any other PPDUs being out of scope of this specification:
Table B-3: PPDU Support Requirements
Value (Hex)
02
02
x2
Abbreviation
SHORT-CP
SHORT-CPA
SHORT-CPR
Full PPDU Name
Short Presentation Connect, unaligned PER
Short Presentation Connect Accept, unaligned PER
Short Presentation Connect Reject, where x = reason
code:
02: presentation-user
12: reason not specified (transient)
22: temporary congestion (transient)
32: local limit exceeded (transient)
42: called presentation address unknown (permanent)
52: protocol version not supported (permanent)
62: default context not supported (permanent)
72: user data not readable (permanent)
FEP203
The value “02” shall be used for encoding the SHORT-CPR PPDU.
FEP204
In addition to the ICAO Doc 9880 [6] updates specified in ED-110B [10],
ULCS implementations shall additionally incorporate all defect resolutions
listed in Table B-4.
Table B-4
PDR ref
PDR Description (Ed 2)
M00400
02
Potential Misdelivery of CLNP
Packets (32 bit checksum)
Applies
To
All End
Systems
Notes
Support is Mandatory in ED110B
[9] section 2.4. However, 32-bit
checksum is not required
E.13
ATN Internet Communications Service requirements
E.13.1
Specific Interoperability Requirements
FEP205
ICS implementations shall conform to the requirements of ED-110B [10]
except where indicated otherwise in this specification.
FEP206
ATN end systems shall implement the TP4 protocol as specified in Doc 9880
[6], section 5.5.2.
P a g e | 50
Commercial In Confidence - Borealis Alliance
Issue 1.0
Note: The connectionless transport protocol (CLTP) is outside the scope of
this specification.
FEP207
In addition to the ICAO Doc 9705 [6] updates specified in ED-110B [10]
chapter 2.4, ICS implementations shall incorporate all defect resolutions
listed in Table B-5.
Table B-5 Modifications to ICAO Doc 9705 - ICS
PDR ref
99090001
99100003
99100004
99100005
PDR Description (Ed 2)
ICS: Over-specification of ARS
Address
ICS: LREF Compression and
CLNP
ECHO NPDUs
Applies To
All Systems
ICS: ISO/IEC 8208 NonStandard
Default Packet Size Facility
ICS: Reservation of
Unassigned/Undefined Values
All ATN
Routers
Air and AirGround Router
All Systems
M0040001 ICS: Incorrect/Duplicated ATSC
Class Security Tag
M0040002 Potential Misdelivery of CLNP
Packets (32 bit checksum)
All ATN
Routers
All End
Systems
M4050001 ICS: Typos and inconsistencies
in
the Doc. 9705 Sub-Volume V
M5020001 ICS: Inclusion of ATN IP
SNDCF
All Systems
Air-Ground
and
GroundGround
Routers
Notes
Needed for ARINC network
compatibility.
Used for compression of
NSAP
addresses
Relaxation of requirement.
No
interoperability implications.
Only impact of this PDR
could be
on implementations that
used
private values.
Clarifies an error condition
Support is Mandatory in
ED-110B
[9] section 2.4. However,
32-bit
checksum is not required
When IP networks are used
for
the ATN ground-ground
segment.
E.13.2
Specific Performance Requirements
FEP208
The TP4 parameter settings listed in Table B-6 should be implemented by all
ground ATN End Systems.
Table B-6: Recommended TP4 parameter settings
PDR ref
99090001
99100003
99100004
99100005
PDR Description (Ed 2)
ICS: Over-specification of ARS
Address
ICS: LREF Compression and
CLNP
ECHO NPDUs
Applies To
All Systems
ICS: ISO/IEC 8208 Non-Standard
Default Packet Size Facility
ICS: Reservation of
Unassigned/Undefined Values
All ATN
Routers
All Systems
Air and AirGround Router
P a g e | 51
Commercial In Confidence - Borealis Alliance
Notes
Needed for ARINC network
compatibility.
Used for compression of
NSAP
addresses
Relaxation of requirement. No
interoperability implications.
Only impact of this PDR could
be
on implementations that used
private values.
Issue 1.0
M0040001
M0040002
M4050001
M5020001
FEP209
ICS: Incorrect/Duplicated ATSC
Class Security Tag
Potential Misdelivery of CLNP
Packets (32 bit checksum)
All ATN
Routers
All End
Systems
ICS: Typos and inconsistencies in
the Doc. 9705 Sub-Volume V
ICS: Inclusion of ATN IP SNDCF
All Systems
Air-Ground and
Ground-Ground
Routers
Clarifies an error condition
Support is Mandatory in ED110B
[9] section 2.4. However, 32bit
checksum is not required
When IP networks are used for
the
ATN
ground-ground
segment.
The IDRP parameter settings listed in Table B-7 shall be implemented by all
ATN Routers
Table B-7: Recommended IDRP parameter settings
Entity
Timer
Recommended Value
IDRP (Airborne Router)
IDRP Hold time
900 sec
IDRP (Air-Ground Router)
IDRP Hold time
900 sec
IDRP (Ground-Ground
Router)
IDRP Hold time
90 sec
E.14
Ground Recording Requirements
FEP210
Data link messages exchanged between an ATS Unit and aircraft shall be
recorded according to the functional specifications for ground recording as
published in EUROCAE Document ED-111 [13].
E.15
Naming and Addressing Requirements
FEP211
Ground ATC entities shall be identified by an ICAO Facility Designator and the
corresponding CM TSEL value.
E.16
Conformity Assessment Requirements
FEP212
The Datalink FEP vendor shall support the completion of the PICS/OICS for
CM and CPDLC as contained in ED-110B, [10] Annex B, where applicable to
the FEP.
FEP213
Unless specified to the contrary in the specification above, the
implementation shall comply with the relevant Profile Requirements Lists for
the ATN ULCS and ICS in Doc 9880 [6].
P a g e | 52
Commercial In Confidence - Borealis Alliance
Issue 1.0
APPENDIX F Glossary and Acronym List
ACARS
Aircraft Communications Addressing and Reporting System
ACC
Area Control Centre
ACL
ATC Clearance (CPDLC service)
ACM
ATC Communications Management (CPDLC service)
ADA
Asset Design Authority
ADS-C
Automatic Data Surveillance – Contract (FANS service)
AGDL
Air Ground Datalink
AMC
ATC stuck microphone check (CPDLC service)
ANSP
Air Navigation Service Provider
AOC
Airline Operational Communications
ARINC
Aeronautical Radio Inc
ATN
Aeronautical Telecommunications Network
ATSU
Air Traffic Service Unit
CM
Context Management
CPDLC
Controller Pilot Datalink Communications
CSC
Common Signalling Channel
CSP
Communications Service Provider (ARINC and SITA)
CWP
Controller Working Position
DLIC
Datalink Initiation Capability
DOC
Designated Operational Coverage
FABEC
Functional Airspace Block – Europe Centre
FANS
Future Air Navigation Services
FEP
Front End Processor
FMC
Flight Management Computer
LAM
Logical Acknowledgment Message (OLDI)
Link2000+
Eurocontrol Datalink project
MUACC
Maastricht Upper Area Control Centre
OLDI
On-Line Data Interchange
POA
Plain Old ACARS
SARPs
Standards And Recommended Practices (ICAO)
SITA
Société Internationale de Télécommunications Aéronautiques
SLA
Service Level Agreement
VCRI
Verification Cross Reference Index
VDL2
VHF Datalink mode 2
VDR
VHF Data Radio
P a g e | 53
Commercial In Confidence - Borealis Alliance