Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   3…   4.2.3   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.2.15…   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.15.11…   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.32.6…   5.33…   5.34…   5.35…   5.38…   5.43…   6…   6.3…   6.3.8…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   H…   J   K…   M…   N…   O…   P…

 

5.38  Support for Multi-USIM UE |R17|p. 500

5.38.1  Generalp. 500

A network and a Multi-USIM UE may support one or more of the following features for Multi-USIM UE operation:
In the Registration procedure (as specified in clause 4.2.2.2.2), when a Multi-USIM UE has more than one USIM active, supports and intends to use one or more Multi-USIM specific features, it indicates to the AMF the corresponding Multi-USIM feature(s) are supported (except for the Paging Timing Collision Control feature). Based on the received indication of the supported Multi-USIM features from the UE, the AMF shall indicate to the UE the support of the Multi-USIM features based on the Multi-USIM features supported by network and any preference policy by the network, if available. When a UE returns to having only one USIM active from a Multi-USIM UE that previously indicated to the network it supported Multi-USIM feature(s), the UE shall indicate all the Multi-USIM features are not supported to the network for that USIM. The AMF shall only indicate the support of Paging Restriction feature together with the support of either Connection Release feature or Reject Paging Request feature.
The Multi-USIM UE includes the support of individual features for Connection Release, Paging Cause Indication for Voice Service, Reject Paging Request and Paging Restriction as specified in clause 5.4.4a.
The network shall not indicate support for any Multi-USIM feature to the UE as part of the Emergency Registration procedure.
A Multi-USIM UE shall use a separate PEI for each USIM when it registers with the network.
Up

5.38.2  Connection Releasep. 501

A Multi-USIM UE may request the network to release the UE from RRC_CONNECTED state in 3GPP access for a USIM due to activity on another USIM in 3GPP access, if both UE and network indicate the Connection Release feature is supported to each other.
In the case of NAS connection release procedure, the UE indicates that it requests to be released from RRC_CONNECTED state, by initiating either a Service Request procedure over 3GPP access or a Registration procedure over 3GPP access (if case the UE needs to perform Registration Update at the same time with this network, including the case where the Registration Request is sent due to mobility outside the Registration Area, i.e. before detecting whether the network supports the feature in the new Tracking Area, provided that the network has already indicated support for Connection Release feature in the current stored Registration Area), by including a Release Request Indication. If supported by the UE and network, the UE may also provide, only together with the Release Request Indication, Paging Restriction Information, as specified in clause 5.38.5, which requests the network to restrict paging. If the UE is performing an Emergency Registration then it shall not include a Release Request Indication.
For NR/5G access, an AS method for the UE to request the network to release the UE from RRC_CONNECTED state is specified in TS 38.300. This mechanism does not allow the UE to indicate Paging Restrictions.
Up

5.38.3  Paging Cause Indication for Voice Servicep. 501

A Multi-USIM UE and the network may support Paging Cause Indication for Voice Service feature.
The network that supports Paging Cause Indication for Voice Service feature shall provide a Voice Service Indication for IMS voice service in the Paging message, only if the UE indicates the Paging Cause Indication for Voice Service feature is supported to the network. The network determines the IMS voice service based on the Paging Policy Indicator as specified in clause 5.4.3.2.
Upon reception of the Voice Service Indication in NGAP Paging Message from AMF, the NG-RAN supporting Paging Cause Indication for Voice Service should include the Voice Service Indication in the Uu Paging message to the UE.
When the UE context in the AMF indicates Paging Cause Indication for Voice Service feature is supported, in order to require NG RAN to deliver the Voice Service Indication in RAN paging for the UE in RRC_INACTIVE state, the AMF provides an indication indicating the Paging Cause Indication for Voice Service feature is supported to the NG-RAN. Upon reception of the indication, the NG-RAN that supports the feature stores a Paging Cause Indication for Voice Service indication in its the UE context. For a UE in RRC_INACTIVE, the NG-RAN should provide the Voice Service Indication in the RAN Paging message only when there is Paging Cause Indication for Voice Service indication in the UE context and detects the downlink data which triggers the RAN Paging message is related to voice service based on the Paging Policy Indicator, in the header of the received downlink data, as specified in clause 5.4.3.2.
UE that supports the Paging Cause Indication for Voice Service feature is capable of differentiation between Paging from a network that does not support the Paging Cause Indication for Voice Service feature and Paging without the Voice Service Indication. How the UE distinguishes the Paging from a RAN that does not support the Paging Cause Indication for Voice Service feature and Paging without the Voice Service Indication is defined in TS 38.331. The UE determines whether the Paging Cause Indication for Voice Service feature is supported in the current Registration Area by 5GC based on the MUSIM capability exchange with the AMF, see clause 5.38.1. The UE determines that the Paging Cause Indication for Voice Service feature is supported if it is supported by both the RAN, as indicated in the received Uu Paging message, and by 5GC, as indicated in the MUSIM capability exchange with the AMF.
The UE uses the Paging Cause Indication for Voice Service as described in TS 24.501 and TS 38.331.
Up

