A satellite serves UE for a few minutes and then moves away. The next usable satellite does not arrive immediately. What should UE do during that gap? Repeating cell searches can waste battery, and repeated paging cannot reach a UE without radio coverage.

Discontinuous coverage support lets UE and network prepare for expected periods without service. UE can use coverage assistance to plan its activity. The core network can account for expected unavailability when managing reachability, timers and buffered traffic. These functions help handle the gap; they do not create a radio link during it.

This page uses the Release 18 specifications listed in References. It separates NR satellite access with 5GC from NB-IoT/eMTC satellite access with EPC. For the geometry behind the service intervals, see Coverage and Beam Movement.

• What Makes Coverage Discontinuous ?
• Before, During and After the Gap
• NR NTN: Informing the 5G Core
  • How UE Learns About the Gap
  • What UE Reports Before Losing Service
  • During the Gap and on Return
• IoT NTN: Radio Assistance and EPS Procedures
  • What SIB31, SIB32 and SIB33 Do
  • What UE Can Stop Doing During the Gap
  • What the MME Does
• Worked Example: A 20 Minute Gap
• Paging, Power Saving and Pending Data
• References

What Makes Coverage Discontinuous ?

A serving beam can leave UE before another usable beam arrives. A sparse constellation is one possible cause. A service schedule or unavailable feeder connection can also leave a gap, even when UE can geometrically see a satellite.

First check whether another permitted cell or access network can serve UE. Losing one serving satellite does not necessarily mean losing all service. Handover or reselection can maintain service when a suitable alternative exists. The procedures here matter when UE expects to become unavailable and remains without service.

The following comparison separates a predictable service gap from other situations that can look similar in a short log.

Do not infer an expected return time from the satellite orbital period alone. The next usable interval depends on the constellation, beams, UE location and network service schedule. The gap can end on a different satellite, cell or carrier.

• Coverage availability and UE activity are separate. A sleeping UE can be in coverage; an awake UE can be outside coverage.
• A planned gap needs usable prediction. An unexpected fade does not establish a known unavailability duration.

Before, During and After the Gap

The high-level sequence has three parts. UE first learns about the expected gap and, when the relevant feature is supported, informs the core network. UE then handles the period without service. When coverage returns, UE acquires a suitable cell and performs the procedures needed for its current state.

Figure 1 separates radio availability from NAS reachability management. The NR and EPS message names are alternatives, not messages sent together. The drawing omits authentication, security and individual RRC messages so the coverage-gap sequence remains visible.

Figure 1. Informing the core network before a gap helps manage unreachability; radio access must still be recovered afterwards.

For NR, the coverage information can come from an external server through the network. For IoT NTN, the radio network can broadcast SIB32 assistance. Receiving either form of information does not itself notify AMF or MME that a particular UE plans to remain unavailable.

There is no universal RRC state labelled "discontinuous coverage". The applicable RRC and NAS procedures determine UE state. Retaining registration information also does not imply that UE retains an active radio connection throughout the gap.

If coverage disappears before advance notification completes, the network may have less information about UE unreachability. A prediction does not guarantee successful signalling. Preparation time must allow for NTN delay, access attempts and the signalling exchange.

NR NTN: Informing the 5G Core

For NR satellite access, start with the core-network feature. UE and AMF exchange Unavailability Period Support during registration. When both support it, UE can report an expected coverage loss before becoming unreachable.

Release boundary: TS 23.501 V18.12.0 clause 5.4.13 explicitly notes that this release has no specified discontinuous-coverage support in the NR RAN specifications. The procedures described here are the 5GS enhancements. Do not copy the IoT NTN SIB32 idle-mode rules into NR or treat NR SIB19 as an equivalent SIB32.

How UE Learns About the Gap

UE needs information about future service at its location. Satellite visibility alone is insufficient because the prediction also needs the expected service-link and feeder-link connectivity. UE movement can change the result.

TS 23.501 clause 5.4.13.2 allows an external server to provide coverage availability information through a PDU Session or SMS. This version does not standardize the protocol and format for that delivery. The AMF can separately receive coverage availability information through O&M.

