Transfer of CPDLC

[Richard McDonald Woods]

Quote from Skybrary.aero for European flights:

"If an aircraft is transferred from an ATS unit where CPDLC is not available to an ATS unit where CPDLC is available, the aircraft uses DLIC to log on to the unit that is CPDLC equipped. The procedures and timings are detailed in the respective AIP.

If both adjacent ATS units are using CPDLC the transfer of voice communications and CPDLC commences concurrently. The transferring unit being the Current data authority (CDA) designates the receiving unit as Next data authority (NDA). The purpose of this designation is to reduce the possibility of logging on to an improper data authority (which is equivalent to switching to the wrong radio frequency in voice communications).

If an aircraft is transferred from an ATS unit where CPDLC is available to an ATS unit where CPDLC is not available, CPDLC termination commences concurrent with the transfer of voice communications."

Are VATSIM planning to allow automatic transfer of CPDLC control from the transferring ATS unit to the receiving unit where both are available?

I can see the difficulties where one unit is not available. Also, there may be multiple possibilities of receiving unit depending on the direction of flight. 

Would a partial solution be possible for SimBrief to provide FPs with receiving units embedded?  Without such a solution, European flights may gain little from a CPDLC implementation.

[Andreas Fuchs]

I thought the automatic transfer worked already!? Only works when you get transferred from ATC with active CPDLC to another unit that is using CPDLC as well.

[Richard McDonald Woods]

Hi Andreas,😄

I fully realise that automatic transfer is a real-world requirement, but Emi recently showed an A320 CPDLC flight where he had to re-sign on when crossing a FIR boundary.

The Simbrief OFP produces identification of FIR boundary crossings, but not the frequencies. From where it would be possible to automatically access active radio frequencies I do not know (VATSIM?).  

[Andreas Fuchs]

Frequencies are often specific to VATSIM, since not all real world sectors may have been implemented. Frequencies used on VATSIM will also differ from the real world, since we do NOT use 8.33 channel spacing, but the legacy 0.25kHz frequencies. I faintly remember that my CPDLC-client transferred me automatically to the next CPDLC-station - it may be specific to the addon aircraft that is used. CPDLC works independent from any ATC-frequency.

[Matisse VanWezer]

During CPDLC handover, Topsky includes the new logon code. It should indeed cause the aircraft to switch automatically. However, as Andreas pointed out, this might be limited to some add-ons based on their implementation.  Keep in mind, if a controller is using CPDLC and your aircraft is capable, that does not imply you will automatically switch: iirc it also depends on the controller's implementation. 

[Andreas Fuchs]

In this case the function may be limited to ATCOs who are using the TopSky plugin for Euroscope, that would make sense!

[Simon Kelsey]

As Matisse and Andreas say, automatic transfer is, in principle, possible. But for various reasons (either on the aircraft side or the ATC client side) it does not always work.

However, I gather that in real life automatic transfers are far from seamless or 100% reliable either -- from speaking to friends who fly around Europe in CPDLC-equipped aircraft on a daily basis, I hear that quite often the automatic transfer fails and a manual login is required, logon attempts quite regularly fail (in some FIRs more than others!), etc etc... so this is not necessarily entirely a VATSIM issue!

[Matisse VanWezer]

13 hours ago, Simon Kelsey said:

quite often the automatic transfer fails and a manual login is required, logon attempts quite regularly fail (in some FIRs more than others!), etc etc... so this is not necessarily entirely a VATSIM issue!

On the other hand, in real life, they usually have one logon code for the whole FIR, not every sector. As a result, one failing login isn't a big deal. Hopefully it's something we can implement soon too! 😉

[Andreas Fuchs]

Isn't it that Frenchies at VATSIM have found a solution for this? I heard they cannot share it "as is" for some reason, but in principle it does work. First of all VATSIM needs its own CPDLC-network.

[Matisse VanWezer]

52 minutes ago, Andreas Fuchs said:

Isn't it that Frenchies at VATSIM have found a solution for this? I heard they cannot share it "as is" for some reason, but in principle it does work. First of all VATSIM needs its own CPDLC-network.

