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 126.96.36.199
The Uu backhaul links can exist between the IAB-node and:
a gNB referred to as IAB-donor; or
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.
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.
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 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 188.8.131.52 of TS 23.502 to disconnect from the network.
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.
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.
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.
The MBSR uses the IAB architecture as defined in clause 5.35, and operates as an IAB node (with an IAB-UE and gNB-DU) with mobility when integrated with the serving PLMN. The architecture described in clause 5.35.1 applies. Additionally, the following limitations apply to the MBSR:
the MBSR has a single hop to the IAB-donor node;
NR Uu is used for the radio link between a MBSR and served UEs, and between MBSR and IAB-donor node.
Regulatory requirements (e.g. emergency services, priority services) are supported when UEs access 5GS via a MBSR. LCS framework as defined in TS 23.273 is used for providing the location service to the served UEs, with additional enhancements described in clause 5.35A.5.
Roaming of the MBSR is supported, i.e. a MBSR can integrated with a VPLMN's IAB-donor node. The corresponding enhancements to support MBSR roaming are described in clause 5.35A.4.
CAG mechanism as defined in clause 5.30 can be used for the control of UE's access to the MBSR. Optional enhancements to the CAG mechanism for MBSR use are described in clause 5.35A.6.
For a MBSR node, it provides a mobile IAB-indication to the IAB-donor-CU when the RRC connection is established as defined in TS 38.331. When the mobile IAB-indication is received, the IAB-donor-CU selects an AMF that supports IAB-node with mobility and includes the mobile IAB-indication in the N2 INITIAL UE MESSAGE as defined in TS 38.413 so that the AMF can perform mobile IAB authorization.
After the IAB-UE performs registration procedure in 5GS, further mobility procedure can be performed to change the IAB-donor-DU, the IAB-donor-CU as specified in TS 38.401.
The procedure of Inter-gNB-DU Mobility as defined in TS 38.401 or the handover procedure using the Xn/N2 reference points as defined in TS 23.502 can be used.
For UEs in RRC_IDLE and RRC_INACTIVE state when a MBSR goes out-of-service, procedure for cell (re-)selection as specified in TS 38.304 for RRC_IDLE and RRC_INACTIVE is used.
For UEs in RRC Connected state, if the MBSR goes out-of-service due to e.g. MBSR moves to an area where the MBSR is not allowed to provide the relay service, the procedure for IAB node release as specified in TS 38.401 is used.
For a MBSR, the subscription information stored in the HPLMN indicates whether it is authorized to operate as MBSR, and the corresponding location and time periods.
When MBSR roaming is supported, a roaming agreement between VPLMN and HPLMN regarding MBSR operation is in place, and the 5GC can make use of it for authorization of MBSR in VPLMN. MBSR (IAB-DU) can use IAB-node integration procedure or inter-IAB-donor gNB mobility procedure to integrate into VPLMN to provide service.
The MBSR(IAB-UE) is assumed to be configured with preferred PLMN lists and forbidden PLMNs by the HPLMN for the MBSR operation.
When the MBSR (IAB-UE) performs initial registration with the serving PLMN, it indicates the request to operate as a MBSR as described in clause 5.35A.1. The AMF authorizes the MBSR based on the subscription information, and provides MBSR authorized indication to NG-RAN. The MBSR establishes the connection to OAM system using the configuration information for MBSR operation.
The AMF of the MBSR can indicate to the MBSR that it is not allowed to act as an IAB node as part of registration procedure, and in this case does not include MBSR authorization indication to donor-gNB.
When a UE accesses 5GS via a MBSR, it can use the location service as defined in TS 23.273. However, in order to provide accurate estimation of the UE location, LMF needs to take the location of the MBSR into account. Enhancements to the LCS framework for MBSR support is described in clause 5.9 of TS 23.273.
CAG Identifier is used to control the access of UE via MBSR (i.e. mobile IAB-node) and existing CAG mechanism defined in clause 5.30.3 can be used for managing UE's access to MBSR, with the following additional considerations:
When the MBSR is allowed to operate as an IAB node for a PLMN, the MBSR is configured, either during the communication with the serving PLMN OAM or (pre-)configuration mechanism, with a CAG identifier which is unique within the scope of this PLMN. If the MBSR is (pre-)configured with the PLMN list in which the MBSR is allowed to operate as MBSR, the corresponding CAG Identifier per PLMN is also configured in the MBSR.
NG-RAN and 5GC support the UE access control based on the CAG identifier associated with the MBSR cell and the allowed CAG identifiers for the UE that supports CAG functionality.
For the UE that does not support CAG functionality, NG-RAN and 5GC are allowed to use not only CAG mechanism but also the other existing mechanism e.g. forbidden Tracking Area, to manage its access to MBSR.
Time duration restriction and location restriction information may be provided together with the CAG Identifier(s) for the MBSR(s) that the UE can access. The enhanced Allowed CAG list will be provided to UE and AMF for enforcement, to make sure that UE not accessing the MBSR cell outside of the time duration or location restriction area. For example, if the time when a certain CAG is allowed for a UE is up or UE is out of the geographic area, the CAG for the UE is revoked from the network.
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.
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.
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.
In the Registration procedure (as specified in clause 184.108.40.206.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.
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.
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 220.127.116.11.
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 18.104.22.168.
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.
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.
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:
all paging is restricted; or
all paging is restricted, except paging for voice service (IMS voice); or
all paging is restricted, except for certain PDU Session(s); or
all paging is restricted, except paging for voice service (IMS voice) and certain PDU session(s).
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.
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.
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.
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.
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.
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.
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 22.214.171.124.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 126.96.36.199.1 considering the area with Disaster Condition, and also indicating that EPC is not an allowed core network.
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.
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.
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 188.8.131.52.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.
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.
Satellite may be used as part of the backhaul between (R)AN and 5GC. The 5G System supports to report of usage of satellite backhaul as described in clause 5.43.2.
For some deployments, UPF may be deployed on the satellite. In these cases, edge computing or local switch via UPF deployed on the satellite may be performed as described in clauses 5.43.2 and 5.43.3. Deployments with satellite backhaul and edge computing with UPF on the ground is supported as described in clause 5.13, i.e. without satellite backhaul specific requirements.
This clause only applies to the case where Edge Computing is deployed with UPF and Edge Computing services on-board the satellite. The UPF deployed on satellite can act as UL CL/BP/local PSA UPF or act as PSA UPF.
If the UPF deployed on satellite is acting as PSA, the following enhancements apply:
If the UE is accessing gNB with satellite backhaul, and AMF is aware the satellite backhaul category, the AMF sends the satellite backhaul category to the PCF. If GEO satellite backhaul category is indicated, the PCF may take it into account to generate or update the URSP rule as defined in clause 184.108.40.206 of TS 23.503 to including an appropriate Route Selection Descriptor for services deployed on GEO satellite, which further enable PDU Session Establishment with PSA UPF on the satellite.
If the UPF deployed on satellite is acting as UL CL/BP and local PSA, the SMF performs UL CL/BP/local PSA selection and insertion during the PDU Session Establishment procedure as described in clause 4.3.2 of TS 23.502 or PDU Session Modification procedure as described in clause 4.3.3 of TS 23.502 based on GEO satellite ID provided by the AMF, which includes:
Based on configuration, the AMF may determine the GEO Satellite ID serving the UE and send it to the SMF. If GEO satellite ID changes, e.g. due to UE handover to an gNB using different GEO satellite as part of backhaul, the AMF may update the latest GEO Satellite ID to the SMF.
The SMF determines DNAI based on local configuration and the GEO Satellite ID received from AMF.
If the UE is allowed to access the service(s) according to the EAS Deployment Information as described in clause 220.127.116.11 of TS 23.548, the SMF selects the UL CL/BP/local PSA based on the DNAI corresponding to the GEO Satellite ID and other factors as described in clause 18.104.22.168 of TS 23.548.
The UE to UE traffic may be locally routed by UPF(s) deployed on satellite (i.e., through local switch) to the target UE without traversing back to the satellite gateway on the ground.
Local switching via UPF(s) deployed on satellite in this clause only applies on GEO satellite backhaul case and considers only DNNs and slices for 5G VN.
N19 tunnel may be established between two UPFs deployed on different satellites to locally switch UE to UE traffic.
Only a single SMF is supported for local switching and N19 forwarding, i.e. both UEs are served by the same SMF.
Clause 22.214.171.124 describes the case of PSA UPF deployed on satellite, clause 126.96.36.199 describes the case of ULCL and local PSA deployed on satellite (PSA UPF is on the ground). Selection of PSA UPF or UL CL/BP/local PSA on satellite is described in clause 6.3.3.
A combination of DNN/S-NSSAI is assigned by the operator to the services deployed on GEO satellite, the URSP configuration is described in TS 23.503.
If SMF selects the UPF deployed on satellite as PSA of UE's PDU Session, the SMF configures the UE's N4 session to forward/detect packet to/from the internal interface same as the configuration for the 5GVN group member's N4 Session in clause 188.8.131.52.1 (Support for unicast traffic forwarding of a 5G VN).
Based on pre-configuration, the SMF may establishes the N19 tunnel between PSA UPFs and set corresponding group-level N4 session rules utilizing IP address(s) in UPF address pool to forward/detect packet to/from the N19 tunnel interface.
For establishing N19 tunnel between the UPFs onboard the satellite, the UPFs are controlled by the same SMF.
To process packets between UE and servers residing in DN, SMF configures rules to route traffic via N6 as described in clause 184.108.40.206.1.
The group-level N4 session is per DNN and slice. The SMF can create, update or delete the group-level N4 Session, i.e., add or delete N4 rules, allocate or release the N19 tunnel resources based on operator deployment, e.g. based on GEO satellite's planed obsolescence or new GEO satellite setup.
For UPF deployed on satellite acting as ULCL/BP/local PSA case, the PSA UPF anchored by UE PDU sessions is on the ground, if the UEs are served by the same SMF, the SMF determines to activate local switching and N19 forwarding for the UEs using the GEO satellite backhaul, based on:
AF request including IP addresses of UEs which require UE-to-UE communications;
UE list or collection provision will reuse a NEF API name defined by the Edge_Ph2 topic.
Target IPs reported by on-ground PSA UPF as current reporting mechanism in clause 220.127.116.11.7. SMF configures the on-ground PAS UPF to detect UL packets with destination IP addresses which belong to the current UPF address pool.
After SMF receiving IP addresses from AF or on-ground PAS UPF, if SMF determines that UEs in communications are using the GEO satellites backhaul and UEs are allowed to access the DNAIs corresponding to the GEO satellites, for each UE communicating with target UE(s) in the communication group, the SMF selects the UPF deployed on GEO satellite according to the DNAI as UL-CL/BP and L-PSA, and configures UL-CL/BP with the following rule:
Route the data traffic received from the UE and destined to IP address(es) of the target UE(s) to the L-PSA.
Route other data traffic received from the UE to the PSA of the UE's PDU Session.
The SMF configures the Local PSA with local forwarding rules to forward the data traffic to the target UEs directly. If the selected L-PSAs are different for the UEs in the communication group, N19 tunnel is established between the L-PSAs. For establishing N19 tunnel between the UPFs onboard the satellite, the UPFs are controlled by the same SMF. The SMF regards the UEs in the communication group as members of a 5G VN group, and configures the local data forwarding rules on L-PSA(s) based on 5GVN user plane handing mechanism in clause 18.104.22.168.1 (Support for unicast traffic forwarding of a 5G VN).
If the AMF is aware that a satellite backhaul is used towards 5G AN, the AMF may report this to SMF as part of the PDU Session establishment procedure as described in clause 4.3.2 of TS 23.502. If AMF is aware that satellite backhaul category changes (e.g. at handover), the AMF reports the current satellite backhaul category and indicates the satellite backhaul category change to SMF.
Satellite backhaul category refers to the type of the satellite (i.e. GEO, MEO, LEO or OTHERSAT, DYNAMIC_GEO, DYNAMIC _MEO, DYNAMIC _LEO, DYNAMIC _OTHERSAT) used in the backhaul. Only a single backhaul category can be indicated.
If dynamic satellite backhaul is used by the NG-RAN, i.e. capabilities (latency and/or bandwidth) of the satellite backhaul change over time due to e.g., use of varying inter-satellite links as part of backhaul, the AMF notifies the SMF of the corresponding dynamic satellite backhaul category to serve the PDU Session.
If dynamic satellite backhaul is used, QoS monitoring can be used to obtain packet delay as specified in clause 5.33.3.
If AMF informs SMF that the dynamic satellite backhaul is used, the SMF informs this to PCF. The PCF may trigger QoS monitoring as specified in clause 5.33.3 if dynamic satellite backhaul is used.