5.4 3GPP access specific aspects

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.4.1 UE reachability in CM-IDLE

5.4.1.1 General

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.

NOTE: If the UE CM state in the AMF is CM-IDLE, then AMF considers the UE always unreachable if the UE is in MICO mode (refer to clause 5.4.1.3).

If the UE indicates an Unavailability Period Duration, then AMF shall consider the UE as unreachable and will not trigger the Paging procedure (e.g. clear the PPF) until the UE registers for normal service again (e.g. set the PPF). Once the event that makes the UE unavailable is completed or cancelled in the UE, the UE shall initiate the registration procedure in order to resume normal service.

If 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.

5.4.1.2 UE reachability allowing mobile terminated data while the UE is CM-IDLE

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..

5.4.1.3 Mobile Initiated Connection Only (MICO) mode

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 [86]) 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 [3].

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 [3] 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.

5.4.1.4 Support of Unavailability Period

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 Supported" 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 for a certain period of time, the UE may store its MM and SM context in USIM or Non Volatile memory 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.

NOTE: How the UE stores its contexts depends upon the UE implementation. The UE can store some or all of its contexts in the USIM using existing USIM functionality.

Before the start of an event that makes the UE unavailable, the UE includes the Unavailability Period Duration and triggers either Mobility Registration Update or UE initiated Deregistration procedure:

a) If the UE initiates Mobility Registration Update procedure:

1) The AMF may take the Unavailability Period Duration into account when determining Periodic Registration Update timer value. The AMF may provide a Periodic Registration Update time longer than or equal to Unavailability Period Duration to avoid interfering with the UE dealing with the event that causes the unavailability;

2) The AMF stores the information that the UE is unavailable in UE context, and considers the UE is unreachable (i.e. clear the PPF in AMF) until the UE enters CM-CONNECTED state;

3) 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

4) 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.

b) If the UE initiates UE-initiated Deregistration procedure:

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;

Once the event which makes the UE unavailable is completed in the UE or the event is delayed to a future time or cancelled in the UE, the UE triggers Registration procedure to resume regular service. The UE shall not include the Unavailability Period in this Registration Request message. Depending on the UE state, the Registration procedure can be Initial Registration procedure or Mobility Registration Update procedure.

5.4.2 UE reachability in CM-CONNECTED

For a UE in CM-CONNECTED state:

– the AMF knows the UE location on a serving (R)AN node granularity.

– the NG-RAN notifies the AMF when UE becomes unreachable from RAN point of view.

UE RAN reachability management is used by RAN for UEs in RRC Inactive state, see TS 38.300 [27]. The location of a UE in RRC Inactive state is known by the RAN on a RAN Notification area granularity. A UE in RRC Inactive state is paged in cells of the RAN Notification area that is assigned to the UEs. The RAN Notification area can be a subset of cells configured in UE’s Registration Area or all cells configured in the UE’s Registration Area. UE in RRC Inactive state performs RAN Notification Area Update when entering a cell that is not part of the RAN Notification area that is assigned to the UE.

At transition into RRC Inactive state RAN configures the UE with a periodic RAN Notification Area Update timer value and the timer is restarted in the UE with this initial timer value. After the expiry of the periodic RAN Notification Area Update timer in the UE, the UE in RRC Inactive state performs periodic RAN Notification Area Update, as specified in TS 38.300 [27].

To aid the UE reachability management in the AMF, RAN uses a guard timer with a value longer than the RAN Notification Area Update timer value provided to the UE. Upon the expiry of the periodic RAN Notification Area Update guard timer in RAN, the RAN shall initiate the AN Release procedure as specified in TS 23.502 [3]. The RAN may provide the elapsed time since RAN’s last contact with the UE to AMF.

5.4.3 Paging strategy handling

5.4.3.1 General

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 [86]).

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 [3].

NOTE: The 5QI is used by AMF to determine suitable paging strategies.

5.4.3.2 Paging Policy Differentiation

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 [15], 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).

NOTE 1: This PPD feature may be used to determine the Paging Cause Indication for Voice Service, as described in clause 5.38.3.

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.

NOTE 2: Support of Paging Policy Differentiation in the case of HR roaming requires inter operator agreements including on the DSCP value associated with this feature.

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.