5.38.4  Reject Paging Requestp. 502

A Multi-USIM UE may set up a connection to respond to a page with a Reject Paging Indication to the network indicating that the UE does not accept the paging and requests to return to CM-IDLE state after sending this response, if both UE and network indicate the Reject Paging Request feature is supported to each other.
Upon being paged by the network, the Multi-USIM UE in CM-IDLE state attempts to send a Service Request message to the paging network including the Reject Paging Indication as the response to the paging, unless it is unable to do so, e.g. due to UE implementation constraints. In addition to the Reject Paging Indication, the UE may include Paging Restriction Information as specified in clause 5.38.5 in the Service Request message, if supported by UE and network.
Up

5.38.5  Paging Restrictionp. 502

A Multi-USIM UE and the network may support Paging Restriction. A Multi-USIM UE, if the AMF indicates that the network supports Paging Restriction feature, may indicate Paging Restriction Information in the Service Request or Registration Request message (including the case where the Registration Request is sent due to mobility outside the Registration Area, i.e. before detecting whether the network supports the feature in the new Tracking Area, provided that the network has already indicated support for Paging Restriction feature in the current stored Registration Area) as specified in clauses 5.38.2 and 5.38.4.
Based on operator policy the AMF may accept or reject the Paging Restriction Information requested by the UE. If the AMF accepts the Paging Restriction Information from the UE, the AMF stores the Paging Restriction Information from the UE in the UE context. If the AMF rejects the Paging Restriction Information, the AMF removes any stored Paging Restriction Information from the UE context and discards the UEs requested Paging Restriction Information. The AMF informs the UE about the acceptance/rejection of the requested Paging Restriction Information in the Registration Accept or Service Accept message.
If the UE does not provide any Paging Restriction Information in the Service Request over 3GPP access or the Registration Request over 3GPP access, the AMF removes any stored Paging Restriction Information from the UE context.
The Paging Restriction Information may indicate any of the following:
  1. all paging is restricted; or
  2. all paging is restricted, except paging for voice service (IMS voice); or
  3. all paging is restricted, except for certain PDU Session(s); or
  4. all paging is restricted, except paging for voice service (IMS voice) and certain PDU session(s).
Up

5.38.6  Paging Timing Collision Controlp. 503

To avoid possible paging occasion collision and to enhance the likelihood that paging is received successfully for different USIMs, a Multi-USIM UE may need a new 5G-GUTI to modify the timing of the Paging Occasions (POs) for a USIM when the USIM's registration is not emergency registration. When a Multi-USIM UE needs a 5G-GUTI assignment, it performs a Mobility Registration Update without any specific indication (i.e. it is using a normal Registration procedure). This triggers the AMF to allocate a new 5G-GUTI and provide it to the Multi-USIM UE in the Registration Accept message.
Up

5.39  Remote provisioning of credentials for NSSAA or secondary authentication/authorization |R17|p. 503

5.39.1  Generalp. 503

