Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

5.4  3GPP access specific aspectsWord-p. 87
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.
Two 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.
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 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.
Up
5.4.1.2  UE reachability allowing mobile terminated data while the UE is CM-IDLEWord-p. 88
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.
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) 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 in 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 in 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.
Up
5.4.2  UE reachability in CM-CONNECTEDWord-p. 89
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. 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.
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. The RAN may provide the elapsed time since RAN's last contact with the UE to AMF.
Up
5.4.3  Paging strategy handlingWord-p. 90
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).
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 data or the notification of downlink data received from UPF. The SMF includes the 5QI and ARP corresponding to 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 TS 23.502, clause 4.2.3.3.
NOTE:
The 5QI is used by AMF to determine suitable paging strategies.
Up
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, 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.
NOTE 1:
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 data packet, the UPF shall include the DSCP in TOS (IPv4) / TC (IPv6) value from the IP header of the downlink data packet and an indication of the corresponding QoS Flow in the data notification message 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 data packet, 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 data packet and identifies the corresponding QoS Flow from the QFI of the received downlink data 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 2:
Network configuration needs to ensure that the information used as a trigger for Paging Policy Indication is not changed within the 5GS.
NOTE 3:
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.
Up
5.4.3.3  Paging PriorityWord-p. 91
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.
Up
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 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 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.
The AMF deletes the UE radio capability when the UE RM state in the AMF transitions to RM-DEREGISTERED.
The UE Radio Capability is maintained in the core network, even during AMF reselection.
NOTE:
The UE Radio Capability is not transferred to EPC during the inter-system mobility.
If the UE's NG-RAN 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". 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 trigger to change the UE's NG-RAN 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.
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.
Up
5.4.4.1a  UE radio capability signalling optimisation (RACS) [R16]Word-p. 92
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 Access 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 radio capabilities container 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 6.2.21.
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.
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 Access Capabilities 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, the IMEI/TAC for the UE. The UCMF stores the association of this IMEI/TAC with this UE Radio Capability ID.
  • When the AMF needs to obtain the UE Radio Capability information associated to a UE Radio Capability ID it provides the UE Radio Capability ID to the UCMF and the UCMF returns a mapping of the UE Radio Capability ID to the corresponding UE Radio Capability information.
  • 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. PLMN-assigned UE Radio Capability IDs related to old values of the Version ID can be removed from cache with priority.
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 NG-RAN nodes at Xn setup and between NG-RAN and AMF at N2 setup time. 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 e.g. using the Configuration Transfer 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 Registration procedure as defined in TS 23.502. 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 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.
NOTE 4:
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 and TS 38.331, 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 stored in the UE context in CN and RAN.
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 there is no the associated UE Radio Capability ID for the updated Radio Capability, the UE shall perform capability update procedure 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.
NOTE 5:
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 6:
If the filter 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.
  • 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.
Up
5.4.4.2Void
5.4.4.2a  UE Radio Capability Match RequestWord-p. 94
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 establishement 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 to provide the 5G-AN with security context, before sending a UE Radio Capability Match Request message.
Up
5.4.4.3  Paging assistance informationWord-p. 95
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, -and 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.
  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.
Up
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 Core Network Capability (mostly to include other UE capabilities related to 5GCN or interworking with EPS) as defined in TS 24.501 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 5GMM 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.
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 (TS 23.401, clause 5.3.2.1).
  • EPC NAS.
  • SMS over NAS.
  • LCS.
  • 5G SRVCC from NG-RAN to UTRAN, as specified in TS 23.216.
  • 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.
Up
5.4.4b  UE 5GSM Core Network Capability handlingWord-p. 96
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.
Up
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.
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 and TS 36.331.
The UE shall apply the DRX cycle broadcast in the cell by the RAN unless it has received Accepted DRX parameters from the AMF in which case the UE shall apply either the DRX cycle broadcast in the cell or the Accepted DRX parameters, as defined in TS 38.304 and TS 36.304.
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 and TS 38.304.
Up
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.
Up
5.4.6.2  Core Network assisted RAN parameters tuningWord-p. 97
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).
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.
Up
5.4.6.3  Core Network assisted RAN paging informationWord-p. 98
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.
Up
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 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 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), or by including the request in some specific N2 messages as specified in TS 38.413.
Up
5.4.8  Support for identification and restriction of using unlicensed spectrum [R16]
Support for NG-RAN using unlicensed spectrum is defined in TS 38.300 and TS 36.300.
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 and TS 36.300.
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 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 and TS 36.300, 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 and TS 36.300.
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.
  • 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, 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.
Up
5.4.9  Wake Up Signal Assistance [R16]Word-p. 99
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.
Up

Up   Top   ToC