Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  17.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.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.35  Support for Integrated access and backhaul (IAB) |R16|p. 412

5.35.1  IAB architecture and functional entitiesp. 412

Integrated access and backhaul (IAB) enables wireless in-band and out-of-band relaying of NR Uu access traffic via NR Uu backhaul links. In this Release of the specification, NR satellite access is not applicable. The serving PLMN may provide the mobility restriction for NR satellite access as specified in clause 5.3.4.1
The Uu backhaul links can exist between the IAB-node and:
  • a gNB referred to as IAB-donor; or
  • another IAB-node.
The part of the IAB node that supports the Uu interface towards the IAB-donor or another parent IAB-node (and thus manages the backhaul connectivity with either PLMN or SNPN it is registered with) is referred to as an IAB-UE.
In this Release of the specification, the IAB-UE function does not apply to the NR RedCap UE.
At high level, IAB has the following characteristics:
  • IAB uses the CU/DU architecture defined in TS 38.401, and the IAB operation via F1 (between IAB-donor and IAB-node) is invisible to the 5GC;
  • IAB performs relaying at layer-2, and therefore does not require a local UPF;
  • IAB supports multi-hop backhauling;
  • IAB supports dynamic topology update, i.e. the IAB-node can change the parent node, e.g. another IAB-node, or the IAB-donor, during operation, for example in response to backhaul link failure or blockage.
Figure 5.35.1-1 shows the IAB reference architecture with two backhaul hops, when connected to 5GC.
Reproduction of 3GPP TS 23.501, Fig. 5.35.1-1: IAB architecture for 5GS
Up
The gNB-DU in the IAB-node is responsible for providing NR Uu access to UEs and child IAB-nodes. The corresponding gNB-CU function resides on the IAB-donor gNB, which controls IAB-node gNB-DU via the F1 interface. IAB-node appears as a normal gNB to UEs and other IAB-nodes and allows them to connect to the 5GC.
The IAB-UE function behaves as a UE, and reuses UE procedures to connect to:
  • the gNB-DU on a parent IAB-node or IAB-donor for access and backhauling;
  • the gNB-CU on the IAB-donor via RRC for control of the access and backhaul link;
  • 5GC, e.g. AMF, via NAS;
  • OAM system via a PDU session or PDN connection (based on implementation).
The IAB-UE can connect to 5GC over NR (SA mode) or connect to EPC (EN-DC mode). The UE served by the IAB-node can operate in the same or different modes than the IAB-node as defined in TS 38.401. The operation mode with both UE and IAB-node connected to EPC is covered in TS 23.401. Operation modes with UE and IAB-node connected to different core networks are described in clause 5.35.6.
Up

5.35.2  5G System enhancements to support IABp. 414

In IAB operation, the IAB-UE interacts with the 5GC using procedures defined for UE. The IAB-node gNB-DU only interacts with the IAB-donor-CU and follows the CU/DU design defined in TS 38.401.
For the IAB-UE operation, the existing UE authentication methods as defined in TS 33.501 applies. Both USIM based methods and EAP based methods are allowed, and NAI based SUPIs can be used.
The following aspects are enhanced to support the IAB operation:
  • the Registration procedure as defined in clause 4.2.2.2 of TS 23.502 is enhanced to indicate IAB-node's capability to the AMF;
  • The IAB-node provides an IAB-indication to the IAB-donor-CU when the RRC connection is established as defined in TS 38.331. When the IAB-indication is received, the IAB-donor-CU selects an AMF that supports IAB and includes the IAB-indication in the N2 INITIAL UE MESSAGE as defined in TS 38.413 so that the AMF can perform IAB authorization.
  • the UE Subscription data as defined in clause 5.2.3 of TS 23.502 is enhanced to include the authorization information for the IAB operation;
  • Authorization procedure during the UE Registration procedure is enhanced to perform verification of IAB subscription information;
  • UE Context setup/modification procedure is enhanced to provide IAB authorized indication to NG-RAN.
After registered to the 5G system, the IAB-node remains in CM-CONNECTED state. In the case of radio link failure, the IAB-UE uses existing UE procedure to restore the connection with the network. The IAB-UE uses Deregistration Procedure as defined in clause 4.2.2.3 of TS 23.502 to disconnect from the network.
Up

5.35.3  Data handling and QoS support with IABp. 414

Control plane and user plane protocol stacks for IAB operation are defined in TS 38.300.
QoS management for IAB can remain transparent to the 5GC. If NG-RAN cannot meet a QoS requirement for a QoS Flow to IAB-related resource constraints, the NG-RAN can reject the request using procedures defined in TS 23.502.
The IAB-UE function can establish a PDU session or PDN connection, e.g. for OAM purpose (protocol stack not shown here). In that case, the IAB-UE obtains an IP address/prefix from the core network using normal UE procedures. The IAB-UE's IP address is different from that of the IAB-node's gNB DU IP address.
Up

5.35.4  Mobility support with IABp. 414

For UEs, all existing NR intra-RAT mobility and dual-connectivity procedures are supported when the UE is served by an IAB-node except for the cases of NR satellite access. However, in this release of the specification, there is no system level support of service continuity for a UE served by an IAB-node when the serving IAB-node changes its IAB-donor-CU.

5.35.5  Charging support with IABp. 415

IAB-donor has all the information regarding the UE and the IAB-node and corresponding mapping of the bearers. The PDU sessions for the UE and IAB-node are separate from IAB-node onwards to the core network. Therefore, the existing charging mechanism as defined in clause 5.12 can be used to support IAB.

5.35.6  IAB operation involving EPCp. 415

When the IAB-donor gNB has connection to both EPC and 5GC, based on PLMN configuration, there are two possible operation modes:
  • the IAB-node connects to a 5GC via the IAB-donor gNB, while the UEs served by the IAB-node connect to EPC with Dual Connectivity as defined in TS 37.340. In this operation mode, the IAB-donor gNB has connection to an eNB, and the 5GC is restricted for IAB-node access only; and
  • the IAB-node connects to an EPC via the IAB-donor gNB with Dual Connectivity as defined in TS 37.340, while the UEs served by the IAB-node connect to the 5GC. In this operation mode, the EPC is restricted for IAB-node access only.
To support the above operation modes, the IAB-UE shall be configured to select only a specific PLMN (as defined in TS 23.122) and whether it needs to connect to 5GC or EPC.
Up

5.36  RIM Information Transfer |R16|p. 415

The purpose of RIM Information Transfer is to enable the transfer of RIM information between two RAN nodes via 5GC. The RIM Information Transfer is specified in TS 38.413.
When the source AMF receives RIM information from source NG-RAN towards target NG-RAN, the source AMF forwards the RIM information to the target AMF, as described in TS 38.413 and TS 29.518. The AMF does not interpret the transferred RIM information.
Up

5.37  Support for high data rate low latency services |R17|p. 415

Interactive services that require high data rate and low latency communication, e.g. cloud gaming and AR/VR services are documented in TS 22.261. Standardized 5QI characteristics for such services are provided in Table 5.7.4-1 and TSCAI can be used to describe the related traffic characteristics as defined in clause 5.27.2.
Up

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

5.38.1  Generalp. 415

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

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

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

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

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

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

5.39.1  Generalp. 418

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

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

5.40.1  Generalp. 419

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

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

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

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

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

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

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

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