The UE's subscribed network (i.e. HPLMN, or subscribed SNPN) may provide functionalities to provision or update the credentials used for NSSAA or credentials used for secondary authentication/authorization to the UE. The provisioning procedure is supported via User Plane.
For User Plane Remote Provisioning, the UE establishes a PDU Session that is used for remote provisioning, e.g. by using DNN(s)/S-NSSAI(s) which can access the PVS. The AMF selects an SMF used for remote provisioning using the SMF discovery and selection functionality as described in clause 6.3.2. If the SMF is configured with the PVS address(es) and/or PVS FQDN(s), the SMF shall send the PVS address(es) and/or PVS FQDN(s) per DNN/S-NSSAI to the UE via PCO during PDU Session Establishment procedure, based on the UE's subscribed DNN(s)/S-NSSAI(s) and the UE's request of PVS information from the network. Alternatively, the UE may be configured with an address of a PVS or the PVS may subscribe for UE Reachability Notification and may use the Application Triggering procedure as specified in TS 23.502 to trigger the UE to initiate the setup of a connection for remote provisioning.
Up

5.39.2  Configuration for the UEp. 503

In order to enable UP Remote Provisioning of credentials for NSSAA or secondary authentication/authorization, UE Configuration Data for UP Remote Provisioning are either pre-configured on the UE or provided by the network to the UE. UE Configuration Data for UP Remote Provisioning provided by the network take precedence over corresponding configuration data stored in the UE.
UE Configuration Data for UP Remote Provisioning consist of PVS IP address(es) and/or PVS FQDN(s). The PVS IP address or PVS FQDN may be associated with dedicated DNN(s) and/or S-NSSAI(s).
If the UE does not have any PVS IP address or PVS FQDN after the establishment of a PDU Session used for UP remote provisioning, the UE may construct an FQDN for PVS discovery as defined in TS 23.003.
The UE Configuration Data for UP Remote Provisioning may be stored in the ME.
The UE Configuration Data for UP Remote Provisioning (i.e. PVS IP address(es) or PVS FQDN(s)) associated with dedicated DNN(s) and/or S-NSSAI(s) may be locally configured in the SMF. The UE Configuration Data for UP Remote Provisioning, if available, shall be provided to the UE during the establishment of any PDU Session used for UP Remote Provisioning as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response, if the UE has requested the PVS information via PCO in the PDU Session Establishment Request.
Up

5.40  Support of Disaster Roaming with Minimization of Service Interruption |R17|p. 504

5.40.1  Generalp. 504

Subject to operator policy and national/regional regulations, 5GS provides Disaster Roaming service (e.g. voice call and data service) for the UEs from PLMN(s) with Disaster Condition. The UE shall attempt Disaster Roaming only if:
  • there is no available PLMN which is allowable (see TS 23.122);
  • the UE is not in RM-REGISTERED and CM-CONNECTED state over non-3GPP access connected to 5GCN;
  • the UE cannot get service over non-3GPP access through ePDG;
  • the UE supports Disaster Roaming service;
  • the UE has been configured by the HPLMN with an indication of whether Disaster roaming is enabled in the UE set to "disaster roaming is enabled in the UE" as specified in clause 5.40.2; and
  • a PLMN without Disaster Condition is able to accept Disaster Inbound Roamers from the PLMN with Disaster Condition.
In this Release of the specification, the Disaster Condition only applies to NG-RAN nodes, which means the rest of the network functions except one or more NG-RAN nodes of the PLMN with Disaster Condition can be assumed to be operational.
Up

5.40.2  UE configuration and provisioning for Disaster Roamingp. 504

A UE supporting Disaster Roaming is configured with the following information:
  • Optionally, indication of whether disaster roaming is enabled in the UE;
  • Optionally, indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN';
  • Optionally, list of PLMN(s) to be used in Disaster Condition.
