A UE can stay at the same location and still need handover in NTN. The satellite moves, and its coverage may move across the UE. Even when the network keeps the coverage over the same area, it may need another satellite to continue serving that area.

This changes how we think about mobility. In a terrestrial network, we usually start from UE movement and radio measurements. In NTN, we also need to ask how long the current satellite can serve the UE. A good RSRP now does not guarantee that the serving path will remain available.

The basic NR handover procedure still applies. NTN adds information about satellite motion, service time and location. UE also needs the correct timing and frequency compensation when it accesses the target. Choosing the target cell and successfully transmitting to that cell are two separate parts of the problem.

This page focuses on NR NTN in RRC_CONNECTED. It explains the Release 17 baseline and selected Release 18 enhancements. The references identify the specification versions used; this is not a claim that every NTN device supports every procedure.

• High-level Handover Sequence
  • Conventional Measurement-based Handover
  • Conditional Handover (CHO)
• Why Handover is Needed
• What Actually Changes ?
• Earth-moving and Quasi-Earth-fixed Cells
• Basic Handover Procedure
• Conditional Handover
• Measurement, Time and Location Triggers
• Timing and Frequency at the Target
• Satellite Switch and Feeder Link Switchover
• Mobility Between TN and NTN
• A Simple Timing Example
• What to Check in a Log
• References

High-level Handover Sequence

NTN supports conventional measurement-based handover and conditional handover (CHO). In conventional handover, UE reports measurements and the network decides when to send the handover command. In CHO, the network prepares candidates early and UE executes when the configured conditions are fulfilled.

Both examples use two gNBs. Satellite and gateway hops are included in the radio paths rather than drawn as separate RRC endpoints. The preparation arrows summarize inter-gNB coordination; core signalling and data forwarding are omitted.

Conventional Measurement-based Handover

UE sends MeasurementReport when the configured reporting conditions are fulfilled. The report gives the network information for its decision; it does not instruct UE to change cells. The source prepares the chosen target and sends the handover command.

UE then applies the target configuration and proceeds with access. It does not store a CHO candidate and wait for a separate execution condition in this procedure.

Figure 1. A measurement event triggers reporting; the network's handover command triggers UE execution.

The early RRCReconfigurationComplete acknowledges measurement configuration at the source. The later completion belongs to handover at the target. The source may also use service availability and other network information when deciding whether to hand over.

Conditional Handover (CHO)

The source sends the candidate configuration before UE needs to leave. UE then evaluates the configured conditions, including T1 or D1 when used. Once the required conditions are fulfilled, UE applies the stored target configuration without waiting for another source command.

Figure 2. CHO prepares the target early; UE executes when its configured conditions are fulfilled.

The completion sent to the source acknowledges receipt of the conditional configuration. UE has not executed handover at that point. Successful execution still requires access and completion at the target.

The preparation arrows summarize inter-gNB coordination, not exact Xn or NG message names. Target downlink acquisition summarizes UE synchronization; it is not a dedicated RRC message. RACH-less access requires the applicable support and configuration.

Why Handover is Needed

Let's start with a stationary UE under a LEO satellite. If the beam footprint moves with the satellite, the UE eventually leaves the serving cell's coverage. The UE did not move, but its position relative to the cell changed.

The network can steer a beam to keep serving a geographical area for some time. That helps, but the satellite cannot keep serving that area indefinitely. The network may need to transfer service to another satellite as the first one moves away.

There is also a path on the ground side of the satellite. In a transparent payload architecture, the feeder link connects the satellite to an NTN gateway. A gateway change may affect the serving gNB connection, even while the UE remains under the same satellite.

These changes are partly predictable from orbit and coverage planning. The network can prepare mobility before the serving radio link becomes poor. The long propagation delay makes this early preparation useful: waiting for the last moment leaves less time for signalling and target access.

What Actually Changes ?

Before reading a handover log, identify what is changing. A satellite, a beam, a cell and a gNB describe different parts of the connection. There is no general one-to-one mapping between them.

