Content for  TS 23.501  Word version:  19.1.0

Reachability management is responsible for detecting whether the UE is reachable and providing UE location (i.e. access node) for the network to reach the UE. This is done by paging UE and UE location tracking. The UE location tracking includes both UE registration area tracking (i.e. UE registration area update) and UE reachability tracking ((i.e. UE periodic registration area update)). Such functionalities can be either located at 5GC (in the case of CM-IDLE state) or NG-RAN (in the case of CM-CONNECTED state). The UE and the AMF negotiate UE reachability characteristics for CM-IDLE state during Registration procedures. Three UE reachability categories are negotiated between UE and AMF for CM-IDLE state:

1. UE reachability allowing Mobile Terminated data while the UE is CM-IDLE state.
   • The UE location is known by the network on a Tracking Area List granularity
   • Paging procedures apply to this category.
   • Mobile originating and mobile terminated data apply in this category for both CM-CONNECTED and CM-IDLE state.
2. Mobile Initiated Connection Only (MICO) mode:
   • Mobile originated data applies in this category for both CM-CONNECTED and CM-IDLE state.
   • Mobile terminated data is only supported when the UE is in CM-CONNECTED state.
3. UE unreachability due to Unavailability Period:
   • Mobile originated data and Mobile terminated data are not transmitted in this category (handling of data by extending buffering may apply).
   • Paging procedure is not applicable to this category.

Whenever a UE in RM-REGISTERED state enters CM-IDLE state, it starts a periodic registration timer according to the periodic registration timer value received from the AMF during a Registration procedure. The AMF allocates a periodic registration timer value to the UE based on local policies, subscription information and information provided by the UE. After the expiry of the periodic registration timer, the UE shall perform a periodic registration. If the UE moves out of network coverage when its periodic registration timer expires, the UE shall perform a Registration procedure when it next returns to the coverage. The AMF runs a Mobile Reachable timer for the UE. The timer is started with a value longer than the UE's periodic registration timer whenever the CM state for the UE in RM-REGISTERED state changes to CM-IDLE. If the AMF receives an elapsed time from RAN when RAN initiate UE context release indicating UE unreachable, the AMF should deduce a Mobile Reachable timer value based on the elapsed time received from RAN and the normal Mobile Reachable timer value. The AMF stops the Mobile Reachable timer, if the UE CM state in the AMF moves to CM-CONNECTED state. If the Mobile Reachable timer expires, the AMF determines that the UE is not reachable. However, the AMF does not know for how long the UE remains not reachable, thus the AMF shall not immediately de-register the UE. Instead, after the expiry of the Mobile Reachable timer, the AMF should clear the PPF and shall start an Implicit De-registration timer, with a relatively large value. The AMF shall stop the Implicit De-registration timer and set the PPF if the AMF moves the UE CM state in the AMF to CM-CONNECTED state. If the UE indicates an Unavailability Period Duration, then AMF shall consider the UE as unreachable during the unreachability period as described in clause 5.4.1.4. If the UE is unreachable (i.e. the PPF is not set), the AMF does not page the UE and shall reject any request for delivering DL signalling or data to this UE. If the Implicit De-registration timer expires before the UE contacts the network, the AMF implicitly de-register the UE. As part of deregistration for a particular access (3GPP or non-3GPP), the AMF shall request the UE's related SMF to release the PDU Sessions established on that access.

The AMF considers a UE in RM-REGISTERED state to be reachable by CN paging if the UE CM state in the AMF is CM-IDLE state unless the UE applies MICO mode or the UE has indicated Unavailability Period Duration.

A UE may indicate preference for MICO mode during Initial Registration or Mobility Registration Update procedure. The AMF, based on local configuration, Expected UE Behaviour and/or Network Configuration parameters if available from the UDM, UE indicated preferences, UE subscription information and network policies, or any combination of them, determines whether MICO mode is allowed for the UE and indicates it to the UE during Registration procedure. If NWDAF is deployed, the AMF may also use analytics on UE mobility and/or UE communication generated by NWDAF (see TS 23.288) to decide MICO mode parameters. If the UE does not indicate preference for MICO mode during Registration procedure, the AMF shall not activate MICO mode for this UE. The UE and the AMF re- negotiate the MICO mode at every subsequent Registration procedure. When the UE is in CM-CONNECTED, the AMF may deactivate MICO mode by triggering Mobility Registration Update procedure through UE Configuration Update procedure as described in clause 4.2.4 of TS 23.502. The AMF assigns a registration area to the UE during the Registration procedure. When the AMF indicates MICO mode to a UE, the registration area is not constrained by paging area size. If the AMF serving area is the whole PLMN, based on local policy, and subscription information, may decide to provide an "all PLMN" registration area to the UE. In that case, re-registration to the same PLMN due to mobility does not apply. If Mobility Restrictions are applied to a UE in MICO mode, the AMF needs to allocate an Allowed Area/Non-Allowed Area to the UE as specified in clause 5.3.4.1. When the AMF indicates MICO mode to a UE, the AMF considers the UE always unreachable while the UE CM state in the AMF is CM-IDLE. The AMF rejects any request for downlink data delivery for UE in MICO mode and whose UE CM state in the AMF is CM-IDLE with an appropriate cause. For MT-SMS over NAS, the AMF notifies the SMSF that UE is not reachable, then the procedure of the unsuccessful Mobile terminating SMS delivery described in clause 4.13.3.9 of TS 23.502 is performed. The AMF also defers location services, etc. The UE in MICO mode is only reachable for mobile terminated data or signalling when the UE is in CM-CONNECTED. A UE in MICO mode need not listen to paging while in CM-IDLE. A UE in MICO mode may stop any access stratum procedures in CM-IDLE, until the UE initiates transition from CM-IDLE to CM-CONNECTED due to one of the following triggers:

• A change in the UE (e.g. change in configuration) requires an update of its registration with the network.
• Periodic registration timer expires.
• MO data pending.
• MO signalling pending (e.g. SM procedure initiated).

If a registration area that is not the "all PLMN" registration area is allocated to a UE in MICO mode, then the UE determines if it is within the registration area or not when it has MO data or MO signalling, and the UE performs Mobility Registration Update before the UE initiates the MO data or MO signalling if it is not within the registration area. A UE initiating emergency service shall not indicate MICO preference during Registration procedure. When the MICO mode is already activated in the UE, the UE and AMF shall locally disable MICO mode after PDU Session Establishment procedure for Emergency Services is completed successfully. The UE and the AMF shall not enable MICO mode until the AMF accepts the use of MICO mode in the next registration procedure. To enable an emergency call back, the UE should wait for a UE implementation-specific duration of time before requesting the use of MICO mode after the release of the emergency PDU session. In order to enable power saving for MT reachability e.g. for Cellular IoT, enhancements to MICO mode are specified in clause 5.31.7:

• MICO mode with Extended Connected Time.
• MICO mode with Active Time.
• MICO mode and Periodic Registration Timer Control.

