Tech-invite  3GPPspecsRELsGlossariesSIP

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8………   4.2.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.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]Word-p. 327
5.35.1  IAB architecture and functional entities
Integrated access and backhaul (IAB) enables wireless in-band and out-of-band relaying of NR Uu access traffic via NR Uu backhaul links. 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 the PLMN it is registered with) is referred to as an IAB-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 5GC, e.g. SMF, may detect that a PDU session for the IAB-UE is for the OAM system access, e.g. by checking the DNN and/or configuration. It is up to the operator configuration to choose whether to use 1 or multiple QoS flows for OAM traffic and the appropriate QoS parameters, e.g. using 5QI=6 for software downloading, and 5QI=80 with signalled higher priority or a pre-configured 5QI for alarm or control traffic.
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.
5.35.2  5G System enhancements to support IABWord-p. 328
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.
Editor's note: The following are the expected system enhancements to assist the development of the CRs for IAB. It will be revised and updated based on RAN WG's conclusion.
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.
Editor's note: Security aspect is being studied by SA WG3, and the above will be revised and aligned after the conclusion of the study.
The following aspects are enhanced to support the IAB operation:
  • the Registration procedure as defined in TS 23.502, clause 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 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 TS 23.502, clause 5.2.3 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 TS 23.502, clause to disconnect from the network.
5.35.3  Data handling and QoS support with IAB
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.
5.35.4  Mobility support with IABWord-p. 329
For UEs, all existing NR intra-RAT mobility and dual-connectivity procedures are supported when the UE is served by an IAB-node. 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 IAB
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 EPC
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.
For a particular PLMN, it is expected that only one of the modes would be deployed in a known region.
5.36  RIM Information Transfer [R16]
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, TS 29.518. The AMF does not interpret the transferred RIM information.

Up   Top   ToC