The Activation of Disaster Roaming is performed by the HPLMN by setting the indication of whether Disaster roaming is enabled in the UE to "disaster roaming is enabled in the UE" using the UE Parameters Update Procedure as defined in TS 23.502. The UE shall only perform disaster roaming if the HPLMN has configured the UE with the indication of whether disaster roaming is enabled in the UE and set the indication to "disaster roaming is enabled in the UE". The UE, registered for Disaster Roaming service, shall deregister from the PLMN providing Disaster Roaming service if the received indication of whether disaster roaming is enabled in the UE is set to "disaster roaming is disabled in the UE".
The optional 'list of PLMN(s) to be used in Disaster Condition' may be pre-configured in USIM or provided by the HPLMN during and after a successful registration procedure over 3GPP access or non-3GPP access via Registration Request procedure or UE Configuration Update procedure as defined in TS 23.502. The 'list of PLMN(s) to be used in Disaster Condition' may be configured over non-3GPP access before disaster condition has occurred.
While roaming (i.e. not in HPLMN), the Registered PLMN may provide the 'list of PLMN(s) to be used in Disaster Condition' during and after a successful registration procedure to the UE via Registration Request procedure or UE Configuration Update procedure as specified in TS 23.502. This list shall not alter any list provided by the HPLMN and shall only be used if the UE is configured by the HPLMN using the UE Parameters Update Procedure as defined in TS 23.502 with the indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN' set to "True".
The details of the UE behaviour regarding the usage of this list are described in TS 23.122 and TS 24.501. If the UE is not configured with 'list of PLMN(s) to be used in Disaster Condition', the UE follows the procedure described in TS 23.122 to select PLMN to be used in Disaster Condition.
The HPLMN may use UE Parameters Update Procedure as defined in TS 23.502 to update the Disaster Roaming information configuration in UE, if the UDM has received MINT support indication as indicated in 5GMM capability from the AMF. The UE indicates the support of MINT in 5GMM capability as specified in clause 5.4.4a, during registration procedure as defined in TS 23.502.
Up

5.40.3  Disaster Condition Notification and Determinationp. 505

The NG-RAN in the PLMN that provides Disaster Roaming service, broadcasts an indication of accessibility for Disaster Roaming service, and optionally, a 'list of one or more PLMN(s) with Disaster Condition for which Disaster Roaming service is offered by the available PLMN' in the impacted area as described in TS 38.304 and TS 38.331.
A UE determines the Disaster Condition based on the information broadcasted from the NG-RAN providing Disaster Roaming service, and performs the network selection and the access control for the Disaster Roaming as described in TS 23.122 and TS 24.501.
Up

5.40.4  Registration for Disaster Roaming servicep. 505

For a UE to receive Disaster Roaming service from a PLMN providing Disaster Roaming service, the UE sends a NAS Registration Request message with Registration Type value "Disaster Roaming Initial Registration" or "Disaster Roaming Mobility Registration Update":
  • When the AMF in the PLMN providing Disaster Roaming service receives a NAS Registration Request with Registration Type set to "Disaster Roaming Initial Registration" or "Disaster Roaming Mobility Registration Update";
  • the AMF controls if the UE is allowed to access Disaster Roaming service in the area with Disaster Condition as specified in clause 4.2.2.2.2 of TS 23.502;
  • the AMF may provide the Disaster Roaming service indication to AUSF and UDM as specified in clause 4.2.2.2.2 of TS 23.502 and TS 33.501. The AMF may provide the Disaster Roaming service indication to SMF as specified in clause 4.3.2 of TS 23.502.
To support the Disaster Roaming service, the PLMN providing Disaster Roaming service is configured to support communication with the network entities in the HPLMN of the UE, i.e. configurations related to roaming interfaces for communication between serving PLMN and HPLMN shall be deployed in the affected entities. This communication between the PLMNs need only be enabled during the Disaster Condition.
The Disaster Roaming service is limited to the impacted geographic area with Disaster Condition. The NG-RAN nodes and AMF in the PLMN providing Disaster Roaming service are configured with the area information, i.e. a list of TAIs which can be formulated by the PLMN providing the Disaster Roaming service based on the geographic area with Disaster Condition in the other PLMN(s).
The AMF in the PLMN providing Disaster Roaming service provides the mobility restriction list to the NG-RAN as specified in clause 5.3.4.1.1 considering the area with Disaster Condition, and also indicating that EPC is not an allowed core network.
Up

5.40.5  Handling when a Disaster Condition is no longer applicablep. 506