During Registration procedure, the UE supporting the Unavailability Period feature provides "Unavailability Period Support" indication as part of 5GMM Core Network Capability in Registration Request message for initial registration and for every mobility registration. The AMF indicates whether the corresponding feature is supported in the AMF by providing the "Unavailability Period Support" indication in Registration Accept message. If the UE and network support Unavailability Period and an event is triggered in the UE that would make the UE unavailable or lose coverage (see clause 5.4.13.1) for a certain period of time, the UE uses Support of Unavailability Period to inform the AMF of the expected unavailability and whether it is due to NR satellite access discontinuous coverage. Use of Support of Unavailability Period for loss of coverage due to NR satellite access discontinuous coverage shall only be used if both UE and the AMF signalled "Unavailability Period Support", see clause 5.4.13.1. If the use of Support of Unavailability Period procedure is not due to NR satellite access discontinuous coverage, the UE may store its MM and SM context in the USIM or Non-Volatile memory in the ME to be able to reuse it after its unavailability period. If the UE can store its contexts the UE may trigger Mobility Registration Update procedure otherwise the UE shall trigger UE-initiated Deregistration procedure. Before the start of an event that makes the UE unavailable, the UE triggers either Mobility Registration Update or UE initiated Deregistration procedure:

1. If the UE initiates Mobility Registration Update procedure:
   0. The UE includes an Unavailability Type to describe the cause of unavailability (e.g. the unavailability caused by NR satellite access discontinuous coverage), the Start of the Unavailability Period if known and the Unavailability Period Duration (if known).
   1. If the UE did not include a Start of Unavailability Period, the AMF considers implicitly the Start of Unavailability Period to be the time at which it has received the Registration Request message from the UE. If the UE included a Start of Unavailability Period, the Start of Unavailability Period indicates the time at which the UE determines it expects to be unavailable, i.e. time until which the UE determines it is available.
   2. The AMF may determine, if not provided by the UE, or update the Unavailability Period Duration and/or the Start of Unavailability Period.
      If unavailability is caused by NR satellite access discontinuous coverage and the AMF knows an Unavailability Period Duration and/or the Start of Unavailability Period (e.g. based on the Unavailability Type and other information available to the AMF as described in clause 5.4.13.3), and the UE did not include an Unavailability Period Duration and/or the Start of Unavailability Period or the UE included an Unavailability Period Duration and/or the Start of Unavailability Period different to the Unavailability Period Duration and/or the Start of Unavailability Period known to the AMF, the AMF should include the Unavailability Period Duration and/or the Start of Unavailability Period known to the AMF in the Registration Accept and use those values in subsequent steps of this procedure. How the UE treats the AMF provided Unavailability Period Duration and/or the Start of Unavailability Period is up to UE implementation e.g. to help to determine when to return to coverage after a discontinuous coverage period, whether to listen to paging in eDRX, not to initiate any NAS signalling (including Service Request for MO data) within the discontinuous coverage period in case of any UL signalling/data request or the UE may deactivate its Access Stratum functions for NR satellite access in order to optimise power consumption until coverage returns, etc.
      If unavailability is not caused due to NR satellite access discontinuous coverage then AMF uses the Unavailability Period Duration and/or the Start of Unavailability Period as indicated by the UE in the subsequent steps of this procedure.
   3. The AMF indicates to the UE in the Registration Accept whether the UE is not required to perform a Registration procedure when the unavailability period has ended.
   4. The AMF may take the Unavailability Period Duration (if available) and Start of Unavailability Period into account when determining Periodic Registration Update timer value. The AMF may provide a Periodic Registration Update so the timer does not expire during the Unavailability Period to avoid interfering with the UE dealing with the event that causes the unavailability;
   5. The AMF stores the information that the UE is unavailable at the Start of Unavailability Period in UE context, and considers the UE is unreachable (i.e. clear the PPF in AMF) from then until the UE enters CM-CONNECTED state;
   6. While the UE is unreachable, all high latency communication solutions (see clause 5.31.8) apply if supported in the network, e.g. extended data buffering, downlink data buffering status report, etc; and
   7. If there is "Loss of Connectivity" event subscription for the UE by AF, the AMF at the start of Unavailability Period considers the remaining time in the Unavailability Period (if available) when constructing the "Loss of Connectivity" event report towards the NEF and the remaining time in the Unavailability Period is reported to the respective subscribed AF.
2. If the UE initiates UE-initiated Deregistration procedure:
   0. The UE includes Unavailability Period Duration (if known).
   1. If there is "Loss of Connectivity" event subscription for the UE by AF, the AMF considers the remaining time in the Unavailability Period when constructing the "Loss of Connectivity" event report towards the NEF and the Unavailability Period is reported to the respective subscribed AF;

Furthermore, if the UE initiates Initial Registration procedure and indicates supporting the Unavailability Period feature by providing "Unavailability Period Support" indication as part of 5GMM Core Network Capability, if the AMF is able to determine the Unavailability Period Duration and/or the Start of Unavailability Period of a UE during the UE's initial Registration procedure, the AMF should provide the Unavailability Period Duration and/or the Start of Unavailability Period to the UE in the Registration Accept message and follow the procedure described in bullet a), steps 2 to 7 above. Unless the AMF indicated that the UE is not required to perform a Registration procedure when the unavailability period has ended, then once the event which makes the UE unavailable is completed in the UE, the UE triggers a Registration procedure. If the event which makes the UE unavailable is delayed to a future time or cancelled in the UE or unavailability period deviates from negotiated value, the UE triggers Registration procedure. The UE may also trigger a Registration procedure before the Unavailability Period has started for other reasons. Depending on the UE state, the Registration procedure can be Initial Registration procedure or Mobility Registration Update procedure. While the UE is in 5GS and if the UE determines that an upcoming loss of coverage no longer applies or determines a new Start of Unavailability Period or Unavailability Period Duration related to the upcoming loss of coverage, the UE sends a new Mobility Registration Update Request to the AMF to update the Start of Unavailability Period and/or Unavailability Period Duration. The UE and the AMF re-negotiate unavailability at every Registration procedure, if it is required. If Start of Unavailability Period and/or Unavailability Period Duration is not included in a Registration procedure any pending unavailability configuration stored in the UE context at AMF is discarded. If the UE moves to EPS, the UE performs Attach or Tracking Area update procedure depending on the interworking mechanisms defined in clause 5.17.2. For discontinuous coverage in E-UTRAN satellite access in EPS, the "Unavailability Period" is also supported (see clause 4.13.8.2 of TS 23.401).

Based on operator configuration, the 5GS supports the AMF and NG-RAN to apply different paging strategies for different types of traffic. In the case of UE in CM-IDLE state, the AMF performs paging and determines the paging strategy based on e.g. local configuration, what NF triggered the paging and information available in the request that triggered the paging. If NWDAF is deployed, the AMF may also use analytics (i.e. statistics or predictions) on the UE's mobility as provided by NWDAF (see TS 23.288). In the case of UE in CM-CONNECTED with RRC_INACTIVE state, the NG-RAN performs paging and determines the paging strategy based on e.g. local configuration, and information received from AMF as described in clause 5.4.6.3 and SMF as described in clause 5.4.3.2. In the case of Network Triggered Service Request from SMF, the SMF determines the 5QI and ARP based on the downlink packet (if the SMF performs buffering) or the Downlink Data Report received from UPF (if the UPF performs buffering). The SMF includes the 5QI and ARP corresponding to the QoS Flow of the received downlink PDU in the request sent to the AMF. If the UE is in CM IDLE, the AMF uses e.g. the 5QI and ARP to derive different paging strategies as described in clause 4.2.3.3 of TS 23.502.