NOTE 3: Network configuration needs to ensure that the information used as a trigger for Paging Policy Indication is not changed within the 5GS.

NOTE 4: Network configuration needs to ensure that the specific DSCP in TOS (IPv4) / TC (IPv6) value, used as a trigger for Paging Policy Indication, is managed correctly in order to avoid the accidental use of certain paging policies.

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.

5.4.3.3 Paging Priority

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.

5.4.4 UE Radio Capability handling

5.4.4.1 UE radio capability information storage in the AMF

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 [27] 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.

NOTE 1: Due to issues with the handling of dynamic UMTS security parameters, the UTRA UE Radio Capability information is excluded from the information that is uploaded and stored in the AMF (see TS 38.300 [27]).

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.

NOTE 2: The UE Radio Capability is not transferred to EPC during the inter-system mobility.

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 [51].

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.

5.4.4.1a UE radio capability signalling optimisation (RACS)

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 [3]. 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 [51] and TS 38.331 [28]. The two UE radio capabilities formats shall be identifiable by the AMF and UCMF and the AMF shall store the TS 38.331 [28] 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 [28]) 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 [28] format and TS 36.331 [51] 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 [28] 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 [51] and TS 38.331 [28] 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 [51] and TS 38.331 [28] 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 [34].

– 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 [51] and TS 38.331 [28] 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 [28] format and the UCMF returns a mapping of the UE Radio Capability ID to the corresponding UE Radio Capability information in TS 38.331 [28] 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 [34] and TS 38.423 [99]. 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 [34] 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 [3] and based on triggers defined in TS 24.501 [47]. 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".

NOTE 1: It is expected that in a given PLMN the UCMF and AMFs will be configured to either use a UE manufacturer-assigned operation requested list based on a list of PLMN-assigned UE Radio Capability IDs or a list of IMEI/TACs, but not both.

NOTE 2: The strategy for triggering of the deletion of PLMN-assigned UE Radio Capability ID(s) in the UE by the AMF is implementation-specific (e.g. can be used only towards UEs in CM_Connected state).

– 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.

NOTE 3: The AMF can decide to remove a UE Radio Capability ID from the "UE Manufacturer Assigned operation requested list" list e.g. because no UE with that UE Radio Capability ID has connected to the network for long time. If later a UE with such UE Radio Capability ID connects to the network, the AMF contacts the UCMF to resolve the UE Radio Capability ID, and at this point the UCMF can trigger again the deletion of the UE Radio Capability ID by including this in the "UE Manufacturer Assigned operation requested list" of the AMF.

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.

NOTE 4: If AMF decides to allocate TAIs of multiple PLMN IDs as part of Registration Area to the UE then AMF provides the UE Radio Capability ID of the new selected PLMN to the NG-RAN during UE mobility, whether the UE Radio Capability ID is taken from stored UE context previously assigned by the same new selected PLMN or generated freshly each time a new PLMN is selected is up to AMF implementation.

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.

NOTE 5: It is assumed that UE does not need to store the access stratum information (i.e. UE-E-UTRA-Capability and UE-NR-Capability specified in TS 36.331 [51] and TS 38.331 [28], respectively) that was indicated by the UE to the network when the PLMN-assigned UE Radio Capability ID was assigned by the network. However, it is assumed that the UE does store the related UE configuration (e.g. whether or not GERAN or UTRAN or MBMS is enabled/disabled).

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 [28].

NOTE 6: In a RACS supporting PLMN, the filter of UE radio capabilities configured in NG-RAN is preferably as wide in scope as possible (e.g. PLMN-wide). In this case, it corresponds e.g. to the super-set of bands, band-combinations and RATs the PLMN deploys and not only to the specific NG-RAN node or region.

NOTE 7: If the filter, included in the UE Radio Capability information, of UE radio capabilities configured in two NG-RAN nodes is different, during handover between these two nodes, it is possible that the target NG-RAN node might need to enquire the UE for its UE Radio Capability Information again and trigger re-allocation of a PLMN-assigned UE Radio Capability ID leading to extra signalling. Additionally, a narrow filter might reduce the list of candidate target nodes.

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 [26].

– 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 [27] and TS 36.300 [30]. 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 [26].