NR SIB19 service timing can describe a serving-area transition in the applicable RRC procedure. Such a timestamp does not by itself define every future coverage interval or negotiate core-network unavailability. Keep the RRC service-time information and the NAS unavailability information separate when reading a trace.

What UE Reports Before Losing Service

If UE expects to lose coverage and decides to remain without service, it triggers Mobility Registration Update under the supported feature. UE should start early enough to complete the procedure before becoming unavailable.

The information below describes the meaning of the exchange in TS 23.501 clauses 5.4.1.4 and 5.4.13.1. These are explanatory field descriptions, not an encoded NAS message example.

The AMF can determine or update the timing using its own information. If the predicted gap changes or no longer applies, UE updates the network. An old prediction should not silently remain the basis for reachability handling.

During the Gap and on Return

At the agreed start, AMF marks UE unavailable and treats it as unreachable until it enters CM-CONNECTED. The network should adjust reachability or implicit deregistration timers to avoid unintended deregistration during the expected absence.

UE handling of AMF-provided timing is implementation dependent. It may use that information to reduce activity, including deactivating NR satellite Access Stratum functions until coverage returns. This is not a requirement that every UE switch off its entire modem.

When the period ends, UE triggers registration unless AMF indicated that this return registration is not required. Initial Registration or Mobility Registration Update depends on UE state. The overload-control wait described later can delay UE-initiated NAS signalling. Expiry of a predicted interval alone does not prove that the network can already reach UE.

• Check support at both ends. This is an optional feature with an explicit capability exchange.
• Keep RRC and NAS state separate. Registration handling does not guarantee preserved radio resources.

IoT NTN: Radio Assistance and EPS Procedures

NB-IoT and eMTC NTN have explicit radio-side assistance for predicting coverage gaps. This helps UE avoid unnecessary idle-mode work while it expects no NTN service. EPS can additionally coordinate unavailability with the MME.

What SIB31, SIB32 and SIB33 Do

These SIBs answer different questions. UE needs assistance for accessing the current satellite, information for predicting later coverage, and potentially information for measuring neighbours. The table separates those roles before looking at UE behavior.

In SIB32, serviceInfo describes when a satellite will provide coverage. For Earth-moving cells, the network supplies TLE-based orbital parameters. For quasi-Earth-fixed cells, it supplies t-ServiceStart. The footprintInfo field describes the covered region using the applicable reference point, radius or elevation-angle information.

These values support prediction; the prediction algorithm remains up to UE implementation. UE needs to relate the coverage information to its own location and time. A satellite identifier by itself does not tell UE whether its current position is covered.

What UE Can Stop Doing During the Gap

TS 36.304 clause 4.1 defines the idle-mode handling. If UE has received SIB32 and determines from available satellite assistance that it is out of coverage, it keeps its AS configuration but need not perform NTN-related idle-mode tasks.

UE implementation handles running timers in this case. Once back in NTN coverage, UE performs the NTN idle-mode tasks again. If SIB32 includes a carrier-frequency list, UE may retain it for cell selection when those tasks resume. The NB-IoT variants use the corresponding NB system information.

This handling differs from PSM. Under the PSM rules in the same clause, running timers continue to run. Do not assume that the timer handling for a coverage gap and for PSM is identical just because both can reduce radio activity.

For connected-mode E-UTRA behavior, TS 36.331 clause 5.3.3.23 includes a specific condition: in a discontinuous-coverage scenario, if t-Service expires or UE is outside serving-cell coverage and T310 is running, UE stops T310 and leaves RRC_CONNECTED with release cause 'other'. This is not an unconditional instruction to release every connection at any predicted timestamp. If eNB detects that UE is outside coverage due to discontinuous coverage, it may request UE context release from MME.

What the MME Does

EPS adds an optional core-network procedure called Enhanced Discontinuous Coverage. UE and MME indicate support during Attach or TAU. For a predicted gap, UE sends a TAU Request with upcoming-loss-of-coverage information and timing when known.