Paging policy differentiation is an optional feature that allows the AMF, based on operator configuration, to apply different paging strategies for different traffic or service types provided within the same PDU Session. In this Release of the specification this feature applies only to PDU Session of IP type. When the 5GS supports the Paging Policy Differentiation (PPD) feature, the DSCP value (TOS in IPv4 / TC in IPv6) is set by the application to indicate to the 5GS which Paging Policy should be applied for a certain IP packet. For example, as defined in TS 23.228, the P-CSCF may support Paging Policy Differentiation by marking packet(s) to be sent towards the UE that relate to a specific IMS services (e.g. conversational voice as defined in IMS multimedia telephony service). It shall be possible for the operator to configure the SMF in such a way that the Paging Policy Differentiation feature only applies to certain HPLMNs, DNNs and 5QIs. In the case of HR roaming, this configuration is done in the SMF in the VPLMN. In the case of Network Triggered Service Request and UPF buffering downlink packets, the UPF shall include the DSCP in TOS (IPv4) / TC (IPv6) value from the IP header of the downlink packet and an indication of the corresponding QoS Flow in the Downlink Data Report sent to the SMF. When PPD applies, the SMF determines the Paging Policy Indicator (PPI) based on the DSCP received from the UPF. In the case of Network Triggered Service Request and SMF buffering downlink packets, when PPD applies, the SMF determines the PPI based on the DSCP in TOS (IPv4) / TC (IPv6) value from the IP header of the received downlink packet and identifies the corresponding QoS Flow from the QFI of the received downlink packet. The SMF includes the PPI, the ARP and the 5QI of the corresponding QoS Flow in the N11 message sent to the AMF. If the UE is in CM IDLE, the AMF uses this information to derive a paging strategy, and sends paging messages to NG-RAN over N2. For a UE in RRC_INACTIVE state the NG-RAN may enforce specific paging policies in the case of NG-RAN paging, based on 5QI, ARP and PPI associated with an incoming DL PDU. To enable this, the SMF instructs the UPF to detect the DSCP in the TOS (IPv4) / TC (IPv6) value in the IP header of the DL PDU (by using a DL PDR with the DSCP for this traffic) and to transfer the corresponding PPI in the CN tunnel header (by using a QER with the PPI value). The NG-RAN can then utilize the PPI received in the CN tunnel header of an incoming DL PDU in order to apply the corresponding paging policy for the case the UE needs to be paged when in RRC_INACTIVE state. In the case of Home-Routed roaming, the V-SMF is responsible of controlling UPF setting of the PPI. In the case of PDU Session with I-SMF, the I-SMF is responsible of controlling UPF setting of the PPI.

Paging Priority is a feature that allows the AMF to include an indication in the Paging Message sent to NG-RAN that the UE be paged with priority. The decision by the AMF whether to include Paging Priority in the Paging Message is based on the ARP value in the message received from the SMF for an IP packet waiting to be delivered in the UPF. If the ARP value is associated with select priority services (e.g. MPS, MCS), the AMF includes Paging Priority in the Paging Message. When the NG-RAN receives a Paging Message with Paging Priority, it handles the page with priority. The AMF while waiting for the UE to respond to a page sent without priority receives another message from the SMF with an ARP associated with select priority services (e.g. MPS, MCS), the AMF sends another Paging message to the (R)AN including the Paging Priority. For subsequent messages, the AMF may determine whether to send the Paging message with higher Paging Priority based on local policy. For a UE in RRC_INACTIVE state, the NG-RAN determines Paging Priority based on the ARP associated with the QoS Flow as provisioned by the operator policy, and the Core Network Assisted RAN paging information from AMF as described in clause 5.4.6.3.

This clause applies when no radio capability signalling optimisation is used between a UE and the network. The UE Radio Capability information is defined in TS 38.300 and contains information on RATs that the UE supports (e.g. power class, frequency bands, etc). Consequently, this information can be sufficiently large that it is undesirable to send it across the radio interface at every transition of UE CM state in the AMF from CM-IDLE to CM-CONNECTED. To avoid this radio overhead, the AMF shall store the UE Radio Capability information during CM-IDLE state for the UE and RM-REGISTERED state for the UE and the AMF shall if it is available, send its most up to date UE Radio Capability information to the RAN in the N2 REQUEST message, i.e. INITIAL CONTEXT SETUP REQUEST or UE RADIO CAPABILITY CHECK REQUEST. The AMF deletes the UE radio capability when the UE RM state in the AMF transitions to RM-DEREGISTERED. When the AMF receives Registration Request with the Registration type set to Initial Registration or when it receives the first Registration Request after E-UTRA/EPC Attach with Registration type set to Mobility Registration Update, the AMF deletes the UE radio capability. The UE Radio Capability is maintained in the core network, even during AMF reselection. If the UE's NG-RAN or E-UTRAN UE Radio Capability information changes while in CM-IDLE state, the UE shall perform the Registration procedure with the Registration type set to Mobility Registration Update and it also includes "UE Radio Capability Update". (For specific requirements for a UE operating in dual-registration mode see clause 5.17.2.1). When the AMF receives Mobility Registration Update Request with "UE Radio Capability Update" requested by the UE, it shall delete any UE Radio Capability information that it has stored for the UE. If the UE's NG-RAN UE Radio Capability information changes when the UE is in CM-IDLE with Suspend, NAS shall trigger AS to establish a new RRC connection and not resume the existing one in order to perform the Registration procedure with the Registration type set to Mobility Registration Update including "UE Radio Capability Update". As a result of this, the access stratum in the UE will discard the AS information and establish a new RRC connection as defined in TS 36.331. If the trigger to change the UE's NG-RAN or E-UTRAN UE Radio Capability information happens when the UE is in CM-CONNECTED state, the UE shall first enter CM-IDLE state and then perform the Registration procedure with the Registration type set to Mobility Registration Update and it also includes "UE Radio Capability Update". The RAN stores the UE Radio Capability information, received in the N2 message or obtained from the UE, for the duration of the UE staying in RRC_CONNECTED or RRC_INACTIVE state. Before any 5G SRVCC handover attempt from NG-RAN to UTRAN, the RAN retrieves the UE's UTRA UE Radio Capabilities from the UE. (For specific requirements for a UE operating in dual-registration mode see clause 5.17.2.1). If the AMF sends N2 REQUEST (i.e. INITIAL CONTEXT SETUP REQUEST or UE RADIO CAPABILITY CHECK REQUEST) message to NG-RAN without UE Radio Capability information in that message and there is no UE Radio Capability information available in RAN, this triggers the RAN to request the UE Radio Capability from the UE and to upload it to the AMF in the N2 UE RADIO CAPABILITY INFO INDICATION message. If a UE supports both NB-IoT and other RATs the UE handles the UE Radio capability information as follows:

• When the UE is camping on NB-IoT the UE provides only NB-IoT UE radio capabilities to the network.
• When the UE is not camping on NB-IoT, the UE provides UE radio capabilities for the RAT but not NB-IoT UE radio capabilities to the network.

In order to handle the distinct UE radio capabilities, the AMF stores a separate NB-IoT specific UE Radio Capability information when the UE provides the UE Radio Capability information while camping on NB-IoT. When the UE is camping on NB-IoT, the AMF sends, if available, the NB-IoT RAT specific UE Radio Capability information to the E-UTRAN. When the UE is not camping on NB-IoT, the AMF sends, if available, UE radio capabilities for the RAT but not NB-IoT radio capabilities.