5.4.4.2 Void

5.4.4.2a UE Radio Capability Match Request

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).

NOTE: During the Registration Procedure, if the AMF does not already have the UEs radio capabilities, and if the RAT where the UE is requires the establishment of AN security context prior to retrieval of radio capabilities, the AMF needs to initiate "Initial Context Setup" procedure as defined in TS 38.413 [34] to provide the 5G-AN with security context, before sending a UE Radio Capability Match Request message.

5.4.4.3 Paging assistance information

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

a) 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 [34], 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.

b) 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.

5.4.4a UE MM Core Network Capability handling

The UE MM Core Network Capability is split into the S1 UE network capability (mostly for E-UTRAN access related core network parameters) and the UE 5GMM Core Network Capability (mostly to include other UE capabilities related to 5GCN or interworking with EPS) as defined in TS 24.501 [47] and contains non radio-related capabilities, e.g. the NAS security algorithms, etc. The S1 UE network capability is transferred between all CN nodes at AMF to AMF, AMF to MME, MME to MME, and MME to AMF changes. The UE 5GMM Core Network Capability is transferred only at AMF to AMF changes.

In order to ensure that the UE MM Core Network Capability information stored in the AMF is up to date (e.g. to handle the situation when the USIM is moved into a different device while out of coverage, and the old device did not send the Detach message; and the cases of inter-RAT Registration Area Update), the UE shall send the UE MM Core Network Capability information to the AMF during the Initial Registration and Mobility Registration Update procedure within the NAS message.

The AMF shall store always the latest UE MM Core Network Capability received from the UE. Any UE MM Core Network Capability that an AMF receives from an old AMF/MME is replaced when the UE provides the UE MM Core Network Capability with Registration signalling.

If the UE’s UE MM Core Network Capability information changes (in either CM-CONNECTED or in CM-IDLE state), the UE shall perform a Mobility Registration Update procedure when it next returns to NG-RAN coverage. See clause 4.2.2 of TS 23.502 [3].

The UE shall indicate in the UE 5GMM Core Network Capability if the UE supports:

– Attach in EPC with Request type "Handover" in PDN CONNECTIVITY Request message (clause 5.3.2.1 of TS 23.401 [26]).

– EPC NAS.

– SMS over NAS.

– LCS.

– 5G SRVCC from NG-RAN to UTRAN, as specified in TS 23.216 [88].

– Radio Capabilities Signalling optimisation (RACS).

– Network Slice-Specific Authentication and Authorization.

– Parameters in Supported Network Behaviour for 5G CIoT as described in clause 5.31.2.

– Receiving WUS Assistance Information (E-UTRA) see clause 5.4.9..

– Paging Subgrouping Support Indication (NR) see clause 5.4.12.

– CAG, see clause 5.30.3.3.

– Subscription-based restrictions to simultaneous registration of network slices (see clause 5.15.12).

– Support of NSAG (see clause 5.15.14).

– Minimization of Service Interruption (MINT), as described in clause 5.40.

– Equivalent SNPNs (see clause 5.30.2.11).

– Unavailability Period, as described in clause 5.4.1.4.

If a UE operating two or more USIMs, supports and intends to use one or more Multi-USIM features (see clause 5.38) in a PLMN for a USIM, it shall indicate in the UE 5GMM Core Network Capability for this USIM in this PLMN that it supports these one or more Multi-USIM features with the following indications:

– Connection Release Supported.

– Paging Cause Indication for Voice Service Supported.

– Reject Paging Request Supported.

– Paging Restriction Supported.

Otherwise, the UE with the capabilities of Multi-USIM features but does not intend to use them shall not indicate support of these one or more Multi-USIM features.

A UE not operating two or more USIMs shall indicate the Multi-USIM features are not supported.

NOTE: It is not necessary for a UE operating two or more USIMs to use Multi-USIM features with all USIMs.

5.4.4b UE 5GSM Core Network Capability handling

The UE 5GSM Core Network Capability is included in PDU Session Establishment/Modification Request.

The UE shall indicate in the UE 5GSM Core Network Capability whether the UE supports:

– "Ethernet" PDU Session Type supported in EPC as PDN Type "Ethernet";

