It's interesting that they state that the train was moving, but not how fast. My understanding was that one of the challenges with doing good mobile broadband on trains (esp. for VoIP applications) is how seamlessly you manage the handover between cells makes a big difference to real-world usability. If the train was going pretty slowly that would obviously make your time-per-cell a lot higher / % of time spent performing handoff a lot lower...
Handover is a massive non-trivial problem - I'm amazed you're the only one commenting on it.
GSM-R was modification to the 2G mobile phone specification specifically to help with high speed handover, but being 2G it gives pretty awful data speeds (1mbit max iirc). If you google for LTE-R it seems there's special provisions to bring that fast handover ability to 4G & 5G networks.
As well as the actual radio layer, you've also got the mobility management side of things to consider, for example your IP address. If you've got a video streaming or a SIP call going then when you connect to the next radio tower your IP address has to move across as do any established data sessions - it's not just a case of getting a new DHCP lease and cracking on, there's some serious network orchestration and session management happening too.
(I'm convinced I read something a few years ago that one of the LTE design goals was to allow handover when moving at 200mph (that number seems stuck in my head), but I'm failing to find any mention of it outside of the LTE-R results).
That’s handled at a higher level though. If you manage to get the lower level handover running fast enough, the IP side of things shouldn’t be a problem (as all the traffic goes to the GGSN or whatever LTE’s equivalent of that is).
> the IP side of things shouldn’t be a problem (as all the traffic goes to the GGSN or whatever LTE’s equivalent of that is).
I'm not sure it's quite that simple. One of the things LTE started (and 5G continues) is to push more and more of this to the edge of the network. Traffic from the UE does get tunnelled through the Serving Gateway (S-GW), but there can be multiple SGW's on a network. Mobility management is also a big enough issue that the Mobility Management Entity (MME) is an entity unto itself on the block diagram.
It's also worth pointing out that eNodeB's (the radios) can now talk directly to each other via X2 and can actually hand over a subscriber without particularly involving the core network.
tldr: I think it's enough of a problem for it to be not entirely trivial.
The mobile (UE) IP anchor is not the S-GW but the P-GW in the core network. For an established PDU session the IP address is fixed, and does not change during a handover.
For information MIP is used between S-GW and P-GW (PMIP IIRC), so there can be IP addresses changes when the HO is such that the S-GW changes. Still, this is transparent to the UE: it's a change at the tunnel level, and the UE traffic flowing inside this tunnel is not affected.
BTW what "anchor" means here is that the IP address the UE gets is routed to the P-GW. From then on the traffic is tunneled to the UE across the cellular network core and radio access networks, but all this is transparent for the end device. There's a first leg from P-GW to S-GW, then from S-GW to the eNB (the base station), then the over-the-air and last leg to the mobile device. That's 3 tunnels joined together to transport data seamlessly from P-GW to UE. During a HO the radio one always changes, the S-GW to P-GW rarely changes. And the P-GW is fixed to provide IP session continuity.
That data is indeed missing. FWIW, though: the French Railway Corporation (SNCF) has had WiFi for some years in the high speed (TGV[0]) lanes (though they have a data cap). I've had no issues with it so far[1,2]. That's a working solution in a ~320km/h (200mph) moving train as commercial offering.
Well, it's a 4 km distance and according to the schedule of the train it takes 6 minutes between both stations, so it would be an average of 40 km/h (well, you will understand that it is relative as the train has to accelerate and decelerate). Also, some of the portion is in a tunnel, I don't know if this can affect in any way the network.