MME can provide timing in TAU Accept and indicate whether UE need not perform TAU when the period ends. It also accounts for the absence in reachability and implicit-detach handling. Unless exempted, UE performs TAU on return, subject to the applicable overload-control wait.

These EPS procedures use MME and TAU, whereas the NR/5GC procedures use AMF and Registration. Similar intent does not make the message names interchangeable. For related radio parameters, see RRC (LTE) and RRC (NB IoT).

Worked Example: A 20 Minute Gap

Assume UE has service until 12:05:00 and expects service again at 12:25:00. The predicted gap is 1200 seconds. These are illustrative wall-clock times, not raw NAS field encodings or a prediction for a particular constellation.

Figure 2 assumes UE completes its advance notification at 12:04:30. UE begins acquisition preparation at 12:24:50 using an implementation-selected ten-second margin. For simplicity, assume it acquires a suitable cell at 12:25:00. Real acquisition can take longer or fail.

Figure 2. A predicted return, successful acquisition and permission to initiate NAS signalling are separate times.

Suppose the network previously provided a Maximum Time Offset of 30 seconds and UE selects a 12-second random wait on returning to coverage. In this example, ordinary UE-initiated NAS signalling waits until 12:25:12. This wait reduces the signalling surge when many UEs regain coverage together.

Under TS 23.501 clause 5.4.13.5, the NR UE stops this wait and initiates signalling if it receives paging, has pending emergency services or enters a TAI outside its registration area. EPS has corresponding exceptions, with the Tracking Area List, in TS 23.401 clause 4.13.8.6. The wait is therefore not an unconditional radio blackout.

Return registration or TAU is still conditional on the network indication and UE state. If the network exempted the return update and UE has no other reason to signal, timer expiry alone does not require a new transaction.

Now consider an uplink sample generated at 12:10:00. If the application retains it and UE first initiates access at 12:25:12, the sample has already waited 912 seconds. Access, signalling and data transfer add more delay. The application must choose whether such an old sample is still useful.

• 1200 seconds is the predicted service gap.
• 10 seconds is an illustrative preparation margin, not a standardized NTN timer.
• 12 seconds is this UE's example overload-control wait within a 30-second maximum.

Paging, Power Saving and Pending Data

UE can save energy by avoiding work that cannot succeed during a known gap. The network can avoid treating every missed response as an unexpected disappearance. Neither action guarantees delivery of traffic generated while UE is unreachable.

For NR/5GC, the core-network procedures can consider the gap when configuring periodic registration, eDRX and MICO where applicable. For IoT NTN/EPS, the corresponding choices include periodic TAU, eDRX and PSM. These mechanisms have their own support and configuration conditions.

High-latency communication features can support buffering and reachability reporting where deployed. Buffer location, capacity, expiry and application policy still matter. A twenty-minute gap does not imply that every downlink packet will be kept for twenty minutes. Likewise, storing uplink data in the application is a product decision, not an automatic consequence of receiving SIB32.

For a trace review, the checks below distinguish a prediction problem from an access problem or a reachability-management problem.

For service that can transfer to an available target, continue with NTN Handover. For a return that requires fresh access, the NTN RACH page explains the radio-access side.

For the listening schedules, EPS PSM, 5GS MICO and their energy/latency trade-offs, see Paging and Power Saving.

References

The explanations use the relevant clauses of the following Release 18 versions. The sequence and numerical timeline are explanatory examples. They are not captured traces or a claim that every NTN deployment enables these optional features.

• 3GPP TS 23.501 V18.12.0 : Clauses 5.4.1.4 and 5.4.13; NR satellite unavailability, coverage information, paging and overload control.
• 3GPP TS 23.401 V18.5.0 : Clause 4.13.8; enhanced discontinuous coverage for satellite access in EPS.
• 3GPP TS 36.300 V18.5.0 : Clauses 23.21.3 and 23.21.4; IoT NTN coverage gaps and mobility.
• 3GPP TS 36.304 V18.3.0 : Clause 4.1; NTN idle-mode tasks during gaps and after return.
• 3GPP TS 36.331 V18.5.0 : Clause 5.3.3.23 and SIB31/SIB32/SIB33 definitions with NB-IoT variants.