– Reflective QoS;

– Multi-homed IPv6 PDU Session (only if the Requested PDU Type was set to "IPv6" or "IPv4v6");

– ATSSS capability (as referred to clause 5.32.2);

– Transfer of Port Management Information containers.

The 5GSM Core Network Capability is transferred, if needed, from V-SMF to H-SMF during PDU Session Establishment/Modification procedure.

After the first inter-system change from EPS to 5GS for a PDU session established in EPS, the 5GSM Core Network Capability is also included in the PDU Session Modification if the Reflective QoS and/or Multi-homed IPv6 PDU Session is present.

5.4.5 DRX (Discontinuous Reception) framework

The 5G System supports DRX architecture which allows Idle mode DRX cycle is negotiated between UE and the AMF. The Idle mode DRX cycle applies in CM-IDLE state and in CM-CONNECTED with RRC Inactive state.

If the UE wants to use UE specific DRX parameters, the UE shall include its preferred values consistently in every Initial Registration and Mobility Registration procedure separately for NR/WB-EUTRA and NB-IoT. During Initial Registration and Mobility Registration procedures performed on NB-IoT cells, the normal 5GS procedures apply. For NB-IoT, the cell broadcasts an indication of support of UE specific DRX for NB-IoT in that cell, and the UE can request UE specific DRX for NB-IoT in the Registration procedure irrespective of whether the cell broadcasts that support indication.

The AMF shall determine Accepted DRX parameters based on the received UE specific DRX parameters and the AMF should accept the UE requested values, but subject to operator policy the AMF may change the UE requested values.

The AMF shall respond to the UE with the Accepted DRX parameters separately for NR/WB-EUTRA and NB-IoT.

For details of DRX parameters, see TS 38.331 [28] and TS 36.331 [51].

The UE shall apply the DRX cycle broadcast in the cell by the RAN unless it has received Accepted DRX parameters for the RAT from the AMF and for NB-IoT the cell supports UE specific DRX for NB-IoT, in which case the UE shall apply either the DRX cycle broadcast in the cell or the Accepted DRX parameters for the RAT, as defined in TS 38.304 [50] and TS 36.304 [52].

The Periodic Registration procedure does not change the UE’s DRX settings.

In CM-CONNECTED with RRC Inactive state, the UE applies either the DRX cycle negotiated with AMF, or the DRX cycle broadcast by RAN or the UE specific DRX cycle configured by RAN, as defined in TS 38.300 [27] and TS 38.304 [50].

5.4.6 Core Network assistance information for RAN optimization

5.4.6.1 General

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.

5.4.6.2 Core Network assisted RAN parameters tuning

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 clause 4.15.6.3 or 4.15.6.3a, TS 23.502 [3]) 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 [3]) 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 [3]) 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 [34]).

NOTE: The calculation of the CN assistance information, i.e. the algorithms used and related criteria, and the decision when it is considered suitable and stable to send to the RAN are vendor specific.

5.4.6.3 Core Network assisted RAN paging information

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.

5.4.7 NG-RAN location reporting

NG-RAN supports the NG-RAN location reporting for the services that require accurate cell identification (e.g. emergency services, lawful intercept, charging) or for the UE mobility event notification service subscribed to the AMF by other NFs. The NG-RAN location reporting may be used by the AMF when the target UE is in CM-CONNECTED state. The NG-RAN location reporting may be used by the AMF to determine the geographically located TAI in the case of NR satellite access.

The AMF may request the NG-RAN location reporting with event reporting type (e.g. UE location or UE presence in Area of Interest), reporting mode and its related parameters (e.g. number of reporting).

If the AMF requests UE location, the NG-RAN reports the current UE location (or last known UE location with time stamp if the UE is in RRC Inactive state) based on the requested reporting parameter (e.g. one-time reporting or continuous reporting).

If the AMF requests UE location, in the case of NR satellite access, the NG-RAN provides all broadcast TAIs to the AMF as part of the ULI. The NG-RAN also reports the TAI where the UE is geographically located if this TAI can be determined.

If the AMF requests UE presence in the Area Of Interest, the NG-RAN reports the UE location and the indication (i.e. IN, OUT or UNKNOWN) when the NG-RAN determines the change of UE presence in Area Of Interest.

