LACKs are a capability of CPDLC (Controller Pilot Data Link Communications) as implemented via the ATN (Aeronautical Telecommunication Network). The purpose of a LACK is to let the operational users (controllers and pilots) know whether a specific data link message has been received at the other end of the communications network. The LACK capability utilizes the automation to deliver a confirmatory message back to the sender. This confirmatory message can then trigger either a positive indication of the receipt of each message or an alert (after a timer has expired) that the message has not been delivered.

As per the ICAO ATN SARPs (Standards and Recommended Practices), when CPDLC is used for ATS communications, the use of LACKs is optional and is left to the States to decide whether or not to use LACKs in their CPDLC systems. A brief explanation and history of CPDLC will be necessary in order to understand the need for LACKs.

When the ODIAC-TF (Operational Development of Initial Air/ground data Communications – Task Force) developed the requirements for ATS data link, the controllers and pilots in that group were adamant that they needed to know whether or not a particular message had been successfully delivered. Please note that this indication does not imply whether the receiver has actually read the message, only whether the message is fully processed, decoded, and possible to be read by the receiver.

The United States FAA took a slightly different approach in the development of its data link program. Instead of utilizing a confirmatory message (and paying the service provider for this message), it was decided that if the data link system could provide an error indication in all cases when the message did not successfully reach the recipient then there was no need to send the LACK message.

As we get closer to the actual implementation of ATN CPDLC, a more complete picture has emerged of just how this system will work. Because several cases are now known in which the data link system does not successfully deliver the message AND does not provide an error indication to the sender, it now appears that the ODIAC was correct in mandating the use of LACKs. Two of those error situations are discussed below, and it is probable that similar situations will be discovered during or after implementation.

The first situation involves messages that arrive in a different sequence than the order in which they were sent (out-of-sequence). When the ICAO ADS (Automatic Dependent Surveillance) Panel wrote the operation requirements for ATS data link, there were two requirements regarding out-of-sequence messages. These requirements are; (1) that messages must be received in the order in which they were sent, and (2) that if an out-of-sequence situation does occur that the messages are delivered to the recipient along with an indication of the error. The ICAO ATN Panel (which developed the technical standards for the ATN) opted to meet the first requirement and to disregard the second. They met the first requirement in a way other than what was envisioned by the ADS Panel. In an out-of-sequence situation, the automation system will not deliver the out-of-sequence messages, and if the missing message(s) do not appear then all the messages are discarded and the communications link is severed. Unfortunately, this situation in which the system is holding messages undelivered can last for up to six minutes and during that time there is no error indication delivered back to the sender indicating that the messages have not been delivered. Likewise, during this time period the receiver has no indication that there are messages awaiting delivery. The use of LACKs in this situation would provide a timely indication to the sender that a message (or messages) had not been delivered to the recipient.

We see that there are at least two situations present within the ATN CPDLC SARPs in which the use of LACKs is necessary to have the system perform in an operationally acceptable way. These situations were uncovered even before any operational implementation of ATN CPDLC, so that it is quite likely that there will be other similar situations.

These situations, in addition to the ODIAC Operational Requirements, show that the operational users of the system (i.e., controllers and pilots) need to clearly indicate to system implementers that the use of LACKs should not be considered optional and are in fact mandatory in any implementation of ATS CPDLC.

“When Air Traffic Services are provided via Aeronautical Telecommunications Network (ATN) Controller Pilot Data Link Communications ( CPDLC), the use of LACKs (Logical Acknowledgments) shall be considered mandatory.

When Air Traffic Services are provided via any CPDLC other than ATN, a capability which meets the Operational Requirements for LACKs shall be considered mandatory.”

Error message with the use of L-ACK (Logical Acknowledgement)

• Controller uplinks CPDLC Clearance, example “CLIMB TO LEVEL 310.”
• Aircraft avionics responds automatically with a L-ACK when the message is successfully decoded and available for display to the aircrew.
• Aircrew responds to Clearance with a reply of “UNABLE.” A technical error occurs somewhere during the transmission and the response is not delivered to the controller.
• Aircraft avionics is still waiting for L-ACK from the ground that the downlinked “UNABLE” was received and decoded.
• When the error occurred to the downlink, the system automatically sent an error notification back to the aircraft avionics. Because the avionics were still waiting for the L-ACK (4), the error notification was correctly paired to the original “UNABLE” downlink and the aircrew was notified that the specific message was not delivered to the controller. The aircrew is consequently able to take appropriate action via the voice radio and notify the controller that they are not executing the climb Clearance.

Attachment B to WP 87

Error message without the use of L-ACK (Logical Acknowledgement)

• Controller uplinks CPDLC Clearance to aircraft, example “CLIMB TO LEVEL 310.” Note that because L-ACKs are not in use, the ground system expects only the operational reply from the aircrew.
• Aircrew responds to Clearance with a reply of “UNABLE.” A technical error occurs somewhere during the transmission and the response is not delivered to the controller.
• When the error occurred to the downlink, the system automatically sent an ERROR notification back to the aircraft avionics. Because the avionics is not waiting for a L-ACK response, the downlink message of “UNABLE” is considered a Closed Transaction as soon as it is sent. Consequently, when the ERROR message is delivered back to the avionics, it cannot be paired to the downlink message and the aircrew is informed only that an error occurred without identifying to which message the ERROR is associated.
• If there are several pending downlinks, the aircrew must spend time trying to analyze which one might be associated with the ERROR, during which time the controller is unaware that the aircraft is not complying with the climb Clearance. Then the aircrew must use the voice radio to discuss the unassociated ERROR with the controller and determine the appropriate course of action. Valuable R/T and control time is spent simply because L-ACKs were not implemented in the CPDLC system.