Yes, but the implementation is not optimal. For example, all logon requests are visible (and audible) for all French controllers and their implementation is not compatible with TopSky (ie no message via the TAGs, ie it's probably faster to do it via voice and is as much of a hassle as text). If for example TopSky would allow grouping controller IDs to a certain logon code and only show the controller messages for aircraft he has owner ship of, we would have a nice implementation.

However, for this to fully work this would probably need to be changed to.

You would otherwise not receive messages for CPDLC connected aircraft during (silent) handoff. A history of messages senders might also be needed in order to avoid replies being send to the wrong controller after a handoff.

In any case, fingers crossed.

Edited October 20, 2022 at 11:17 AM by Matisse VanWezer

[Andreas Fuchs]

I see that Matisse wants to be the leader of this project! You got the job, man! 😄

[Bernardo Reis]

9 hours ago, Matisse VanWezer said:

You would otherwise not receive messages for CPDLC connected aircraft during (silent) handoff.

Why not? You would receive the frequency change message and then continue receiving messages from the other controller as normal.

[Mateusz Zymla]

TopSky determines next controller logon by guessing it by callsign (so EPWW_C_CTR would be determined as EPWC and so on). That's what I understood from Mattia somewhere on VACC Scandinavia forums. That is why sometimes automatic detection (or determination, I should say) doesn't work.

[Bernardo Reis]

3 hours ago, Mateusz Zymla said:

TopSky determines next controller logon by guessing it by callsign (so EPWW_C_CTR would be determined as EPWC and so on). That's what I understood from Mattia somewhere on VACC Scandinavia forums. That is why sometimes automatic detection (or determination, I should say) doesn't work.

That's not correct I think. You define the logon code by station ID in [STATIONS] field of TopskyCPDLC.txt

[Matisse VanWezer]

On 10/20/2022 at 10:56 PM, Bernardo Reis said:

Why not? You would receive the frequency change message and then continue receiving messages from the other controller as normal.

In a world where CPDLC is used as intended it wouldn't pose an issue but image the following situations.

 

Aircraft logs onto code EBBU.

After a few minutes the aircraft gets handed over to the next sector, still in the EBBU FIR. 

At least two possible scenario's that could cause trouble

1. Pilot doesn't call in on voice

The first controller (who performed the handoff) would still get new cpdlc messages until the second controller accepts the tag (after the pilot called in).

2. Pilot sends a cpdlc message/request right while handoff is being delivered through cpdlc

The first controller would still get the request while the second, current, controller would never receive it. 

 

Also, when the handoff goes to a controller with a different logon code (ie to EDGG) the pilot logs on but the system (topsky) does not know to which controller to send the aircraft messages until the handoff is accepted (thus after the aircraft calls in). 

 

When the controller to whom the handoff is initiated becomes the owner, the system does know who is supposed to receive new messages (not replies! that's why you would need history).

[Matisse VanWezer]

6 hours ago, Mateusz Zymla said:

TopSky determines next controller logon by guessing it by callsign (so EPWW_C_CTR would be determined as EPWC and so on). That's what I understood from Mattia somewhere on VACC Scandinavia forums. That is why sometimes automatic detection (or determination, I should say) doesn't work.

False, as Bernardo mentioned it is done using the controller ID. This is why, if you make a manual transfer the CPDLC handover also still works. 

[Mateusz Zymla]

3 hours ago, Matisse VanWezer said:

False, as Bernardo mentioned it is done using the controller ID. This is why, if you make a manual transfer the CPDLC handover also still works. 

It has changed since this message appeared, then.

[Tobias Dammers]

On 10/24/2022 at 5:43 PM, Matisse VanWezer said:

In a world where CPDLC is used as intended it wouldn't pose an issue but image the following situations.

 

Aircraft logs onto code EBBU.

After a few minutes the aircraft gets handed over to the next sector, still in the EBBU FIR. 

At least two possible scenario's that could cause trouble

1. Pilot doesn't call in on voice

The first controller (who performed the handoff) would still get new cpdlc messages until the second controller accepts the tag (after the pilot called in).

2. Pilot sends a cpdlc message/request right while handoff is being delivered through cpdlc

The first controller would still get the request while the second, current, controller would never receive it. 

 

Also, when the handoff goes to a controller with a different logon code (ie to EDGG) the pilot logs on but the system (topsky) does not know to which controller to send the aircraft messages until the handoff is accepted (thus after the aircraft calls in). 

 

When the controller to whom the handoff is initiated becomes the owner, the system does know who is supposed to receive new messages (not replies! that's why you would need history).

Keep in mind that the CPDLC automatic handover only hands over CPDLC comms, not voice comms - the pilot still has to call in on voice with the new controller, even when the voice handover has been initiated via CPDLC. Also, the CPDLC messages for voice handover and CPDLC handover are separate ones; the voice handover is displayed and acknowledged like any other CPDLC instruction, while the CPDLC handover is handled automatically by the aircraft systems.

Also keep in mind that you can always fall back to voice comms when CPDLC isn't possible for whichever reasons.

So here are two scenarios demonstrating how it should go:

Scenario 1: Handing over to a controller using the same CPDLC logon

1. CPDLC uplink: "CONTACT (new station) ON (frequency)"
2. CPDLC downlink: "WILCO"
3. Pilot switches frequency and calls in on voice

Scenario 2: Handing over to a controller using a different CPDLC logon

1. CPDLC uplink: "CONTACT (new station) ON (frequency)"
2. CPDLC downlink: "WILCO"
3. CPDLC uplink: "NEW DATA AUTHORITY (new CPDLC logon)"
4. CPDLC downlink: "LOGON (new CPDLC logon)"
5. CPDLC uplink: "LOGON accepted" (from new CPDLC station)
6. (In parallel with 3.-5.:) Pilot switches frequency and calls in on voice

And yes, you are right that this can cause issues if the pilot sends CPDLC messages just before the CPDLC handover happens, which is why there are some recommendations:

1. As a controller, do not initiate a CPDLC handover when there are still open CPDLC dialogs (including the voice handover).
2. As a controller, initiate and complete the voice handover before initiating the CPDLC handover.
3. As a pilot, do not initiate a new CPDLC dialog while being handed over - use voice comms instead.

However, at least in IRL CPDLC systems, if the CPDLC authority *does* change in the middle of a dialog, then the systems on both ends will detect this, and the dialog will fail, which then, by policy, forces pilot and ATC to resort to voice comms to clear things up. E.g.:

1. CPDLC downlink: "REQUEST FL200"
2. CPDLC uplink: "NEW DATA AUTHORITY (new CPDLC logon)"
3. CPDLC downlink (automatic): "LOGON (new CPDLC logon)"
4. CPDLC uplink: "LOGON ACCEPTED"
5. CPDLC uplink (from old station, answering the FL200 request:) "DESCEND FL200"
6. CPDLC downlink: "NOT CURRENT DATA AUTHORITY" (this should display as an error on the controller's client, and it means that the clearance has not been accepted)

As to what to do if the pilot doesn't call in on voice: the same thing that happens in such a scenario when CPDLC is not in use. Coordinate with the old controller, ask them whether the pilot is still with them; wait; try to reach them on CPDLC; try to reach them on text (VATSIM) or on GUARD (IRL - not used on VATSIM); and, failing all else, resort to lost comms procedures. This is pretty much independent from CPDLC.

[Richard McDonald Woods]

Hi Toby!

Thanks for a very clear explanation.

Does anybody know whether aircraft and ATC (VATSIM) software is planned to support both ends of a CPDLC conversation?

Wouldn't it be great if real world aircraft radios could be automatically retuned to the new frequency 🥴. But our hobby cannot expect to change the real world.

[Andreas Fuchs]

My real plane does NOT do CPDLC (we have an exemption for this) and I do NOT mind.

[Tobias Dammers]

41 minutes ago, Richard McDonald Woods said:

Does anybody know whether aircraft and ATC (VATSIM) software is planned to support both ends of a CPDLC conversation?

Most ATC clients, and many aircraft, already support CPDLC via the Hoppie network (http://www.hoppie.nl/acars/). It is not affiliated with or endorsed by VATSIM in any way, but it is a de facto standard solution for CPDLC on VATSIM. If your aircraft doesn't support it, you can try "EasyCPDLC", a standalone Hoppie client.

 

44 minutes ago, Richard McDonald Woods said:

Wouldn't it be great if real world aircraft radios could be automatically retuned to the new frequency

Some CPDLC systems can actually do that, or, well, they can do it semi-automatically (fully automatic would be rather bad). The workflow is usually something like this:

1. Receive CPDLC uplink "Contact (station) on (frequency)"; aircraft goes "ping"
2. Pilot opens CPDLC uplink on MCDU
3. Pilot selects "WILCO" and sends response
4. Pilot selects "APPLY", and selects a COMM radio (usually COMM1); frequency is inserted in that radio's standby
5. Pilot swaps COMM frequencies and makes call

This is possible because CPDLC messages are designed to be machine-readable, so the FMS actually understands what the message means, and which parts are what, so it can extract the frequency, and it knows what to do with it. Likewise, some CPDLC systems can also insert DIRECTs and other instructions directly into a temporary flightplan, so that the pilots don't have to manually copy them over, but instead just review and confirm the temporary flightplan.

[Richard McDonald Woods]

I was involved with the original introduction of CPDLC with Jeroen Hoppenbrouwers, probably over 20 years ago. Hence, my continuing interest in how we can have an embedded implementation.

[Tobias Dammers]

21 hours ago, Richard McDonald Woods said:

I was involved with the original introduction of CPDLC with Jeroen Hoppenbrouwers, probably over 20 years ago. Hence, my continuing interest in how we can have an embedded implementation.

Well, that's the thing, we already have a couple of them, but it has to be done on a per-aircraft basis, because it needs to integrate with whatever avionics are simulated, and that's going to be different for each aircraft.