After N2 based Handover, if the NG-RAN location reporting information is required, the AMF shall re-request the NG-RAN location reporting to the target NG-RAN node. For Xn based Handover, the source NG-RAN shall transfer the requested NG-RAN location reporting information to target NG-RAN node.

The AMF requests the location information of the UE either through independent N2 procedure (i.e. NG-RAN location reporting as specified in clause 4.10 of TS 23.502 [3]), or by including the request in some specific N2 messages as specified in TS 38.413 [34].

5.4.8 Support for identification and restriction of using unlicensed spectrum

Support for NG-RAN using unlicensed spectrum is defined in TS 38.300 [27] and TS 36.300 [30].

For NG-RAN, in the case of NR in stand-alone mode, all cells are in unlicensed spectrum and the NR is used as primary RAT. NR or E-UTRA cells in unlicensed spectrum, can be used as secondary cells as specified in the Dual Connectivity architecture defined in clause 5.11 or in addition can be configured to support the Carrier Aggregation Architecture (CA) defined in TS 38.300 [27] and TS 36.300 [30].

For either case the serving PLMN can enforce Access Restriction for Unlicensed Spectrum (either signalled from the UDM, or, locally generated by VPLMN policy in the AMF) with the following:

– To restrict the use of NR in unlicensed spectrum as primary RAT, the AMF rejects the UE Registration procedure with appropriate cause code defined in TS 24.501 [47] if the UE performs initial access from NR using unlicensed spectrum. If the UE is accessing through some other allowed RAT, the AMF signals this access restriction to NG-RAN as part of Mobility Restriction List.

– To restrict the use of use of unlicensed spectrum with NR or E-UTRA as secondary RAT using Dual Connectivity or Carrier Aggregation Architecture (CA) defined in TS 38.300 [27] and TS 36.300 [30], the AMF signals this access restriction to NG-RAN as part of Mobility Restriction List.

An NG-RAN node supporting aggregation with unlicensed spectrum using either NR or E-UTRA checks whether the UE is allowed to use unlicensed spectrum based on received Mobility Restriction List. If the UE is not allowed to use Unlicensed Spectrum, the NG-RAN node shall restrict the using of unlicensed spectrum, either NR or E-UTRA as secondary RATs when using either Dual Connectivity or Carrier Aggregation (CA) as defined in TS 38.300 [27] and TS 36.300 [30].

At inter-RAT handover from E-UTRAN/EPS, the Access Restriction for Unlicensed Spectrum is either already in the AMF’s UE context, or is obtained from the UDM during the subsequent Registration Area Update procedure (i.e. not from the source MME or source RAN). In both inter-RAT handover cases, any Access Restriction for use of Unlicensed Spectrum is then signalled to NG-RAN or enforced in AMF.

NOTE: This signalling of the Access Restriction during the Registration Area Update after the inter-RAT handover procedure means that there is a small risk that unlicensed spectrum resources are transiently allocated.

When the UE is accessing 5GS using unlicensed spectrum as primary RAT:

– The NG-RAN node shall provide an indication to the AMF in N2 interface that NR access is using unlicensed spectrum as defined in TS 38.413 [34].

– In order to restrict access to NR in unlicensed spectrum, cells supporting NR in unlicensed spectrum have to be deployed in Tracking Area(s) different to cells supporting licensed spectrum.

– When the AMF receives an indication from NG-RAN over N2 whether NR in unlicensed spectrum is being used as defined in TS 38.413 [34], the AMF provides to the SMF an indication that the RAT type is NR with usage of unlicensed spectrum during PDU Session Establishment or as part of the UP activation and Handover procedures.

– The PCF will also receive the indication whether the UE is using NR in unlicensed spectrum, when applicable, from the SMF during SM Policy Association Establishment or SM Policy Association Modification procedure.

– The NFs generating CDRs shall include the indication that the UE is using NR in unlicensed spectrum in their CDRs.

When the UE is accessing NR or E-UTRA using unlicensed spectrum as secondary RAT, procedures for Usage Data Reporting for Secondary RAT as defined in clause 5.12.2 can apply.

5.4.9 Wake Up Signal Assistance