With the increase of the size of UE radio capabilities driven e.g. by additional frequency bands and combinations thereof for E-UTRA and NR, an efficient approach to signal UE Radio Capability Information over the radio interface and other network interfaces is defined with RACS. In this Release of the specification, RACS does not apply to NB-IOT. RACS works by assigning an identifier to represent a set of UE radio capabilities. This identifier is called UE Radio Capability ID. A UE Radio Capability ID can be either UE manufacturer-assigned or PLMN-assigned, as specified in clause 5.9.10. The UE Radio Capability ID is an alternative to the signalling of the UE Radio Capability information over the radio interface, within NG-RAN, from NG-RAN to E-UTRAN, from AMF to NG-RAN and between CN nodes supporting RACS. PLMN-assigned UE Radio Capability ID is assigned to the UE using the UE Configuration Update Command, or Registration Accept as defined in TS 23.502. The UCMF shall be configured with a Version ID for PLMN-assigned UE Radio Capability IDs, defined in clause 5.9.10. The UCMF (UE radio Capability Management Function) stores all UE Radio Capability ID mappings in a PLMN and is responsible for assigning every PLMN-assigned UE Radio Capability ID in this PLMN, see clause 6.2.21. The UCMF stores the UE Radio Capability IDs alongside the UE Radio Capability information and the UE Radio Capability for Paging they map to. Each UE Radio Capability ID stored in the UCMF can be associated to one or both UE radio capabilities formats specified in TS 36.331 and TS 38.331. The two UE radio capabilities formats shall be identifiable by the AMF and UCMF and the AMF shall store the TS 38.331 format only. An NG-RAN which supports RACS can be configured to operate with one of two modes of operation when providing the UE radio capabilities to the AMF when the NG-RAN executes a UE Radio Capability Enquiry procedure (see TS 38.331) to retrieve UE radio capabilities from the UE:

• Mode of operation A): The NG-RAN provides to the AMF both formats (i.e. the TS 38.331 format and TS 36.331 format). The NG-RAN derives one of the UE Radio Capability formats using local transcoding of the other format it receives from the UE and extracts the E-UTRAN UE Radio Capability for Paging and NR UE Radio Capability for Paging from the UE Radio capabilities.
• Mode of operation B): The NG-RAN provides to the AMF the TS 38.331 format only.

In a PLMN supporting RACS only in 5GS, Mode of Operation B shall be configured. If the PLMN supports RACS in both EPS and 5GS:

• If RAN nodes in the EPS and 5GS are configured in Mode of operation B, then the UCMF shall be capable to transcode between TS 36.331 and TS 38.331 formats and the UCMF shall be able to generate the RAT-specific UE Radio Capability for Paging information from the UE Radio Capability.
• If the NG-RAN is configured to operate according to Mode A, then also the E-UTRAN shall be configured to operate according to mode A and the UMCF is not required to transcode between TS 36.331 and TS 38.331 formats and the AMF shall provide the UE Radio Capability for Paging information.

When the NG-RAN updates the AMF with new UE radio capabilities information, the AMF provides the information obtained from the NG-RAN to the UCMF even if the AMF already has a UE Radio Capability ID for that UE. The UCMF then returns a value of UE Radio Capability ID. If the value is different from the one stored in the AMF, the AMF updates the UE Radio Capability ID it stores and provides this new value to the NG-RAN (if applicable) and to the UE. In order to be able to interpret the UE Radio Capability ID a Network Function or node may store a local copy of the mapping between the UE Radio Capability ID and its corresponding UE Radio Capability information i.e. a dictionary entry. When no mapping is available between a UE Radio Capability ID and the corresponding UE Radio Capability information in a Network Function or node, this Network Function or node shall be able to retrieve this mapping and store it.

• An AMF which supports RACS shall store such UE Radio Capability ID mapping at least for all the UEs that it serves that have a UE Radio Capability ID assigned.
• The NG-RAN performs local caching of the UE Radio Capability information for the UE Radio Capability IDs for the UEs it is serving, and potentially for other UE Radio Capability IDs according to suitable local policies.
• When the NG-RAN needs to retrieve the mapping of a UE Radio Capability ID to the corresponding UE Radio Capability information, it queries the AMF using N2 signalling defined in TS 38.413.
• When the AMF needs to obtain a PLMN-assigned UE Radio Capability ID for a UE from the UCMF, it provides the UE Radio Capability information it has for the current radio configuration of the UE and the IMEI/TAC for the UE and the UCMF returns a UE Radio Capability ID. The AMF shall provide to the UCMF the UE Radio Capability information (and at least in Mode A, the UE Radio Capability for Paging) obtained from the NG-RAN in one or both the TS 36.331 and TS 38.331 formats depending on how the RAN is configured. The UCMF stores the association of this IMEI/TAC with this UE Radio Capability ID and the UE Radio Capability information and the UE Radio Capability for Paging in all the formats it receives. The UE Radio Capability information formats the AMF provides shall be identifiable at the UCMF.
• When the AMF needs to obtain the UE Radio Capability information and the UE Radio Capability for Paging associated to a UE Radio Capability ID it provides the UE Radio Capability ID to the UCMF with an indication that it is requesting the TS 38.331 format and the UCMF returns a mapping of the UE Radio Capability ID to the corresponding UE Radio Capability information in TS 38.331 format to the AMF.
• UEs, AMFs and RAN nodes which support RACS learn the current value of the Version ID when a new PLMN-assigned UE Radio Capability ID is received from the UCMF and the Version ID it contains is different from the ones in their PLMN Assigned UE Radio Capability ID cache. For a PLMN, PLMN-assigned UE Radio Capability IDs related to old values (i.e. not current value) of the Version ID can be removed from cache but, if so, prior to removing any cached PLMN-assigned UE radio Capability IDs with the current value of the Version ID. The AMF, RAN and UE may continue to use the stored PLMN assigned UE Radio Capability IDs with old values of the Version ID, until these are purged from cache. If an out of date PLMN assigned UE Radio Capability ID is removed form an AMF cache, the AMF shall proceed to assign a new PLMN assigned UE Radio Capability ID to all the UEs for which the UE context includes the removed PLMN-assigned UE Radio Capability ID using a UE Configuration Update procedure, or when these UEs perform a Registration. If the AMF attempts to resolve a PLMN assigned UE Radio capability ID with an old Version ID, the UCMF shall return an error code indicating that the Version ID in the UE radio capability ID is no longer current and proceed to assign a new UE Radio Capability ID to the UE.
  If at any time the AMF has neither a valid UE Radio Capability ID nor any stored UE radio capabilities for the UE, the AMF may trigger the RAN to provide the UE Radio Capability information and subsequently request the UCMF to allocate a UE Radio Capability ID.
• The RAN, in order to support MOCN network sharing scenarios, shall be capable to cache PLMN assigned UE Radio Capability IDs per PLMN ID.

A network may utilise the PLMN-assigned UE Radio Capability ID, without involving the UE, e.g. for use with legacy UEs. Mutual detection of the support of the RACS feature happens between directly connected NG-RAN nodes and between NG-RAN and AMF using protocol means as defined in TS 38.413 and TS 38.423. To allow for a mix of RACS-supporting and non-RACS-supporting RAN nodes over the Xn interfaces, the UE Radio Capability ID should be included in the Path Switch signalling during Xn based handover and Handover Request during N2 based handover between AMF and NG-RAN. In addition, RACS-supporting RAN nodes can be discovered across inter-CN node boundaries by using the mechanism defined in TS 38.413 that allows the source NG-RAN node to retrieve information on the level of support for a certain feature at the target NG-RAN side by means of information provided within the Source to Target and Target to Source transparent handover containers during handover procedure. The support of RACS by peer AMFs or MMEs is based on configuration in a PLMN or across PLMNs. A UE that supports WB-E-UTRA and/or NR indicates its support for RACS to AMF using UE MM Core Network Capability as defined in clause 5.4.4a. A UE that supports RACS and stores an applicable UE Radio Capability ID for the current UE Radio Configuration in the PLMN, shall signal the UE Radio Capability ID in the Initial, and Mobility Registration procedure as defined in TS 23.502 and based on triggers defined in TS 24.501. If both PLMN-assigned for the current PLMN and UE manufacturer-assigned UE Radio Capability IDs are stored in the UE and applicable in the PLMN, the UE shall signal the PLMN-assigned UE Radio Capability ID in the Registration Request message. When a PLMN decides to switch to request a particular type of UE to use UE manufacturer-assigned UE Radio Capability ID(s):