The following cases separate the physical path change from the RRC mobility procedure. Pay attention to whether the UE changes its serving cell and whether its context moves between gNBs.

For the payload and gateway relationships, see NTN Architecture. The switchover definitions come from TS 38.300, clause 16.14.4.

Earth-moving and Quasi-Earth-fixed Cells

With an Earth-moving cell, the coverage area moves over the ground. A stationary UE can move from the middle of the coverage area toward its edge simply because the footprint moves.

With a quasi-Earth-fixed cell, beam steering keeps coverage over approximately the same geographical area for a limited period. The next satellite can then take over that area. Here, the end of the serving period can matter even when the UE remains near the cell's reference location.

This is why a single RSRP comparison does not describe every NTN mobility case. The network may know that service is about to stop before the UE measures a large signal drop. Conversely, a predicted target position does not prove that the target radio link is usable.

The coverage pattern also matters for location conditions. A fixed reference location is suitable for describing a fixed geographical area. For a moving cell, the reference location itself needs to evolve with time. Release 18 adds a CHO event for this moving-reference case.

Basic Handover Procedure

First consider a conventional NR handover with random access at the target. The source network prepares a target configuration, sends it to the UE, and the UE applies it. NTN-specific assistance makes the target radio access possible over the satellite path.

This sequence is a procedure outline, not a captured test. Preparation signalling depends on whether the target belongs to the same gNB or another gNB.

The command is not evidence that handover succeeded. It tells us that the source instructed the UE to move. Target access and completion show how far the UE actually got.

Release 18 also supports RACH-less handover in NTN. When the required configuration and conditions apply, the UE can use that procedure instead of the random-access stage above. Do not assume that every NTN handover must contain PRACH. See TS 38.300, clauses 9.2.3 and 16.14.3.2.1.

Conditional Handover

Conditional Handover (CHO) separates preparation from execution. The network sends candidate configurations while the source connection is still available. UE stores them and evaluates the associated execution conditions.

When a candidate's conditions are fulfilled, the UE applies that candidate's stored configuration. It does not need another handover command from the source at that instant. This reduces dependence on receiving a late command over a fading or expiring source link.

For now, pay attention to three RRC fields. conditionalReconfiguration carries the conditional configuration. condExecutionCond identifies the condition or conditions for a candidate. condRRCReconfig contains the RRCReconfiguration to apply when those conditions are fulfilled.

The network still chooses and prepares the candidates. CHO does not allow the UE to select an arbitrary satellite and create its own target configuration. A candidate also needs usable radio coverage and valid access information when execution takes place.

There are two completion points to distinguish in a trace. UE can acknowledge receiving the conditional configuration at the source before any handover occurs. A later RRCReconfigurationComplete at the target belongs to execution of the stored configuration.

The baseline procedure is in TS 38.300, clause 9.2.3.4. The RRC evaluation and execution rules are in TS 38.331, clause 5.3.5.13.

Measurement, Time and Location Triggers

CHO conditions answer different questions. Radio events check signal quality relationships. Time and location events relate execution to the planned availability of coverage. The configured combination determines when UE can execute.

The event descriptions here explain their purpose. Exact entering and leaving conditions, filtering, hysteresis and timeToTrigger follow TS 38.331, clause 5.5.4 and ReportConfigNR.

Time-based Execution

T1 defines an execution window, not a countdown started when the UE receives the RRC message. t1-Threshold-r17 uses an absolute time representation. Decoding it as a relative delay would produce the wrong execution time.

The threshold uses 10 ms units from the UTC epoch specified in TS 38.331, starting on 1 January 1900. duration-r17 uses 100 ms units. Use the exact event rules at the boundaries rather than rounding a decoded timestamp to the nearest second.

Do not confuse this threshold with t-Service-r17 in SIB19. t-Service indicates when the cell will stop serving its current area. It does not, by itself, provide a CHO candidate configuration or command UE to execute handover.

