Current Issues
The list below contains a description of the main issues with the datalink services, in no particular order. References to the associated tickets in the problem reporting tool are included, but please note the access to some tickets is restricted to protect confidentiality. Some issues that have appeared on this page in the past have now been addressed and so have been moved to a separate page.
Provider Aborts
Provider Aborts (PAs) are a major concern. They occur when there is a sustained loss of end-to-end connectivity. The problems causing the loss of connectivity may arise anywhere within CPDLC; the ATN and VDL Mode 2. There is no single cause for all PAs. Provider Aborts have been occuring for several years and over that time a number of problems have been identified and fixed. The aircraft avionics are a major source of PAs, with problems currently being observed with aircraft fitted with Thales EVR750 VDRs, Spectralux Dlink+, Honeywell RTA44D VDR, Honeywell EPIC avionics and Rockwell Collins VDRs (920, 2100, 4000) that have not been updated to address the 'VDR deafness' problem. The phenomenon known as 'VDR Deafness' is where the aircraft continues to downlink messages normally but fails to recognise uplinks and is a major cause of PAs (it accounts for approx. 70% of PAs suffered by aircraft fitted with these RC VDRs) and although a fix is now available it is still not widely deployed. Updates to the other avionics mentioned are being developed. The avionics are not the only element of the system which cause PAs and a number of problems have also been noted with the communications infrastructure and the ground systems.
A number of ad-hoc meetings were held in 2013/2014 to develop and execute a PA action plan, but following a review of the status of the DLS IR by the European Commission the main thrust of investigations into the PA problem is now being conducted under the ELSA project of the SESAR Joint Undertaking.
 A Provider Abort |
 Provider Abort History |
