Don’t know the implementation specs but on Android phones you can use the Google Cloud Messaging system. It seems to work quite well.
I use it in one of my apps that has 100 users. No problems.
A mobile device these days has an IP connection to the general Internet, and in principle IP can do true “push”
Regardless of any protocol, you need to be on a known IP in order to receive UDP packets.
I recently spoke to someone who is involved with this stuff. The problem is that while a phone user walking about a town on 3G/4G will keep his IP despite going into a toilet and briefly breaking the signal (so is not doing DHCP all the time, so you could just send him push notifications via UDP) this does not work when airborne. For a start, you are probably switching networks. Also you lose the signal for say 1hr at a time. And then it seems clear that some systems simply blacklist you for hopping across too many towers too fast – I see this a lot over France where I see a full signal for ages but no data (no IP allocated, apparently).
If you had a phone with a fixed IP (which is possible – we have this at work for ADSL backup, a SIM card for £3/month) then you could deliver whatever you want to an airborne user, just by throwing UDP packets at him (serially numbered, but nothing more complex). The most brief connectivity windows might be enough. The problem is that the requirement for such a phone (probably a pricey corporate-level cellular product) would make the service unmarketable (as would the need for a rooted phone).
That situation is technically already here somewhat. Here (Luxembourg), the telcos kinda already have adapted their pricing to that: the difference between different subscriptions is purely the data; nearly all subscriptions have exactly the same “fake unlimited” for calls, SMS and MMS included. The only thing they would really lose is international calls to non-EU (and non-USA) destinations, that are outside the “flat fee”.
With the EU roaming gravy train disappearing, they want the non EU traffic even more 
I recently got billed a huge amount (tens of €) for downloading a few k while overflying Albania and Montenegro.
And if your aircraft did not have ADS-B Out installed, you are only seeing a minority of the traffic!
That seems to be a US-specific quid pro quo, AIUI.
Peter wrote:
The only real “push” that exists in the mobile context is the original GSM one: a phone is constantly listening for tower signals and about every 10 mins it reports itself to the nearest tower.
IPv6 is designed to make this better (no NAT, IPv6 mobility, …), but is barely being deployed “last mile”, and the least in mobile … probably because it destroys telco’s business model. They even reinvented NAT on top of IPv6.
But the last thing which the cellular networks want is VOIP working because it would open the door to the holy grail of a VOIP-only phone whose SIM is just a data SIM and no “hard” number
GaryandAlice wrote:
Thanksgiving Day, it appeared all of California was traveling to family. And they were all using airplanes.
And if your aircraft did not have ADS-B Out installed, you are only seeing a minority of the traffic!
In the US, the clearance data is already published in electronic form inside the FAA computer. At a point prior to departure, typically 30 minutes, the clearance is printed on a strip or available on a screen display to the controller who issues the clearance verbally when the pilot requests the clearance. In most instances, the controller does not make changes, although they can. It is a common service today by App providers to forward a heads up copy of the route from the same source that the controller obtains their copy. ForeFlight obtains its expected route information as published by the FAA on their computer.
So the pilot today, often has a copy of the route that the controller is going to clear the aircraft and knows the rest of the information a priori. So it is not a big stretch to provide the remaining components of the clearance in electronic form. What is new that is being proposed, is to allow this electronic version to be sent to the pilot via a text or email or direct to the App. The controller would not need to read the clearance to the pilot, but the pilot would still have to read back the clearance and the controller would have to confirm the read back.
A typical clearance follows a pre-ordained order CRAFT:
C – Clearance Limit, this is already known by the pilot, it is the destination
R – Route, this was filed and is either unchanged or the system currently provides an expected route
A – Altitude, this is typically the filed altitude or the SID or there is a standard altitude for the airport, like my airport is 3000 feet, expect filed altitude 10 minutes after departure
F – Frequency, this is usually on the chart and known by the pilot in advance.
T – Takeoff instructions, these are usually canned for a specific airport
So the system would change from a verbal copying of the clearance, to an electronic form with verbal read back. If electronic form did not work, revert to verbal.
None of this relates to taking the route and sending it to the panel equipment. That is a separate and distinct operation after the clearance is received and may or may not be automated.
I know this is getting nitpicky but while messages get sent to the telegram server “instantly”, the telegram client app still has to keep checking, and you see this not working all that well when airborne, when the phone needs something like a minute of solid mobile data connection before it tells the app that it has an internet connection and can start retrieving messages. Consequently I frequently find that I send a wx request during a flight and get it delivered as I land, a couple of hours later Some previous threads – mainly this one. That is why I am installing the ADL150 – 3G/4G is OK a lot of the time but it is e.g. normal to get zero connectivity over the whole of Belgium, and almost zero over France (Vodafone). It works great over the Alps. This issue would not exist if you are parked at an airport and getting your departure clearance, but it would be useless for any airborne stuff which is what CPDLC is supposed to work for. And I can’t see anybody implementing a system which works only on the ground; the ATC time saving is minimal for the extra interface involved.
Eurocontrol can send slot messages. These can be accessed by Autorouter and pushed to Telegram (yes Peter, you’re correct “push” means “listen” but it’s an accepted term).
ATC has the clearances on a server somewhere (since they can be sent to CAT). These could be accessed in the same way.
My point is only that the technical effort is probably quite light. I agree with everyone else, it’s a question of focus so it won’t happen.
Peter wrote:
The message needs to be sent to the airframe (more precisely, to the airframe currently flying that flight number e.g. AF447, BA038…) not to the crew.
Good point and that goes to the heart of the matter, and is why it’s a long way away in Europe. CAT is the priority for Eurocontrol
The Q I would ask is on the implementation details at the ATC end. One could do it with a website into which the ATCO would type in (or copy/paste) the clearance. Connected to this would be a database of your mobile #, or your email address. Eurocontrol already has all this, for their 2T+ billing 
Then you just need the trivial thing of sending SMS (plenty of commercial options for that), sending email (even more trivial), or sending a Telegram message (not good since very few people use Telegram), and Whatsapp is not available since they ban machine interfacing. Given the message length could exceed 160 bytes, an email would be the best way.
Technically this is easy but somebody would have to fund it, and somebody would have to promote it to ATC and to pilots. And a lot of pilots (probably the majority of the VFR community) are not internet users.
AIUI, there is no “push” technology in reality. It is just a fancy term, like “cloud”. The phone’s OS needs internet (mobile data) access (GPRS/EDGE/3G/4G) and via the internet it periodically polls some server belonging to a “push” outfit (e.g. the Pushover one which can be used for EuroGA notifications). The app gets the incoming message “pushed” to it via some API but actually the phone has to keep polling that server all the time, via the internet, with the battery life impact that has (fairly minimal if the signal is good).
The only real “push” that exists in the mobile context is the original GSM one: a phone is constantly listening for tower signals and about every 10 mins it reports itself to the nearest tower. This is how they track criminals etc because all these accesses are logged, together with the signal level, the IMEI, etc. If there is an incoming voice call or SMS, the phone gets that right away, and your phone rings, etc. This was why the Stagefright issue was so big – no way to prevent the reception of a picture SMS, short of using an SMS app which can disable them. But AFAIK this mechanism isn’t available for 3rd party usage. It would be good if it was because you could implement e.g. incoming VOIP calls without the heavy battery drain which that currently involves (polling the server). But the last thing which the cellular networks want is VOIP working because it would open the door to the holy grail of a VOIP-only phone whose SIM is just a data SIM and no “hard” number
Back to the ATC aspect, I can’t see it happening in Europe because GA gets no ATC services (other than (a) mandated by ICAO i.e. FIS and (b) operating on the back of airliner services), and for airliner messaging CPDLC is seen as the way forward, not sending emails or whatever to pilots. The message needs to be sent to the airframe (more precisely, to the airframe currently flying that flight number e.g. AF447, BA038…) not to the crew.
It would be good but I don’t hold my breath.
CPLDC is an expensive option on a Citation, we’re talking six figure sums.
As a rule of thumb I reckon if it’s aviation I add a zero to what an automotive part would cost, if the aeroplane runs on kerosene another zero, and if there’s no propellers double it.