5.4.9.1 General

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 [52]).

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:

a) 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 [34]) to the AMF in the NGAP UE Context Release Complete, UE Context Suspend Request and UE Context Resume Request messages;

b) 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 [34]); and

c) 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 [34]). 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.

5.4.9.2 Group Wake Up Signal

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 [30]).

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.

5.4.10 Support for identification and restriction of using NR satellite access

Support for NR satellite access is specified in TS 38.300 [27].

Editor’s note: TS 38.300 [27] not yet updated by RAN groups.

The AMF determines the RAT Type for NR satellite access, i.e. NR(LEO), NR(MEO), NR(GEO) and NR(OTHERSAT). When the UE is accessing NR using satellite access, an indication is provided in N2 interface indicating the type of NR satellite access, as defined in TS 38.413 [34].

Editor’s note: Further details on what type of satellite platforms OTHERSAT includes is FFS and to be aligned with RAN WG3.

The serving PLMN can enforce mobility restrictions for NR satellite access as specified in clause 5.3.4.1.

In order to enable efficient enforcement of Mobility Restrictions, cells of each NR satellite RAT Type (NR(LEO), NR(MEO), NR(GEO) or NR(OTHERSAT)) need to be deployed in TAs different from TAs for other NR satellite RAT Types as well as different from TAs supporting terrestrial access RAT Types.

The AMF may initiate deregistration of the UE when an N2 UE Context Release Request is received with cause value indicating that the UE is not in PLMN serving area, as specified in TS 38.413 [34].

5.4.11 Support for integrating NR satellite access into 5GS

5.4.11.1 General

This clause describes the specific aspects for NR satellite access.

5.4.11.2 Support of RAT types defined in 5GC for 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.

5.4.11.3 Void

5.4.11.4 Verification of UE location

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. In this case, when the AMF receives a NGAP message containing User Location Information for a UE using NR satellite access, the AMF 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.

NOTE: The area where the UE is allowed to operate can be determined based on the regulatory area where the PLMN is allowed to operate based on its licensing conditions.

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 proceeds 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 [87], 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 [17] and TS 24.501 [47].

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.

5.4.11.5 Network selection for NR satellite access

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 [17].

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.

5.4.11.6 Support of Mobility Registration Update

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.

5.4.11.7 Tracking Area handling for NR satellite access

Editor’s note: References to RAN TSs are needed after RAN WGs have further progressed their work on TA handling in NTN.

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.331 [28].

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 [34] to the AMF as part of the ULI, whenever the ULI is included in the NGAP message as described in TS 38.413 [34]. The NG-RAN indicates, if known, also the TAI where the UE is geographically located.

NOTE: The AMF may take the TAI where the UE is geographically located into account to generate a suitable Registration Area for the UE.

5.4.11.8 Support for mobility Forbidden Area and Service Area Restrictions for NR satellite access

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 [3]. 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.

5.4.12 Paging Early Indication with Paging Subgrouping Assistance

5.4.12.1 General

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 [50]).

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.

NOTE: Paging messages sent to that gNB can increase UE power consumption for other UEs that support 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.

NOTE: Because the UE uses the AMF allocated paging subgroup across all cells in its TAI-list, and, different, overlapping TAI lists can be allocated to different UEs, then to avoid UE power consumption increasing, it is likely to be necessary that all AMFs with an overlapping coverage area use a consistent policy in allocating UEs to the paging subgroups.

The NG-RAN node and the UE determine per cell which paging subgrouping method to use as defined in TS 38.304 [50] and TS 38.331 [28].

5.4.12.2 Core Network Assistance for PEIPS

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 [27]).

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.

NOTE 1: To minimise MT voice call setup latency, the AMF could allocate Paging Subgroup IDs taking into account whether or not the UE is likely to receive IMS voice over PS session calls.

NOTE 2: To avoid MT traffic for more mobile UEs causing more stationary UEs to be woken up, the AMF could allocate Paging Subgroup IDs taking into account the UE’s mobility pattern.

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 [27].

The AMF may use the UE Configuration Update procedure (as described in clause 4.2.4 of TS 23.502 [3]) and N2 UE Context Modification procedure (as described in clause 8.3.4 of TS 38.413 [34]) 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.