When a UE detects a Disaster Condition is no longer applicable, the UE performs PLMN selection as described in TS 23.122 and TS 24.501 and may return to the PLMN previously with Disaster Condition.
A PLMN providing Disaster Roaming:
  • May trigger the Disaster Inbound Roaming UEs to return to the PLMN previously with Disaster Condition when the Disaster Inbound Roamers attempt to transit to 5GMM-CONNECTED mode.
  • May trigger the Disaster Inbound Roaming UEs to return to the PLMN previously with Disaster Condition by triggering Deregistration procedure.
  • May trigger the Disaster Inbound Roaming UEs to return to the PLMN previously with Disaster Condition by rejecting Registration Request message.
  • May trigger the Disaster Inbound Roaming UEs to return to the PLMN previously with Disaster Condition by rejecting Service Request message.
  • Shall organise the return of the Disaster Roaming UEs in a manner that does not cause overload (e.g. of signalling) in the PLMN that previously had the Disaster Condition.
  • Stop broadcasting of providing Disaster Roaming service as specified in clause 5.40.3.
  • May determine that the disaster condition has ended and the UE which is registered for disaster roaming services has an emergency PDU session, the AMF initiates the UE configuration update procedure to indicate that the UE is registered for emergency services as described in TS 24.501.
  • May determine that the disaster condition has ended and inform the UE by initiating the UE configuration update procedure indicating re-registration from UE is required as specified in clause 5.4.4 of TS 24.501 if the UE is in CM-CONNECTED mode.
The HPLMN i.e. the UDM may trigger the Disaster Inbound Roaming UEs to return to the PLMN previously with Disaster Condition by triggering Deregistration procedure.
Up

5.40.6  Prevention of signalling overload related to Disaster Condition and Disaster Roaming servicep. 506

The load control, congestion and overload control mechanism specified in clause 5.19 and access control and barring specified in clause 5.2.5 can be used to mitigate the load caused by UE requesting the Disaster Roaming service in the PLMN providing Disaster Roaming service and returning of UE to allowable PLMN when Disaster Condition is no longer applicable.
To prevent signalling overload in PLMN providing Disaster Roaming, the HPLMN or registered PLMN:
  • may provide the UE in a prioritized manner with the list of PLMNs described in clause 5.40.2 for Disaster Roaming;
  • may provide disaster roaming wait range information to control when the UE can initiate the registration for Disaster Roaming service upon arriving in the PLMN providing Disaster Roaming service as specified in TS 23.122 and TS 24.501; and
  • applies Access Identity 3 for Disaster Roaming service request as specified in TS 24.501.
To prevent signalling overload by returning UEs in PLMN previously with Disaster Condition which is no long applicable, the HPLMN or registered PLMN:
  • may provide disaster return wait range information to control when the UE can initiate the registration upon returning to the PLMN previously with Disaster Condition as specified in TS 23.122 and TS 24.501.
Up

5.41  NR RedCap UEs differentiation |R17|p. 507

This functionality is used by the network to identify traffic to/from UEs accessing over NR RedCap, e.g. for charging differentiation.
An NR RedCap UE using NR shall provide an NR RedCap indication to the NG-RAN during RRC Connection Establishment procedure as defined in TS 38.300.
When the UE has provided an NR RedCap indication to the NG-RAN during RRC Connection Establishment, the NG-RAN shall provide an NR RedCap Indication to the AMF in the Initial UE Message (see clause 4.2.2.2.1 of TS 23.502 and TS 38.413).
When the AMF receives an NR RedCap Indication from NG-RAN in an Initial UE Message, the AMF shall store the NR RedCap Indication in the UE context, consider that the RAT type is NR RedCap and signal it accordingly to the SMSF during registration procedure for SMS over NAS, to the SMF during PDU Session Establishment or PDU Session Modification procedure. The PCF will also receive the NR RedCap RAT type indication when applicable, from the SMF during SM Policy Association Establishment or SM Policy Association Modification procedure.
During handover from E-UTRA to NR, the target NG-RAN (i.e. gNB) provides the NR RedCap indication to AMF in NGAP Path Switch Request message during Xn handover, or NGAP Handover Request Acknowledge message during N2 handover (including intra 5GS N2 handover and EPS to 5GS handover) based on the UE capability information provided by the source RAN to the target RAN as specified in TS 38.300.
The NFs interacting with CHF shall include the NR RedCap as RAT type.
Upon AMF change, the source AMF shall provide the "NR RedCap Indication" to the target AMF.
Up