The network sends the T1 parameters through dedicated RRCReconfiguration signalling. They belong to condEventT1-r17 inside ReportConfigNR. The candidate's condExecutionCond uses a measurement identity to link this event configuration to the associated measurement object.

The following path locates the two T1 fields. Some wrapper fields are omitted, as in the D1 example in the next section.

RRCReconfiguration
  measConfig
    reportConfigToAddModList
      ReportConfigNR
        reportType: condTriggerConfig-r16
          condEventId: condEventT1-r17
            t1-Threshold-r17
            duration-r17

Unlike the D1 event, condEventT1-r17 has no hysteresisLocation or timeToTrigger field. duration-r17 determines when the T1 leaving condition becomes true. It is not a period during which UE must wait after the entering condition becomes true.

TS 38.331 defines the entering and leaving conditions separately. Mt is the time measured at UE. Convert the encoded threshold and duration to milliseconds before comparing them with Mt.

Thresh1  = t1-Threshold-r17 x 10 ms
Duration = duration-r17 x 100 ms

T1-1 entering condition: Mt > Thresh1
T1-2 leaving condition:  Mt > Thresh1 + Duration

Both inequalities use a strict greater-than comparison. At exactly Thresh1, the entering condition is not yet true. At exactly Thresh1 + Duration, the leaving condition is not yet true. These are event-state rules; do not replace them with an inclusive-start comparison in a log-analysis script.

Consider a hypothetical threshold of 12:00:00 UTC on 5 November 2026 and a duration of 3 seconds. The following values distinguish the encoded integers from their decoded meaning.

The threshold field permits integers from 0 to 549755813887. The duration field permits integers from 1 to 6000, corresponding to 100 ms through 600 seconds. The two fields have different scales even though both represent time.

Assume UE receives the candidate configuration at 11:59:50 UTC on the same day. The configured threshold remains 12:00:00 UTC; receiving the message does not start a new three-second timer. The following observations assume the configuration remains applicable throughout the example.

Now suppose the same candidate also has an A4 condition. If A4 becomes fulfilled at 12:00:01.200, including its applicable timeToTrigger, UE can execute while T1 remains fulfilled. If A4 becomes fulfilled only at 12:00:03.100, it is too late for this window.

The samples above illustrate the comparisons, not a required UE evaluation interval. T1 also does not guarantee completion within three seconds. Once UE executes the candidate configuration, target synchronization and the configured access procedure still have to succeed.

For a trace, check the UTC conversion, the 1900 epoch, and both field scales first. An SFN value, Unix timestamp or local wall-clock time cannot be compared directly with the encoded threshold. The definitions are in TS 38.331, clause 5.5.4.16 and CondTriggerConfig within ReportConfigNR in clause 6.3.2.

Location-based Execution

D1 uses two distances. One relates UE to the serving reference location, and the other relates UE to the candidate reference location. Both sides of the condition must be evaluated; leaving the serving region alone is not enough.

These are distances to reference locations associated with cells. They are not simply the slant ranges from UE to two satellites. Keep this distinction when comparing a location trigger with the distance used for timing advance.

Then how does UE get these two reference locations? The network explicitly configures referenceLocation1-r17 and referenceLocation2-r17 inside condEventD1-r17. It sends this measurement configuration through dedicated RRCReconfiguration signalling.

referenceLocation1-r17 is associated with the serving cell. referenceLocation2-r17 is associated with the candidate target cell. The network selects these geographical points; the field definition does not require them to be the exact beam centres.

The following path locates the D1 fields in a decoded RRC message. Some wrapper fields are omitted to keep the relationship easy to follow.

RRCReconfiguration
  measConfig
    reportConfigToAddModList
      ReportConfigNR
        reportType: condTriggerConfig-r16
          condEventId: condEventD1-r17
            referenceLocation1-r17
            referenceLocation2-r17
            distanceThreshFromReference1-r17
            distanceThreshFromReference2-r17
            hysteresisLocation-r17
            timeToTrigger-r17