• The UCMF sends a Nucmf_UECapabilityManagement_Notify message to the AMF including either a list of UE Radio Capability IDs (if the UE was previously using any PLMN-assigned IDs) or the IMEI/TAC values corresponding to UE types that are requested to use UE manufacturer-assigned UE Radio Capability ID. These values are stored in a "UE Manufacturer Assigned operation requested list" in the AMF.
• The AMF uses the Registration Accept message or the UE Configuration Update command message to request the UE to delete all the PLMN-assigned UE Radio Capability ID(s) for this PLMN if the UE is, respectively, registering or is registered with PLMN-assigned ID or IMEI/TAC values matching one value in the "UE Manufacturer Assigned operation requested list".
• a UE that receives indication to delete all the PLMN-assigned UE Radio Capability IDs in the Registration Accept message, or UE Configuration Update command message, shall delete any PLMN-assigned UE Radio Capability IDs for this PLMN. The UE proceeds to register with a UE manufacturer-assigned UE Radio Capability ID that is applicable to the current UE Radio configuration.
• When the "UE Manufacturer Assigned operation requested list" contains PLMN-assigned UE Radio Capability IDs, the UCMF shall avoid re-assigning PLMN-assigned UE Radio Capability IDs that were added to the "UE Manufacturer Assigned operation requested list" in the AMFs to any UE.
• The AMF stores a PLMN-assigned ID in the "UE Manufacturer Assigned operation requested list" for a time duration that is implementation specific, but IMEI/TACs are stored until the UCMF require to remove certain TACs from the list (i.e. the list of IMEI/TACs which are requested to use UE manufacturer-assigned IDs in the AMF and UCMF is synchronised at all times).
• The UCMF can request at any time the AMF to remove PLMN-assigned ID(s) or IMEI/TAC(s) values from the UE manufacturer-assigned operation requested list.

The serving AMF stores the UE Radio Capability ID related to selected PLMN for a UE in the UE context and provides this UE Radio Capability ID to NG-RAN as part of the UE context information using N2 signalling. During inter PLMN mobility, the new AMF shall delete the UE Radio Capability ID received from the old AMF, unless the operator policy indicates that all UE Radio Capability IDs used in the old PLMN is also valid in the new PLMN. The UE stores the PLMN-assigned UE Radio Capability ID in non-volatile memory when in RM-DEREGISTERED state and can use it again when it registers in the same PLMN. At any given time at most one UE Radio Capability ID is used from the UE context in CN and RAN which is related to the selected PLMN. The number of PLMN-assigned UE Radio Capability IDs that the UE stores in non-volatile memory is left up to UE implementation. However, to minimise the load (e.g. from radio signalling) on the Uu interface and to provide smoother inter-PLMN mobility (e.g. at land borders) the UE shall be able to store at least the latest 16 PLMN-assigned UE Radio Capability IDs (along with the PLMN that assigned them). This number is independent of the UE manufacturer-assigned UE Radio Capability ID(s) the UE may store. It shall be possible for a UE to change, e.g. upon change in its usage settings, the set of UE radio capabilities in time and signal the associated UE Radio Capability ID, if available. The UE stores the mapping between the UE Radio Capability ID and the corresponding UE Radio Capability Information for every UE Radio Capability ID it stores. If the UE's Radio Capability Information changes and regardless of whether the UE has an associated UE Radio Capability ID for the updated UE Radio Capability information, the UE shall perform the Registration procedure by sending a Registration Request message to the AMF with the Registration type set to Mobility Registration Update which includes "UE Radio Capability Update" and:

• If the UE has an associated UE Radio Capability ID for the updated UE Radio Capability information, the UE shall include it in the Registration Request message so that the AMF, upon receiving it, shall update the UE's context with this UE Radio Capability ID.
• If the UE does not have an associated UE Radio Capability ID for the updated UE Radio Capability information, the UE shall not include any UE Radio Capability ID in the Registration Request message so that the AMF, upon receiving this Registration Request without any UE Radio Capability ID, retrieves the UE radio capabilities from the UE as defined in clause 5.4.4.1.

The NG-RAN may apply RRC filtering of UE radio capabilities when it retrieves the UE Radio Capability Information from the UE as defined in TS 38.331. If a UE supports both NB-IoT and other RATs that do support RACS (e.g. WB-E-UTRA and/or NR) then (since there is no support for RACS in NB-IoT) the UE handles the RACS procedures as follows:

• NB-IoT specific UE Radio Capability Information is handled in UE, NG-RAN and AMF according to clause 5.4.4.1 and in EPS according to TS 23.401.
• when the UE is not camping on NB-IoT, the RAN provides UE radio capabilities for other RATs but not NB-IoT UE radio capabilities, according to TS 38.300 and TS 36.300. As a result the UE Radio Capability ID that is assigned by the network corresponds only to the UE radio capabilities of the non-NB-IoT RATs. The UE uses the UE Radio Capability IDs assigned only in Mobility Registration Update procedures performed over non-NB-IoT RATs.

Support for RACS in EPS is defined in TS 23.401.

If the AMF requires more information on the UE radio capabilities support to be able to set the IMS voice over PS Session Supported Indication (see clause 5.16.3), then the AMF may send a UE Radio Capability Match Request message to the NG-RAN. This procedure is typically used during the Registration Procedure or when AMF has not received the Voice Support Match Indicator (as part of the 5GMM Context).

The paging assistance information contains UE radio related information that assists the RAN for efficient paging. The Paging assistance information contains:

1. UE radio capability for paging information:
   • The UE Radio Capability for Paging Information contains information derived by the NG-RAN node (e.g. band support information) from the UE Radio Capability information. The AMF stores this information without needing to understand its contents.
     As the AMF only infrequently (e.g. at Initial Registration) prompts the NG-RAN to retrieve and upload the UE radio capabilities i.e. UE Radio Capability information to the AMF, and the AMF may be connected to more than one NG-RAN RAT, it is the responsibility of the NG-RAN to ensure that UE Radio Capability for Paging Information (which is derived by the NG-RAN node) contains information on all NG-RAN RATs that the UE supports in that PLMN. To assist the NG-RAN in this task, as specified in TS 38.413, the AMF provides its stored UE Radio Capability for Paging Information in every NG-AP INITIAL CONTEXT SETUP REQUEST message sent to the NG-RAN.
   • The UE Radio Capability for Paging Information is maintained in the core network, even during AMF reselection, and is stored in the UCMF alongside the UE Radio Capability information associated to a UE Radio Capability ID.
2. Information On Recommended Cells And RAN nodes For Paging:
   • Information sent by the NG-RAN, and used by the AMF when paging the UE to help determining the NG RAN nodes to be paged as well as to provide the information on recommended cells to each of these RAN nodes, in order to optimize the probability of successful paging while minimizing the signalling load on the radio path.
   • The RAN provides this information during N2 release.

