Notification and CPDLC Connection — AFN and Connect
Article 1 set the datalink assembly line: notify (crew) → connect (controller) → communicate (CPDLC). This article covers the first two steps — AFN notification and CPDLC connection — the handshake that puts the aircraft in touch with an ATC centre by datalink. CPDLC communication (article 3) cannot begin until this handshake is made; get it wrong (e.g. a mistyped flight number) and nothing downstream works.
By the end you should be able to say when and where notification is sent, why the flight number must match the ICAO flight plan exactly, what active and next ATC centres are, and why DCL/OCL/D-ATIS need no notification.
1. Notification (AFN) — 15 to 45 minutes before the area
Notification is the first handshake step. Per FCOM DSC-46-10-30-10:
The Notification application enables the flight crew to send a notification message to an ATC center, if the datalink system is correctly initialized. [...] The flight crew must notify the ATC center, from 15 min to 45 min, before entering the ATC area. The flight crew notifies a desired ATC center via the NOTIFICATION page of the MCDU.
Notification lets ATC correlate the aircraft with its ICAO flight number — and here lies the commonest pitfall. Per FCOM DSC-46-10-30-10:
The notification procedure enables the ATC to correlate the aircraft with the ICAO flight number. [...] Consequently, it is essential to enter, into the FMGEC, via the INIT page of the MCDU, the same flight number as the flight number, indicated on the ICAO flight plan (with the same number of letters).
[!warning]- One wrong letter in the flight number, and the datalink "does not correlate" The flight number the FMGEC provides is the key by which the ATC ground system claims your aircraft. If it differs from the ICAO flight plan by a single character (an extra/missing letter, a different leading zero), ATC cannot correlate, notification fails, and the connection is never built. This is the commonest root cause of "I sent notification but cannot connect". When entering the flight number on the MCDU INIT page, check it character by character against the ICAO plan — the first discipline of the datalink handshake.
2. Notification triggers the connection
After notification is sent, the rest is automatic. Per FCOM DSC-46-10-30-10:
Note: The ATC center initiates a CPDLC connection, when the flight crew sends the notification. The NOTIFICATION page of the MCDU will display XXXX NOTIFIED HHMM Z. Therefore, it is not necessary to repeat notifications to the ATC center.
XXXX NOTIFIED HHMM Z (XXXX = centre code, HHMM Z = time) means the notification succeeded — do not re-send. And ATC centres notify each other automatically across areas, so the crew need not notify each area by hand.
3. CPDLC connection — active and next centres
The second handshake step is done by the controller. Per FCOM DSC-46-10-30-20:
The notified ATC center can initiate a CPDLC connection with the aircraft. This ATC center is then considered as active. The active ATC center appears on the DCDU, and on the MCDU, in the active ATC field of the CONNECTION STATUS page. Only one ATC center can be active at a time.
The automatic cross-boundary handover. Per FCOM DSC-46-10-30-20:
The next ATC center may initiate a passive connection with the aircraft, when the aircraft is still connected to the active ATC. [...] When the ATC area changes, the active ATC center ends the connection with the aircraft, and the next ATC center automatically becomes the active ATC center.
[!note]- One active, one on deck, seamless handover Picture a relay baton: only one baton is in hand at a time (active — the centre you now converse with), and the next centre reaches out early (next — a passive stand-by). Fly out of the area, the active centre lets go, the stand-by automatically takes the baton and becomes active — transparent to the crew. The CONNECTION STATUS page (MCDU) shows the ICAO codes of the active and next centres; the crew can also disconnect manually there. Why only one active? CPDLC is "talking to the controller currently working you" — two at once would be chaos.
4. Optional applications need no notification — DCL / OCL / D-ATIS
Not every datalink application uses the notify–connect handshake. Per FCOM DSC-46-10-30-10:
Optional datalink applications (Departure CLearance (DCL), Oceanic CLearance (OCL) and D-ATIS do not require previous notifications, or connection to an ATC center. Optional datalink applications are based on voice exchanges: 1. Request - crew requests; 2. Clearance - ground clears; 3. Read-back - crew reads back; 4. Confirmation - ground confirms.
[!note]- Two classes: CPDLC handshakes, ARINC 623 does not CPDLC / ADS-C (FANS A) require the "notify → connect" handshake — they are a sustained session with a centre; DCL / OCL / D-ATIS (ATS 623) are a one-shot "request → clearance → read-back → confirmation" — like sending a text to look something up, no persistent connection. Article 6 covers those three; the "does it handshake?" test separates the two classes.
Self-test
[!note]- Q1. When is notification (AFN) sent, on which page, and why must the flight number match the ICAO plan exactly? 15 to 45 minutes before entering the ATC area, via the MCDU NOTIFICATION page. The flight number is the correlation key — a single mismatch and ATC cannot correlate, so notification/connection fails.
[!note]- Q2. What is the success indication (MCDU display), and must each area be notified by hand?
XXXX NOTIFIED HHMM Z. No — ATC centres notify each other automatically across areas.
[!note]- Q3. What are active and next ATC centres, why only one active, and how is the boundary handover done? Active = the centre you converse with (only one); next = a passive stand-by. At the boundary the active ends and the next automatically becomes active.
[!note]- Q4. Why do DCL/OCL/D-ATIS need no notification or connection, and what exchange model do they use? They are a one-shot ATS 623 request–clearance–read-back–confirmation, not a sustained connection.
Key takeaways
| Point | Detail |
|---|---|
| Notify first | 15–45 min before the area, MCDU NOTIFICATION; flight number = ICAO plan, exactly |
| Success | XXXX NOTIFIED HHMM Z; do not re-send; cross-area is automatic |
| Active/next | One active centre; next is passive; boundary handover is automatic |
| Two classes | CPDLC/ADS-C handshake; DCL/OCL/D-ATIS (ATS 623) do not |
References
- FCOM DSC-46-10-30-10 — notification timing (15–45 min), NOTIFICATION page, flight-number correlation, XXXX NOTIFIED, optional apps need no notification.
- FCOM DSC-46-10-30-20 — CPDLC connection, active/next centres, only one active, automatic boundary handover, CONNECTION STATUS page.
Independent study material, not an Airbus publication and not endorsed by the manufacturer. Always defer to the current operator FCOM, FCTM, and QRH for operational use.