Data Communications Implementation Team (DCIT)

1. Data Communications Implementation Team (DCIT) Relogon and Abnormal Terminations 4/16/2014 ARINC – Annapolis, MD

2. Topics • AFN Relogon • TDLS handling of abnormal connection termination

3. AFN Relogon

4. AFN Relogon Scenario • Aircraft performs AFN logon with CMAP • TDLS creates CPDLC session with aircraft for delivery of Initial DCL • Initial DCL is sent and open (pending) • Aircraft performs second AFN logon with CMAP • Callsign, Registration Number, and Departure Airport remain the same • ERAM informs TDLS of AFN relogon via use of the ReLogon Indicator in a DU/Update message • What action should TDLS take?

5. AFN Relogon Solution Close Transaction, Terminate Session • Close open transaction • Display 'e' on GUI • Start new CPDLC session immediately after termination of first completes Pros • No ops disconnect between controller and pilot regarding CPDLC messages • Transaction and session management logic is kept simple • Handles all cases of why the AFN logon may be performed • No deviation from DO-258A • Same solution applied for both TDLS and En Route Cons • Session termination not expected; potential pilot training impacts • Impact to data authority processing for ATCComm not addressed • But…pilot should not perform AFN logon with current connection

6. AFN Relogon SolutionMessage Sequence Chart

7. AFN RelogonS1P1/S1P2 Behavior Summary • DO-258A 5.1.4.3 indicates that the AFN relogon should be treated as a failure recovery scenario • As such, the design should focus on the failure recovery scenario yet address non-failure recovery anomalies • The current design choice does both • Ground system logic is simple; no exception cases necessary • Tower Controller GUI is consistent (‘e’ displayed prior to callsign) in that voice coordination should occur when AFN logon is performed with an open transaction • En Route Controller GUI is TBD • Ensures context is maintained consistent between ground system and aircraft concerning state of open transaction and CPDLC session • Transaction lifetime bounded by lifetime of CPDLC session in which it is created • No DO-258A deviation necessary

8. Abnormal Connection Termination

9. CPDLC Connection Termination • TDLS design supports the use of DR1 in the uplink direction to abnormally terminate CPDLC sessions • But, some aircraft ignore the receipt of a received DR1 • Following slides will address how the TDLS design provides 2 session termination options • CPDLC-end request (AT1 + UM161 [+ UM159]) • CPDLC-user-abort request (DR1)

10. Use of CPDLC-end request • CPDLC-end request is used whenever it is possible to construct the PER-encoded CPDLC message • Includes abnormal termination reasons as well as normal • Pilot response not permissible (e.g., ROGER instead of WILCO) • Invalid message content (e.g., not a DM73 in CC1, unsupported version) • PER-decoding errors (because all checksums said the message was valid prior to attempting to decode) • CPDLC-end request uses the AT1 IMI to uplink UM161 END SERVICE with optional appended UM159 • Use of UM161+UM159 invokes abnormal connection termination in avionics • Session is terminated after receipt of downlink DR1 (CPDLC-end confirmation)

11. Use of CPDLC-user-abort request (1 of 2) • CPDLC-user-abort request is available to handle application-level protocol errors and cleanup duties • These are expected to be very rare events • Every occurrence requires subsequent post-mortem activities to determine why the situation occurred • CPDLC-user-abort request is used as a last resort only • TDLS sends the uplink DR1 for the benefit of those aircraft that can process it to inform the aircraft that the ground system no longer has a session • No harm assumed for aircraft that do not process uplink DR1s

12. Use of CPDLC-user-abort request (2 of 2) • Examples of when CPDLC-user-abort request is used • Session termination after timeout waiting for downlink DR1 to uplink UM161 • Invalid state-event combinations for finite state machine processing • Local implementation failures (e.g., interprocesscommunication errors)

13. Summary of CPDLC Connection Terminations • TDLS uses CPDLC-end request for normal connection terminations • TDLS uses CPDLC-end request for some abnormal connection terminations • TDLS uses CPDLC-user-abort request as a last resort action only when the application protocol fails • TDLS uses the CPDLC-user-abort request when local implementation failures occur • The use of DR1 in the uplink direction should be a very rare occurrence

14. Backup Slides

15. AFN Relogon Alternatives Assessment • TDLS considered multiple design options to address the guidance conflict in DO-258A • Section 4.6.2.1.2 recommends that ATCComm maintain pending messages across connections • Section 5.1.4.3 recommends that ATS Provider systems treat an AFN relogon as a failure recovery mechanism and consider pending messages as failed • Both sections are applicable in the end-to-end chain for this scenario • TDLS identified 4 design options and chose the current approach as the best overall solution • Significant driving factor was minimizing the potential for an operational disconnect between controller and pilot concerning the status of pending messages prior to the AFN relogon

16. AFN Relogon Design Options  Option 1 – Close Transaction, Terminate Session (Current Design) • Close open transaction • Display ‘e’ on GUI • Terminate CPDLC session • Start new CPDLC session when have new clearance to deliver • CDR: Start new CPDLC session immediately after termination of first completes Pros • No ops disconnect between controller and pilot regarding CPDLC messages • TDLS transaction and session management logic is kept simple • Handles all cases of why the AFN logon may be performed • No deviation from DO-258A (may be questionable) Cons • Session termination not expected; potential pilot training impacts Option 2 – Replace Session, Resend Clearance/New Transaction • Put open transaction into ‘limbo’ state • No change on GUI • Replace existing CPDLC session • Send new CR1, receive new CC1 • Send ‘limbo’ transaction as new transaction on new CPDLC session Pros • If avionics lost first CPDLC session, no ops disconnect between controller and pilot • Treats open transaction as ‘failed’; no deviation from DO-258A Cons • If avionics maintained first CPDLC session, avionics will have the first pending uplink message; pilot response will result in unrecognized message reference number error condition Option 3 – Keep Transaction, Replace Session • Keep open transaction • Will Timeout on GUI if avionics lost the first CPDLC session • May receive pilot response if first CPDLC session was not lost • Replace existing CPDLC session • Send new CR1, receive new CC1 Pros • No ops disconnect between controller and pilot; reuse existing Timeout controller procedures Cons • Deviation required for DO-258A, section 5.1.4.3 that recommends that the ATS Provider treat pending messages as failed • Increased TDLS complexity to “replace” CPDLC session and “move” transaction from first CPDLC session to second CPDLC session Option 4 – Close Transaction, Replace Session • Close open transaction • Display ‘e’ on GUI • Replace existing CPDLC session • Send new CR1, receive new CC1 Pros • Compliant with expected operation per DO-258A section 5.1.4.3 • If avionics lost first CPDLC session, no ops disconnect between controller and pilot • Treats open transaction as ‘failed’; no deviation from DO-258A Cons • If avionics maintained first CPDLC session, avionics will have the first pending uplink message; pilot response will result in unrecognized message reference number error condition

17. AFN Relogon Option 3 Message Sequence Chart