Core Network assistance information for RAN aids the RAN to optimize the UE state transition steering and the RAN paging strategy formulation in RRC_INACTIVE state. The Core Network assistance information includes the information set, Core Network assisted RAN parameters tuning, which assist RAN optimize the UE RRC state transition and CM state transition decision. It also includes the information set, Core Network assisted RAN paging information, which assist RAN to formulate an optimized paging strategy when RAN paging is triggered.

Core Network assisted RAN parameters tuning aids the RAN to minimize the UE state transitions and achieve optimum network behaviour. How the RAN uses the CN assistance information is not defined in this specification. Core Network assisted RAN parameters tuning may be derived by the AMF per UE in the AMF based on collection of UE behaviour statistics, Expected UE Behaviour and/or other available information about the UE (such as subscribed DNN, SUPI ranges, or other information). If the AMF maintains Expected UE Behaviour parameters, Network Configuration parameters (as described in clauses 4.15.6.3 or 4.15.6.3a of TS 23.502) or SMF derived CN assisted RAN parameters tuning, the AMF may use this information for selecting the CN assisted RAN parameter values. If the AMF is able to derive the Mobility Pattern of the UE (as described in clause 5.3.4.2), the AMF may take the Mobility Pattern information into account when selecting the CN assisted RAN parameter values. The SMF uses the SMF-Associated parameters (e.g. Expected UE Behaviour parameters or Network Configuration parameters of the UE) to derive the SMF derived CN assisted RAN parameters tuning. The SMF sends the SMF derived CN assisted RAN parameters tuning to the AMF during the PDU Session establishment procedure and if the SMF-Associated parameters change the PDU Session modification procedure is applied. The AMF stores the SMF derived CN assisted RAN parameters tuning in the PDU Session level context. The AMF uses the SMF derived CN assisted RAN parameters tuning to determine a PDU Session level "Expected UE activity behaviour" parameters set, which may be associated with a PDU Session ID, as described below in this clause. The Expected UE Behaviour parameters or the Network Configuration parameters can be provisioned by external party via the NEF to the AMF or SMF, as described in clause 5.20. The CN assisted RAN parameters tuning provides the RAN with a way to understand the UE behaviour for these aspects:

• "Expected UE activity behaviour", i.e. the expected pattern of the UE's changes between CM-CONNECTED and CM-IDLE states or the duration of CM-CONNECTED state. This may be derived e.g. from the statistical information, or Expected UE Behaviour or from subscription information. The AMF derives one or more sets of the "Expected UE activity behaviour" parameters for the UE as follows:
  • AMF may derive and provide to the RAN a UE level of "Expected UE activity behaviour" parameters set considering the Expected UE Behaviour parameters or Network Configuration parameters received from the UDM (see clauses 4.15.6.3 or 4.15.6.3a of TS 23.502) and the SMF derived CN assisted RAN parameters tuning associated with a PDU Session using Control Plane CIoT 5GS Optimisation. This set of "Expected UE activity behaviour" parameters is valid for the UE; and
  • AMF may provide to the RAN a PDU Session level "Expected UE activity behaviour" parameters set, e.g. considering the SMF derived CN assisted RAN parameters tuning, per established PDU Session. The PDU Session level "Expected UE activity behaviour" set of parameters is associated with and valid for a PDU Session ID. The RAN may consider the PDU Session level "Expected UE activity behaviour" parameters when the User Plane resources for the PDU Session are activated;
• "Expected HO behaviour", i.e. the expected interval between inter-RAN handovers. This may be derived by the AMF e.g. from the Mobility Pattern information;
• "Expected UE mobility", i.e. whether the UE is expected to be stationary or mobile. This may be derived e.g. from the statistical information or Expected UE Behaviour parameters or from subscription information;
• "Expected UE moving trajectory" which may be derived e.g. from the statistical information or Expected UE Behaviour parameters or from subscription information; or
• "UE Differentiation Information" including the Expected UE Behaviour parameters excluding the Expected UE moving trajectory (see clause 4.15.6.3 of TS 23.502) to support Uu operation optimisation for NB-IoT UE differentiation if the RAT type is NB-IoT.

The AMF decides when to send this information to the RAN as "Expected UE activity behaviour" carried in N2 request over the N2 interface (see TS 38.413).

Core Network assisted RAN paging information aids the RAN to formulate a RAN paging policy and strategy in RRC_INACTIVE state, besides the PPI and QoS information associated to the QoS Flows as indicated in clause 5.4.3. CN assisted RAN paging information may be derived by the AMF per UE and/or per PDU Session based on collection of UE behaviour statistics, Expected UE Behaviour and/or other available information about the UE (such as subscribed DNN, SUPI ranges, Multimedia priority service), and/or information received from other network functions when downlink signalling is triggered. The CN assisted RAN paging information consists of a service priority (values 1 to 256) which provides AN with a way to understand how important the downlink signalling is. The AMF derives this service priority based on available information as described above. The method to derive the service priority is implementation depended and can be controlled by operator. The Core Network may provide the CN assisted RAN paging information to RAN in different occasions, e.g. during downlink N1 and N2 message delivery, etc.

The RAN and UE may use a Wake Up Signal (WUS) to reduce the UE's idle mode power consumption. The RAN sends the WUS shortly before the UE's paging occasion. The WUS feature enables UEs to determine that in the paging occasions immediately following their WUS occasion they will not be paged if their WUS is not transmitted, or that they might be paged if their WUS is transmitted (see TS 36.304). To avoid waking up UEs due to an AMF paging other UEs across multiple cells (e.g. due to frequent UE mobility and/or for low paging latency services such as VoLTE), the use of WUS by the ng-eNB and the UE is restricted to the last used cell, i.e. the cell in which the UE's RRC connection was last released. To support this:

1. ng-eNBs should provide the Recommended Cells for Paging IE in the Information on Recommended Cells and RAN Nodes for Paging IE (see TS 38.413) to the AMF in the NGAP UE Context Release Complete, UE Context Suspend Request and UE Context Resume Request messages;
2. if received during the last NGAP UE Context Release Complete or UE Context Suspend Request message, the AMF provides (without modification) the Recommended Cells for Paging as Assistance Data for Recommended Cells IE in the Assistance Data for Paging IE within the NGAP Paging message to the RAN (see also TS 38.413); and
3. the AMF shall delete (or mark as invalid) the Information On Recommended Cells And RAND nodes For Paging when a new NGAP association is established for the UE.

In the NGAP Paging message, the last used cell ID is sent in the Assistance Data for Recommended Cells IE in the Assistance Data for Paging IE (see TS 38.413). When receiving an NGAP Paging message for a WUS-capable UE that also includes the Assistance Data for Recommended Cells IE then a WUS-capable ng-eNB shall only broadcast the WUS on the cell that matches the last used cell ID.

To support the Wake Up Signal (WUS), the WUS Assistance Information is used by the ng-eNB to help determine the WUS group used when paging the UE (see TS 36.300). The content of the WUS Assistance Information consists of the paging probability information. The paging probability information provides a metric on the probability of a UE receiving a paging message based on, e.g. statistical information. The UE may in the Registration Request message provide its capability to support receiving WUS Assistance Information. If WUS Assistance Information is supported by the UE, then the UE in the Registration Request message may provide the additional UE paging probability information. The AMF may use the UE provided paging probability, local configuration and/or previous statistical information for the UE, when determining the WUS Assistance Information. If the UE supports WUS Assistance Information, the AMF may assign WUS Assistance Information to the UE, even when the UE has not provided the additional UE paging probability information. If the AMF has determined WUS Assistance Information for the UE, the AMF provides it to the UE in every Registration Accept message. The AMF stores the WUS Assistance Information parameter in the MM context and provides it to the ng-eNB when paging the UE. UE and AMF shall not signal WUS Assistance Information in Registration Request, Registration Accept messages when the UE has an active emergency PDU session.