More up to date statistics for the PA rate are on the performance monitoring pages.
Inappropriate display of instructions to turn right/left
It has been observed that the HMI of some avionics always display three digits for the UM215 message to turn right or left by a specified number of degrees, rather than omitting the leading zeroes where appropriate. For example, an instruction to TURN RIGHT 30 DEGREES results in a display of TURN RIGHT 030 DEGREES, which can cause the flight crew to interpret this as a an instruction to turn right to heading 030. ICAO Doc 4444 (section 12.4.1) when defining ATC phraseology for vectoring instructions specifies that three digits are always used to describe a heading (giving an absolute value of the heading to fly) and one,two,or three digits is used as appropriate to describe a number of degrees to turn. There have been two cases of this reported at MUAC during 2012, both of which were detected due to the voice read-back which was in place at that time, but as that has been removed as from the 15th November 2012 the CRO has decided that it is necessary to take preventive action.
Recommendation Unless additional system-supported mitigations can be deployed the CRO recommends ANSPs to inhibit UM215 until sufficient evidence of correct display in all aircraft installations is available.
Inaccurate ATC Center NSAP addresses on board LINK2000+ equipped aircraft
Many LINK2000+ aircraft NSAP addressing database have not been updated according to the latest EUR NSAP Address Registry (Version 2.0 dated 04-2012) published by the ICAO AFSG Planning Group. Most aircraft databases are still compliant to EUR NSAP Address Registry Version 1.0 dated 04-2011, where NSAP addresses for Swiss ATC Centers and NSAP addresses for Spanish ATC centers are not accurate as some major changes were introduced in summer 2011. With the out-dated databases, manual Logon addressed to any Swiss ATC center or any Spanish ATC center will not reach the target End-System in the LINK2000+ ATN deployed infrastructure.
The main impact of this discrepancy is for Skyguide ANSP who have been operational with CPDLC since since early 2013.
Possible Workaround
One possibility in order to get up-dated NSAP addresses dynamically uploaded on board an aircraft is to address CM-CONTACT requests to the CPDLC/ATN avionics equipment. For some avionics, the dynamically uploaded addresses will be lost after reset of the equipment; this is typically the case for the Airbus ATSU FANS-B+.
A CM-CONTACT request can be invoked in the context of operational centre to centre transfers or via a dedicated CM application tool in the context of Interoperability Testing with equipped aircraft (blind CM-CONTACT).
Note: The blind CM-CONTACT option above mentioned in the context of Interoperability Testing, requires: 1- owning a dedicated CM application tool capable to generate CM-CONTACT requests – to upload Ground Facility Designators and CM applications addresses on board, 2- prior registration of each aircraft CM application address (NSAP/TSEL) in the addressing database of the ground tool 3- for some avionics, CM-CONTACT request to be issued after each avionics equipment reset.
Situation with Airbus ATSU FANS-B+ equipped Aircraft
Airbus have released early November 2012 a database which is compliant to the latest version of the EUR NSAP Address Registry (Version 2.0 dated 04-2012); the Service Information Letter has been published. Airlines are strongly recommended to update their aircraft database to the latest Airbus released database.
Situation with Rockwell Collins CMU equipped Aircraft
Rockwell Collins have confirmed that initial versions of their CMU addressing database are compliant to Version 1.0 of the EUR NSAP Address Registry dated 04-2011. The address values listed in the Registry changed subsequent to V1.0. The Rockwell Collins database was updated with the new address values in late 2012 and the subsequent released versions of software include that database. Please contact Rockwell Collins with any questions regarding the status of a particular version of software.
For those with versions of software that have the obsolete address values, a procedure has been defined to manually configure the CMU. Please contact either Rockwell Collins or the link cro if you would like a copy of this procedure
Situation with Honeywell Mark2 Plus CMU equipped Aircraft
Honeywell have released in August 2012 a database which is compliant to the latest version of the EUR NSAP Address Registry (Version 2.0 dated 04-2012). Airlines are strongly recommended to update their aircraft database to the latest Honeywell released database.
VDL Uplink failures leading to Provider Aborts
An analysis of provider aborts suffered by aircraft fitted with the VDR deafness upgrade in the period between 1st June and 14th July 2013 has shown that a significant factor in approximately 50% of these PAs was a prolonged failure of the VDL uplink. The precise reason for this is not yet known. Refer to CRO-335.
VDL8208 SVC Clearing leading to Provider Aborts
An analysis of provider aborts suffered by aircraft fitted with the VDR deafness upgrade in the period between 1st June and 14th July 2013 has shown that a significant factor in approximately 50% of these PAs was the ground clearing the SVC. The precise reason for this is not yet known. Refer to CRO-334.
Network performance - Technical round trip delay
The technical round trip delay has been observed to be increasing steadily over the majority of 2013 and the 95% value has been above the 16 seconds requirement for RCTP given in ED-120 since that time. Refer to 317.
Embraer/EPIC avionics performance
Aircraft fitted with the Honeywell EPIC avionics suffer a significantly higher technical round trip delay than other aircraft and are observed to be suffering from an increasing PA rate during 2013. The data is only currently available for Embraer aircraft fitted with the EPIC avionics so it possible that the problem may be with this specific configuration. Refer to CRO-282 and 316.
Inappropriate forwarding of IDRP routes to aircraft
Due to some aircraft with pioneer avionics and configured for dual ACSP still operating , some IDRP routes that the aircraft have provided to the SITA router have been inappropriately forwarded to all SITA aircraft creating some IDRP bursts over the link. A work around has been put in place to prevent the aircraft involved connecting at the ATN level but IDRP policy rules need to be updated on the ATN router; this is currently (Nov 2013) being tested. Refer to CRO-258.
Processing of DM22 messages
There is some inconsistency in how DM22 messages are supported by different ANSPs. Only MUAC and Skyguide support DM22 with lat/long (DFS and NATS do not) and DFS does not support DM22 messages involving a request direct to a navaid (the message is rejected). Refer to CRO-177 and 332.
NDA and DLIC-Contact Message Order
When performing a transfer of communications between ATSUs ED110B requires a DLIC-contact request to be initiated before an UM160 NDA is uplinked. However in some cases the aircraft may have received a CPDLC-start-request from the receiving ATSU before it has received the NDA message from the transferring ATSU. This results in a rejection of the CPDLC-start-request and the downlinking of DM107 NOT AUTHORIZED NEXT DATA AUTHORITY to the receiving ATSU. To avoid such race conditions the UM160 NDA must be sent (by the transferring ATSU) before the DLIC-contact request. Refer to CRO-161.
FANS CSP Identification
At initial logon (AFN-contact), an indication of the CSP is provided. Upon transfer of the flight to the next ATSU, the LOF message is used. Since the LOF message does not indicate which CSP delivered the Logon (AFN-Contact) message, the R-ATSU has no way of knowing to which CSP address the CPDLC-Start should be sent. This dilemma could be resolved by including an additional field in the LOF for FANS aircraft to indicate which CSP delivered the Logon. Refer to CRO-160.
FANS B+ ATSU Issues
There are a number of problems related to the FANSB+ ATSU, primarily related to mulitfrequency operations. Refer to CRO-68 to 74. A new version of the Airbus ATSU (version CSB8.3) is now available which addressed the issues and is known to perform much better than previous versions.
Airbus handling of CDA messages
Airbus aircraft consider CPDLC connection to be established once they have received the LACK of DM99 (CDA). If the LACK is received more than 40 seconds after having been sent it is discarded by the aircraft and the connection is not considered established. However the ground system has sent the LACK and consider the connection as established. Therefore when an uplink requiring an answer, such as UM 160 (NDA) or any other UM requiring an answer, is received on board it is answered by DM 63 (not CDA). In this case the CPDLC connection needs to be re-established. Refer to CR0-221.
UnrecognizedMsgReferenceNumber error messages received in response to a seemingly valid message
There have been a number of cases where an error message ‘unrecognizedMsgReferenceNumber’ has been received in response to a message where the message reference number sent is valid. This can occur for both messages sent by the ground system and messages sent by the aircraft system, but for different reasons.
Some ground implementations allow the controller to cancel an open dialogue via their HMI. When the controller cancels an open dialogue the ground system loses the context of the dialogue, so if the aircraft system responds to the ground initiated dialogue which the controller has cancelled the ground system does not recognise the message reference number sent in the downlink response and hence uplinks the error message (CRO-529 refers). This seems incorrect when viewed from the perspective of the aircraft because it is unaware that the dialogue has been cancelled in the ground system. The ability to allow a controller to cancel an open dialogue, if used inappropriately, can also allow the uplink of a second instruction of the same type before the first instruction dialogue is closed (from an aircraft perspective) e.g. the controller uplinks a 'DIRECT TO' type instruction, cancels it on their HMI before the aircraft responds, then sends a different 'DIRECT TO' instruction (CRO-481 refers).
Some aircraft implementations consider a downlink request as failed if a LACK is not received by the aircraft before the ‘tr’ timer expires (40secs). In such a scenario if the aircraft receives a subsequent response from the ground system referring to the downlinked request which has timed out, the aircraft system does not recognise the message referenced and so downlinks the error message (CRO-549 refers). This seems incorrect from the ground perspective because it does not know the aircraft has timed out the request