Each location uses ReferenceLocation-r17, an OCTET STRING containing the Ellipsoid-Point representation defined in TS 37.355. It represents a geographical latitude and longitude. A decoder may display the encoded octets or convert them to coordinates.

For D1, UE uses the two locations explicitly configured in this event. It does not replace them with the serving reference location from SIB19. It also does not derive these fixed points from satellite ephemeris.

The CHO candidate's condExecutionCond contains the measurement identity linking this report configuration to its measurement object. This is how UE associates the D1 condition with the stored candidate configuration.

UE calculates d1 from its own position to referenceLocation1, and d2 from its own position to referenceLocation2. Both entering inequalities must hold. Use the same distance unit for d1, d2, the thresholds and hysteresis.

d1 - hysteresis > threshold1
AND
d2 + hysteresis < threshold2

Consider the following hypothetical configuration. The coordinates are decoded geographical values, not literal ASN.1 octet strings. The threshold and hysteresis columns distinguish encoded field values from physical distances.

Place UE at latitude 0 degrees and longitude 0.6 degrees east. Using approximate surface distances along the equator, d1 is 66.8 km and d2 is 44.5 km. Coordinate encoding quantization is ignored in this illustrative calculation.

Substituting these distances gives two true inequalities. The 1 km hysteresis makes UE move farther beyond the serving threshold and farther inside the candidate threshold before entry.

Serving side:   66.8 - 1 = 65.8 km > 60 km  : true
Candidate side: 44.5 + 1 = 45.5 km < 50 km  : true

If both remain true for 320 ms, the D1 entering requirement is fulfilled. If this candidate also has an A4 condition, that condition must be fulfilled as well before CHO execution.

Now place UE at longitude 0.5 degrees east on the equator. Both distances are approximately 55.7 km. The serving comparison becomes 54.7 > 60, and the candidate comparison becomes 56.7 < 50; both are false.

The distance threshold step is 50 m, while the hysteresis step is 10 m. Do not treat the encoded integers as metres directly. The definitions are in TS 38.331, clause 5.5.4.15 and the ReportConfigNR, ReferenceLocation and HysteresisLocation descriptions in clause 6.3.2.

D2 extends the idea to moving references. The serving reference uses movingReferenceLocation and the associated satellite ephemeris and epoch time from SIB19. The candidate information comes from the associated MeasObjectNR. A stale epoch or incorrect satellite association can therefore affect the location evaluation.

Release 17 and Release 18 Combination Rules

In the Release 17 baseline, the network configures a time or location condition together with an A3, A4 or A5 condition. Do not interpret the time window alone as permission to execute that combined configuration.

Release 18 permits time-only or location-only CHO in supported scenarios. TS 38.300 gives zero or negligible service discontinuity as an example. The actual use still depends on UE support and the network configuration.

In the cited Release 18 RRC specification, a candidate has at most one of D1, D2 and T1. Except for the supported single-event cases, it also has an A3, A4 or A5 event. Two configured triggering events refer to the same measurement object. Check the candidate's condition list before deciding which rule applies.

Timing and Frequency at the Target

Suppose the UE chose the correct target and executed at the correct time. It can still fail if its uplink arrives at the wrong time or frequency. A new satellite path can have different propagation delay and Doppler.

NTN-Config provides access information such as ephemeris, epoch time, common TA parameters, scheduling offset and uplink synchronization validity. SIB19 and dedicated signalling provide NTN information in their applicable contexts. Check the target configuration actually available to UE rather than assuming it reused the serving configuration.

UE uses its position and satellite information for the applicable uplink timing and frequency pre-compensation. The target information must remain valid when the stored CHO configuration is executed. Receiving it earlier does not make it valid indefinitely.

Neighbour measurements have a timing problem too. Signals from different satellites can arrive with different propagation delays. SMTC and measurement gaps must allow UE to observe the target SSB. Missing target measurements can therefore come from measurement timing, even when target coverage exists.