This clause describes the specific aspects for NR satellite access.

In case of NR satellite access, the RAT Types values "NR(LEO)", "NR(MEO)", "NR(GEO)" and "NR(OTHERSAT)" are used in 5GC to distinguish the different NR satellite access types (see clause 5.4.10). When a UE is accessing to the network via satellite access, the AMF determines the RAT type as specified in clause 5.4.10.

In order to ensure that the regulatory requirements are met, the network may be configured to enforce that the selected PLMN is allowed to operate in the current UE location by verifying the UE location during Mobility Management and Session Management procedures. The UE that supports network verified UE location over NTN NR shall indicate this capability in UE 5GMM Core Network Capability and LPP as defined in TS 37.355. In this case, when the AMF receives a NGAP message containing User Location Information for a UE using NR satellite access, the AMF takes into account the capability of the UE in UE 5GMM Core Network Capability for the support by the UE of network verified UE location over NR NTN and may decide to verify the UE location. If the AMF determines based on the Selected PLMN ID and ULI (including Cell ID) received from the gNB that it is not allowed to operate at the present UE location the AMF should reject any NAS request with a suitable cause value. If the UE is already registered to the network when the AMF determines that it is not allowed to operate at the present UE location, the AMF may initiate deregistration of the UE. The AMF should not reject the request or deregister the UE unless it has sufficiently accurate UE location information to determine that the UE is located in a geographical area where the PLMN is not allowed to operate. If the AMF, based on the ULI, is not able to determine the UE's location with sufficient accuracy to make a final decision or if the received ULI is not sufficiently reliable, the AMF takes into account the UE 5GMM Core Network Capability related to the UE support of network verified UE location over NR NTN and may proceed with the Mobility Management or Session Management procedure and may initiate UE location procedure after the Mobility Management or Session Management procedure is complete, as specified in clause 6.10.1 of TS 23.273, to determine the UE location. The AMF shall be prepared to deregister the UE if the information received from LMF indicates that the UE is registered to a PLMN that is not allowed to operate in the UE location. In the case of a NAS procedure, the AMF should either reject any NAS request targeted towards a PLMN that is not allowed to operate in the known UE location and indicate a suitable cause value, or accept the NAS procedure and initiate deregistration procedure once the UE location is known. In the deregistration message to the UE, the AMF shall include a suitable cause value. For UE processing of the cause value indicating that the PLMN is not allowed to operate in the current UE location, see TS 23.122 and TS 24.501. In the case of a handover procedure, if the (target) AMF determines that it is not allowed to operate at the current UE location, the AMF either rejects the handover, or accepts the handover and later deregisters the UE.

Network selection principles specified in clause 5.2.2 apply also for NR satellite access. For NR satellite access, a UE with location capability should use its awareness of its location to select a PLMN that is allowed to operate in the UE location as specified in TS 23.122. In order to ensure that the regulatory requirements are met, the network may be configured to enforce this UE choice by verifying the UE location, as described in clause 5.4.11.4.

A moving radio cell for NR satellite access may indicate support for one or more TACs for each PLMN. A UE that is registered with a PLMN may access a radio cell and does not need to perform a Mobility Registration Update procedure as long as at least one supported TAC for the RPLMN or equivalent to the RPLMN is part of the UE Registration Area. A UE shall perform a Mobility Registration Update procedure when accessing a radio cell where none of the supported TACs for the RPLMN or equivalent to the RPLMN are part of the UE Registration Area. When indicating a last visited TAI in a Registration Update, a UE may indicate any TAI supported in a radio cell for the RPLMN or equivalent to the RPLMN for the last UE access prior to the Registration Update that is part of the UE Registration Area.

In the case of NR satellite access with moving cells, in order to ensure that each TA is Earth-stationary even if the radio cells are moving across the Earth's surface, the NG-RAN may change the TAC values that are broadcast in a cell's system information as the cell moves, as described in TS 38.300 and TS 38.331. NG-RAN may broadcast in a cell a single TAC per PLMN and change that TAC value as the cell moves. Alternatively, the NG-RAN may broadcast in a cell more than one TAC for a PLMN and add or remove TAC values as the cell moves. The NG-RAN provides either the single broadcast TAI or all broadcast TAIs corresponding to the Selected PLMN as described in TS 38.413 to the AMF as part of the ULI, whenever the ULI is included in the NGAP message as described in TS 38.413. The NG-RAN indicates, if known, also the TAI where the UE is geographically located. When supplying location information to another NF (e.g. SMF, PCF), the AMF shall include the TAI where the UE is located (if known) and the broadcast TAI(s), excluding all forbidden TAI(s).

Forbidden Area functionality is supported as described in clause 5.3.4.1.1 with the modifications described below:

• The AMF and the UE receive the broadcast TAI (if a single TAI is broadcast) or all broadcast TAIs (if multiple TAIs are broadcast) from the NG-RAN as described clause 5.4.11.7. The AMF considers the UE to be in a Forbidden Area if the only received TAI is forbidden or if all received TAIs are forbidden based on subscription data. The UE considers it is in a Forbidden Area if the only received TAI is forbidden, or if all received TAIs are forbidden and is not within a Forbidden Area in the case that at least one broadcast TAI is not forbidden.
• If AMF receives multiple TAIs from the NG-RAN and determines that some, but not all of them are forbidden by subscription or by operator policy, the AMF shall send the forbidden TAI(s) to the UE as described in clauses 4.2.2.2 and 4.2.3 in TS 23.502. The UE stores the TAI(s) in the appropriate Forbidden Area list and removes the TAI(s) from Registration Area if present.

Service Area Restrictions functionality is supported as described in clause 5.3.4.1.2 with the modifications described below:

• The AMF receives the broadcast TAI (if a single TAI is broadcast) or all broadcast TAIs (if multiple TAIs are broadcast) from the NG-RAN as described clause 5.4.11.7. The AMF provides the UE with Service Area Restrictions which consist of either Allowed Areas or Non-Allowed Areas, as described in clause 5.3.4.1.2. The UE and AMF consider the UE to be in a Non-Allowed Area if none of the broadcast TAIs is Allowed. The UE and AMF consider the UE to be in an Allowed Area if at least one broadcast TAI is allowed.

The RAN and UE may use a Paging Early Indication with Paging Subgrouping (PEIPS) to reduce the UE's power consumption in RRC_IDLE and RRC_INACTIVE over NR (see TS 38.304). The paging subgrouping can be based on either the UE's temporary ID or a Paging Subgroup ID allocated by the AMF. Paging subgrouping based on the UE's temporary ID is implemented within the NG-RAN. For paging subgrouping based on UE's temporary ID, the UE's support is included in the UE Radio Capability for Paging, either derived by the NG-RAN from UE provided UE radio capability (see clause 5.4.4) or based on UE Radio Capability ID if UE radio capability signalling optimisation is used (see clause 5.4.4.1a). The AMF, when determining its paging strategy (see clause 5.4.3), should take into consideration whether a gNB is using Paging subgrouping based on the UE's temporary ID. If paging subgroups are being allocated by the AMF, then all AMFs connected to one gNB (including the AMFs in different PLMNs using 5G MOCN network sharing) shall use a consistent policy in allocating UEs to the paging subgroups. The AMF may configure up to 8 different Paging Subgroup IDs. The NG-RAN node and the UE determine per cell which paging subgrouping method to use as defined in TS 38.304 and TS 38.331.