5.42  Support of Non-seamless WLAN offload |R17|p. 507

Non-seamless WLAN offload is an optional capability of a UE supporting WLAN radio access.
The architecture to support authentication for Non-seamless WLAN offload in 5GS is defined in clause 4.2.15.
A UE supporting Non-seamless WLAN offload may, while connected to WLAN access, route specific data flows via the WLAN access without traversing the 5GC. These UE data flows are identified using URSP configuration for Non-Seamless Offload, or UE Local Configurations as defined in TS 23.503. For these data flows, the UE uses the local IP address allocated by the WLAN access network and no IP address preservation is provided between WLAN and NG-RAN.
For performing the Non-seamless WLAN offload, the UE needs to acquire a local IP address from the WLAN access network and it is not required to connect to an N3IWF, ePDG or TNGF. If the WLAN access network is configured to require the 5GS based access authentication of the UE for connecting to the WLAN, the UE performs the authentication procedure for Non-seamless WLAN offload in 5GS defined in clause 4.2.15 and in Annex S of TS 33.501. After successful authentication, the UE is not considered to be entered in 5GS Registered state. The UE can send and receive traffic not traversing the 5GC and which is not under the control of the 5GC.
A non-3GPP access network may be connected via SWa' to multiple PLMNs for 5G NSWO. In a roaming scenario the HPLMN may be reached by the UE via a WLAN access connected to more than one VPLMN. Therefore, a UE when roaming shall be able to indicate a specific selected VPLMN using decorated NAI for 5G NSWO, as specified in clauses 28.7.9.1 and 28.7.9.2 of TS 23.003, through which the NSWO request should be sent towards the HPLMN.
A non-3GPP access network may be connected to multiple SNPNs different from the Credentials Holder for 5G NSWO. When using the credentials owned by CH, the UE shall be able to indicate a specific selected SNPN (e.g. using decorated NAI for 5G NSWO) through which the NSWO request should be sent towards the CH in the following scenarios:
  • The CH hosts AUSF/UDM and the CH is reached by the UE via a WLAN access connected to a SNPN different from the CH as defined in Figure 4.2.15-3a.
  • The CH hosts AAA server and the CH is reached by the UE via a WLAN access connected to the AAA proxy in specific SNPN as defined in Figure 4.2.15-3b.
A UE connected to a WLAN access network using 5GS credentials (as shown in Figure 4.2.15-1), may also be connected to the 5GC, for example to establish a PDU session. For example, the UE may connect to the 5GC either via another access type (such as NG-RAN), or via the same WLAN access network by performing the 5GS registration via Untrusted non-3GPP access procedure (using N3IWF) or interworking between ePDG connected to EPC and 5GS (using ePDG) defined in TS 23.502.
When a UE is connected to a WLAN access network (e.g. using 5GS credentials) and using an Untrusted non-3GPP access, the UE can perform Non-Seamless Offload of some or all data traffic to this WLAN access network sending the traffic outside the IPSec tunnel encapsulation as defined in URSP rules with Non-Seamless Offload indication.
A UE may use the Registration procedure for Trusted non-3GPP access defined in clause 4.12a.2.2 of TS 23.502 and then determine to send some traffic (to be subject to Non-seamless WLAN offload) outside of the IPSec tunnel established with the TNGF.
When the UE decides to use 5G NSWO to connect to the WLAN access network using its 5GS credentials but without registration to 5GS, the NAI format for 5G NSWO is used whose realm is different than the realm defined for usage of Trusted non-3GPP access to the 5GC (defined in clauses 28.7.6 and 28.7.7 of TS 23.003).
The NAI format for 5G NSWO is defined in TS 23.003.
Up

Up   Top   ToC