For the compensation mechanisms, see Timing Advance and Frequency Compensation. For target random access, see NTN RACH. NTN measurement support is described in TS 38.300, clause 16.14.3.3.

Satellite Switch and Feeder Link Switchover

A satellite change does not always require an L3 cell handover. Release 18 supports satellite switch with re-synchronization for a quasi-Earth-fixed scenario with the same SSB frequency and the same gNB. The procedure maintains the PCI over the geographical area.

For a soft satellite switch, UE can start synchronizing with the target before the source satellite stops serving the cell. For a hard switch, it can start only after the source stops. Random access can be triggered by a PDCCH order through the target satellite.

These conditions matter when reading a trace with no PCI change. The UE may still need to synchronize to a different satellite path. Check the SIB19 satSwitchWithReSync information and the procedure in TS 38.331, clause 5.7.19.

A feeder link switchover changes the gateway path for a particular payload. A soft switchover allows a period with more than one gateway connection. A hard switchover has only one gateway connection at a time, so an interruption may occur during the transition.

If the switchover transfers the established UE connection between gNBs, the network uses NG-based or Xn-based handover for context transfer. Gateway movement in the topology alone does not tell you which UE-side messages must appear. Check the gNB relationship as well. See TS 38.300, clauses 16.14.3.2.3 and 16.14.4.

Mobility Between TN and NTN

UE may also move between terrestrial and satellite access. The target then changes both the coverage source and the propagation conditions. For TN-to-NTN mobility, target satellite assistance and UE NTN capabilities become part of access preparation.

TS 38.300 does not require UE to connect to TN and NTN simultaneously during this mobility. DAPS handover is not supported for NTN in the cited Release 18 specification. Do not assume a simultaneous source and target connection when estimating interruption.

A supported band pair and mobility procedure are also necessary. Availability of TN and NTN coverage does not establish that a particular UE can hand over between them. Check UE capabilities, network configuration and the applicable release.

In idle or inactive mode, follow cell selection and reselection instead. SIB19 assistance can help mobility measurements, but it does not turn reselection into connected-mode handover.

A Simple Timing Example

Consider a hypothetical CHO candidate B with a T1 execution window and an A4 condition. The following times are illustrative seconds on one common timeline. They are not encoded RRC field values or measured test results.

Assume the source remains available until 100 s. The candidate window runs from 96 s to 99 s. UE already received the candidate configuration at 90 s.

Now change one assumption: B never satisfies A4 during the window. UE cannot execute this candidate merely because the source stops at 100 s. The network needs a suitable mobility plan, and UE follows the applicable failure and recovery procedures if connectivity is lost.

This example also separates execution time from completion time. An execution window does not promise that target access or user-plane recovery finishes at its start. Those take additional time.

What to Check in a Log

Start from the last successful step and work forward. A missing handover command, an unfulfilled CHO condition and a failed target PRACH are different failures. Treating all three as a handover failure hides the useful evidence.

The checks below are diagnostic guidance, not results from a particular test. Correlate UE and gNB records on a common timeline before comparing event times.

For a controlled test, record the source and target identities, the planned service interval and the UE capability set. Keep the actual RRC configuration with the trace. Without those inputs, a timestamp or RSRP plot alone cannot explain why UE executed a particular candidate.

References

The explanations use the following specification versions. Release 17 establishes the baseline combination rule; the Release 18 documents cover moving-reference triggers, RACH-less support and satellite re-synchronization.

• 3GPP TS 38.300 V18.9.0 : NR and NG-RAN Overall Description. Clauses 9.2.3, 16.14.3 and 16.14.4.
• 3GPP TS 38.331 V18.8.0 : NR RRC Protocol Specification. Clauses 5.3.5.13, 5.5.4 and 5.7.19; SIB19, ConditionalReconfiguration, MeasObjectNR, NTN-Config and ReportConfigNR.
• 3GPP TS 38.300 V17.2.0 : Release 17 NTN handover and CHO baseline, clause 16.14.3.2.