To support the Paging Early Indication with Paging Subgrouping (PEIPS), Paging Subgrouping Support Indication and the PEIPS Assistance Information is used by the AMF and NG-RAN to help determine whether PEIPS applies to the UE and which paging subgroup used when paging the UE (see TS 38.300). In the Registration Request message, the Paging Subgrouping Support Indication indicates whether the UE supports PEIPS with AMF PEIPS Assistance Information. If the UE includes Paging Subgrouping Support Indication, the UE may also include the paging probability information to assist the AMF. If the AMF supports PEIPS assistance and if the UE provided Paging Subgrouping Support Indication, the AMF stores the indication in the UE context in AMF. The AMF may use local configuration, the UE's paging probability information if provided, information provided by the RAN (e.g. any of the Information On Recommended Cells And RAN nodes For Paging), and/or previous statistical information for the UE to determine the AMF PEIPS Assistance Information. The AMF PEIPS Assistance Information includes the Paging Subgroup ID. If the AMF has determined AMF PEIPS Assistance Information for the UE, the AMF stores it in the UE context in AMF and provides it to the UE in every Registration Accept message. If the AMF has determined AMF PEIPS Assistance Information, the AMF shall provide it to NG RAN when paging the UE. In addition, in order to support PEIPS for UEs in RRC_INACTIVE mode, the AMF shall provide the AMF PEIPS Assistance Information to NG-RAN as part of the RRC Inactive Assistance Information. The NG-RAN chooses on a per-cell basis whether to use PEIPS and which paging subgrouping mechanism to use. When using AMF allocated subgroups, both the UE and NG-RAN use the AMF PEIPS Assistance Information to determine the paging subgroup to apply as defined in TS 38.300. The AMF may use the UE Configuration Update procedure (as described in clause 4.2.4 of TS 23.502) and N2 UE Context Modification procedure (as described in clause 8.3.4 of TS 38.413) to update the AMF PEIPS Assistance Information in the UE and NG-RAN. When the UE has an active emergency PDU Session:

• The UE shall not signal Paging Subgrouping Support Indication in the Registration Request message.

The present clause 5.4.13 provides optional enhancements to support discontinuous coverage:

• Mobility management and power saving optimization, see clause 5.4.13.1; and
• Coverage availability information provisioning to the UE, see clause 5.4.13.2; and
• Coverage availability information provisioning to the AMF, see clause 5.4.13.3; and
• Paging, see clause 5.4.13.4; and
• Overload control, see clause 5.4.13.5.

For NR satellite access that provides discontinuous network coverage the Mobility Management and Power Saving Optimization functionality may be used. If both the UE and the network support "Unavailability Period Support", and if the UE determines it will lose coverage and will become unavailable, and the UE decides to remain in no service during that time, then:

• the UE triggers the Mobility Registration Update procedure to inform the network of its unavailability, as described in clause 5.4.1.4.
• The UE may be able to determine, including considering current and expected future locations of the UE, a Start of Unavailability Period and/or Unavailability Period Duration for when it expects to be out of coverage and include them in the Mobility Registration Update procedure, as described in clause 5.4.1.4.
• The UE should trigger the Mobility Registration Update procedure early enough such that the procedure, under normal conditions, is able to complete before the start of the unreachability period.

In case the UE requests power saving features the AMF uses the procedures defined in other clauses to provide the UE with timers (e.g. Periodic Registration Update timer), extended DRX in CM-IDLE configuration (see clause 5.31.7.2), and MICO mode configuration (see clause 5.4.1.3), and to provide the NG-RAN with Extended Connected Time (see clause 5.31.7.3) and may also consider the Unavailability Period Duration and Start of Unavailability Period (if available). This is to keep UE in power saving mode and avoid the network attempting to page the UE if it is out of satellite network coverage. The AMF should adjust the mobile reachable timer or Implicit Deregistration timer or both such that the AMF does not implicitly deregister the UE while the UE is unavailable, see clause 5.4.1. Features described for High latency communication in clause 5.31.8 may be used to handle mobile terminated (MT) communication with UEs being unreachable due to NR satellite access discontinuous coverage and the Unavailability Period Duration (if available) and Start of Unavailability Period (if available) may be used when determining the Estimated Maximum Wait Time. Tracking Area or RAT specific configuration in the AMF may be used to set timer values based on typical coverage periods of a satellite system. The UE may send Mobility Registration Update procedure to inform the network of its UE unavailability period (see clause 5.4.1.4) even if Mobility Management back-off timer is running.

A UE may use satellite coverage availability information for satellite access to support discontinuous coverage operations. Satellite coverage availability information can be provided to a UE by an external server via a PDU Session or SMS. The protocol and format of satellite coverage availability information via PDU session or SMS is not defined in this release of the specification, but some examples on possible information that constitutes the satellite coverage availability information is defined in Annex Q.

The AMF may use satellite coverage availability information to support satellite access by UEs with discontinuous coverage operation. Satellite coverage availability information may be provisioned to the AMF by O&M. The satellite coverage availability information is not UE specific and can be applied by the AMF for any UE in the affected area.

In the case of NR satellite access that provides discontinuous network coverage, AMF may utilize sub-area paging as described in clause 4.2.3.3 of TS 23.502 (e.g. first page in the last known cell-id or TA and retransmission in all registered TAs). The AMF may utilize the location information as received at or before the AN release due to the discontinuous coverage for paging optimisation. The AMF may e.g. receive UE location from NG-RAN during the Registration procedure e.g. triggered for Mobility Management and Power Saving Optimization for discontinuous network coverage as described in clause 5.4.13.1, or the AMF may request NG-RAN location reporting when the UE is in CM-CONNECTED state as described in clause 5.4.7.

The AMF and UE may only use the procedure defined in this clause if both the UE and AMF indicate support for "Unavailability Period Support", see clause 5.4.13.1. A UE indicating support for "Unavailability Period Support" shall support the procedures defined in this clause when leaving coverage and re-gaining coverage for an NR satellite access. In order to avoid a large number of UEs causing excessive signalling load on the network when leaving coverage or re-gaining coverage after being out of coverage, the AMF may determine a Maximum Time Offset controlling when UEs are allowed to initiate NAS signalling with the network, as described in this clause. In this case, the AMF determines this Maximum Time Offset based on network configuration, high priority access and priority service as specified in TS 23.122 and TS 24.501. The AMF sends this Maximum Time Offset to individual UEs during the Registration procedure or UE Configuration Update procedure. If the UE receives a Maximum Time Offset from the network in a Registration Accept or UE Configuration Update Command message, the UE shall replace any previously received Maximum Time Offset on the same RAT type and PLMN with this one. When the UE knows a later time at which coverage will be lost and when the UE does not send Mobility Registration Update to the AMF in advance (see clause 5.4.13.1), the UE determines a random value up to the minimum of the latest Maximum Time Offset for this PLMN and RAT type and the time until coverage will be lost. The UE shall send the Mobility Registration Update at the time when coverage will be lost less the random value to the AMF indicating the loss of coverage. Upon returning to coverage after being out of coverage due to discontinuous coverage, the UE sets the discontinuous coverage wait timer value to a random value up to and including the latest Maximum Time Offset for this PLMN and RAT type, and starts this timer. The UE shall not initiate any NAS signalling on that RAT Type and PLMN while the discontinuous coverage wait timer is running. The UE shall stop the discontinuous coverage wait timer and initiate NAS signalling if the UE receives paging message, has pending emergency services or when UE enters a TAI outside the registration area.