NTN – Part 6 – Satellite Mobility

In the previous episodes, I’ve gone into some of the details of the Non-Terrestrial Network (NTN) extensions specified in 3GPP Rel. 17 36.300 and 38.300. One main aspect I haven’t addressed so far is mobility, so let’s have a look at that today! Actually, mobility in NTN is even more fun than in terrestrial networks because it’s not only the mobile device but also ‘the network’ that can potentially move from one place to another!

3GPP makes it quite clear that mobility procedures over satellite (i.e. over NTN) work just the same as in terrestrial networks unless specified otherwise. This is important to realize because the basic mindset is that LTE and 5G over satellite works just the same way as over a terrestrial base station, perhaps with just a few bits and pieces added, modified or removed. So let’s have a look what TS 36.300 and 38.300 have to say:


In an ideal case, the network is able to hand-over an ongoing RRC connection to another cell (or satellite beam in the case of NTN) before the RRC connection is lost and needs to be reestablished. This can happen for two reasons: As in terrestrial networks, the mobile device moves into an area in which a different cell (i.e. a different beam) provides better coverage. So far so good. With Low or Medium Earth Orbit (LEO or MEO) constellations, however, the satellites also move relative to the earth, so it’s now also possible that the mobile device stays in place but the network moves. In other words, a handover is now also required due to the ‘network moving’. A bit bizarre when one comes from a terrestrial network background.

For handovers, it seems a bit of additional information for the UE is required. 3GPP says:

'To enable mobility in NTN, the network provides target cell NTN payload assistance information needed to access the NTN cell in the handover command'

Note that ‘NTN payload’ is just another name for the satellite. Over NTN, the standard handover parameters do not suffice because when a connection is handed over from one satellite to another, the UE must become aware of the orbit parameters, so it can pre-compensate for the new round trip delay and prepare for a different Doppler shift of the carrier wave.

An important note: LTE NB-IoT does NOT use handovers per design in terrestrial networks, so the handover scenarios would only apply for LTE CAT-M and 5G over satellite.

RRC Connection Failures

For NB-IoT and for cases in which the UE looses the network for a short time, radio link failure procedures and RRC connection re-establishments are also supported over satellite. The general procedures applicable to ground and satellite use cases are described in Chapter 10.1.6. When one looks in 10.1.6, one finds the standard LTE UE Radio Link Failure procedures. Nothing new here.

Feeder Link Switch-Overs

Let’s come back for a moment to the moving network, i.e. LEO or MEO satellite constellations used as repeaters for a base station on the ground. From a terrestrial point of view, the following ‘bizzare’ thing can happen:

'A feeder link switchover may result in transferring the established connection for the affected UEs between two eNBs'

So, as already noted above, despite the mobile device being stationary it has to perform a handover, not only in the case when moving from one beam to another but also when the new beam is provided by a different satellite. So it’s upside down, the mobile is stationary and the network is moving. But then everything is relative, it doesn’t really matter which part moves. All that matters is that a different cell or beam provides a better signal strength and quality.

But Something Needs to be Fixed

And before I close, here’s another interesting addition 3GPP has made for NTN. From a core network point of view, cells have a static location and do not move. But in LEO/MEO NTNs, they do move. The solution: Mapped Cell IDs. The way I understand this is that the eNB on the ground uses the information which beam serves which part of the earth at a particular time and maps cell ID related information to a ‘Mapped Cell ID’ that is always the same for a particular area. This way, software that looks at the Cell-ID in the core network for various purposes such as location based services, billing, etc. have something to work with.


So, yes, idle mode, connected mode and radio link failure scenarios look pretty much the same from a UE point of view with only a few additions. By now, one thing should be clear: It may be possible to pick up LTE or 5G signaling from normal mobile devices from space but the software in the devices must be adapted. 3GPP also makes this quite clear, as the specs say that only NTN enabled mobiles are allowed to communicate with an NTN cell. That makes me wonder, though, how non-NTN enabled devices become aware that they shouldn’t talk to an NTN cell. I’m sure that’s specified somewhere but I haven’t found it yet.