Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 38.401  Word version:  17.1.1

Top   Top   Up   Prev   Next
1…   5…   6…   6.1.4   6.1.5…   6.2…   7…   8…   8.2…   8.2.2…   8.2.3…   8.2.4   8.2.5   8.3…   8.4…   8.4.4…   8.5…   8.9…   8.9.4…   8.9.6…   8.9.7…   8.10   8.11…   8.12…   8.13…   8.14…   8.15…   8.16…   8.17…   8.17.3…   8.17.4   8.18…   8.19…   8.19.2   8.19.3   8.19.4…   9…   A…

 

8.9.7  Trace activation/deactivation over F1 and E1 |R16|p. 68

Figure 8.9.7-1 shows the procedure used for the activation and the deactivation of UE traces in the gNB-DU, the gNB-CU-UP or both.
Reproduction of 3GPP TS 38.401, Fig. 8.9.7-1: Trace activation/deactivation over F1 and E1
Up
Step 1.
The gNB-CU-CP receives a TRACE START message from the AMF or the MeNB (in case of EN-DC).
Step 2.
The gNB-CU-CP initiates the Trace Start procedure by sending a TRACE START message to the gNB-DU, the gNB-CU-UP or both.
Step 3.
Upon reception of the TRACE START message, the gNB-DU, the gNB-CU-UP or both initiate the requested trace session and report it as described in TS 32.422.
Step 4.
The gNB-CU-CP receives a DEACTIVATE TRACE message from the AMF or the MeNB (in case of EN-DC).
Step 5.
The gNB-CU-CP initiates the Deactivate Trace procedure by sending a DEACTIVATE TRACE message to the gNB-DU, the gNB-CU-UP or both.
Step 6.
Upon reception of the DEACTIVATE TRACE message, the gNB-DU, the gNB-CU-UP or both stop the trace session for the indicated trace reference.
Up

8.9.8  BH RLC channel establishment procedure |R16|p. 68

The BH RLC channel is an RLC channel used for backhauling between IAB-node and IAB-donor-DU, or between different IAB-nodes. The BH RLC channel establishment may be triggered by a UE accessing the network and establishing a DRB.
Reproduction of 3GPP TS 38.401, Fig. 8.9.8-1: Signalling flow for IAB BH RLC channel establishment procedure
Up
Step 1.
The IAB-donor-CU sends to the IAB-donor-DU a UE CONTEXT MODIFICATION REQUEST message for setting up the parent-node IAB-DU side of the BH link between IAB-donor-DU and IAB-node 1. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-donor-DU and IAB-node 1.
Step 2.
The IAB-donor-DU sends the UE CONTEXT MODIFICATION RESPONSE message to the IAB-donor-CU.
Step 3.
The IAB-donor-CU sends to the IAB-donor-DU a DL RRC MESSAGE TRANSFER message encapsulating the RRCReconfiguration message for configuring the IAB-MT of IAB-node 1. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-donor-DU and IAB-node 1.
Step 4.
The IAB-donor-DU decapsulates and forwards the RRCReconfiguration message to the IAB-MT of IAB-node 1. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-donor-DU and IAB-node 1.
Step 5.
The IAB-MT of IAB-node 1 sends to the IAB-donor-DU an RRCReconfigurationComplete message destined to the IAB-donor-CU. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-donor-DU and IAB-node 1.
Step 6.
The IAB-donor-DU sends the UL RRC MESSAGE TRANSFER message encapsulating the RRCReconfigurationComplete message to the IAB-donor-CU. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-donor-DU and IAB-node 1.
Step 7.
The IAB-donor-CU sends to the IAB-DU of IAB-node 1 a UE CONTEXT MODIFICATION REQUEST message for setting up the parent node IAB-DU side of the BH link between IAB-node 1 and IAB-node 2. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-node 1 and IAB-node 2.
Step 8.
The IAB-node 1 sends the UE CONTEXT MODIFICATION RESPONSE message to the IAB-donor-CU.
Step 9.
The IAB-donor-CU sends to the IAB-DU of IAB-node 1 a DL RRC MESSAGE TRANSFER message encapsulating the RRCReconfiguration message for configuring the IAB-MT of IAB-node 2. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-node 1 and IAB-node 2.
Step 10.
The IAB-DU of IAB-node 1 decapsulates and forwards the RRCReconfiguration message to the IAB-MT of IAB-node 2. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-node 1 and IAB-node 2.
Step 11.
The IAB-MT of IAB-node 2 sends to IAB-node 1 an RRCReconfigurationComplete message destined to the IAB-donor-CU. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-node 1 and IAB-node 2.
Step 12.
IAB-node 1 sends the UL RRC MESSAGE TRANSFER message encapsulating the RRCReconfigurationComplete message to the IAB-donor-CU. This step is optional and is required only when a new BH RLC channel needs to be established on the BH link between IAB-node 1 and IAB-node 2.
The IAB-donor-CU uses the existing CU-DU split principles and the UE Context Setup procedure or UE Context Modification procedure to configure the parent IAB-DU side of the BH RLC channel. The IAB-donor-CU uses RRC signaling (which is encapsulated in the DL RRC MESSAGE TRANSFER message terminating at the parent node IAB-DU side of the BH RLC channel) to configure the child node IAB-MT side of the BH RLC channel.
The IAB-donor-CU configures the IAB-DU with a mapping to the BH RLC channel to be used for a specific UL F1-U tunnel during the UE Context Setup procedure or the F1-AP UE Context Modification procedure for the UE.
Up

8.9.9  Traffic Mapping |R16|p. 70

8.9.9.1  Traffic Mapping from IP-layer to Layer-2p. 70

When forwarding IP packets, the IAB-donor-DU performs the traffic mapping from IP-layer to layer-2 as defined in TS 38.340. The traffic mapping information is configured by the IAB-donor-CU, which contains the IP header information, and the BH information including the BAP routing ID and a list of egress link and BH RLC channel pairs.
Multiple traffic mappings can contain the same BAP routing ID and/or list of egress link and BH RLC channel pairs.
The traffic mappings can be configured as part of the UE Context Setup or UE Context Modification procedures. They may also be configured via the non-UE-associated BAP Mapping Configuration procedure.
The traffic mapping from IP-layer to layer-2 may include IPv6 Flow Label information. For DL F1 or X2 traffic, the IPv6 Flow Label information is set by the IAB-donor-CU or MeNB, respectively. When this traffic is protected via IPsec tunnel mode, the IPv6 Flow Label is set on the inner header by the IAB-donor-CU or MeNB, and the security gateway shall copy the IPv6 Flow Label from the inner IP header to the outer IP header to ensure that the IAB-donor-DU can perform the traffic mapping considering the IPv6 Flow Label.
Up

8.9.9.2  BH RLC Channel Mapping on BAP Layerp. 70

When traffic is forwarded on BAP layer as described in TS 38.300, the IAB-node performs the BH RLC channel mapping as defined in TS 38.340. The BH RLC channel mapping information is configured by the IAB-donor-CU.
The BH RLC channel mappings can be configured as part of the UE Context Setup or UE Context Modification procedures. They may also be configured via the non-UE-associated BAP Configuration procedure.
Up

8.9.10  IAB-node release |R16|p. 70

An IAB-node may depart the network either in an orderly fashion, which implies that both the network and the IAB-node are aware in advance, or in a disorderly fashion (e.g. due to an RLF with failed recovery).

8.9.10.1  IAB-node orderly releasep. 71

For orderly release, the IAB-donor-CU can remove the F1 interface connection to the IAB-DU without releasing the IAB-MT. If the IAB-MT needs to be released, IAB-MT will perform the deregistration procedure. If both F1 interface and IAB-MT need to be released, the IAB-donor-CU should remove the F1 interface to the IAB-DU before it releases the collocated IAB-MT. The deregistration procedure is the same as the UE deregistration procedure. The IAB-donor-CU hands over the UEs or child IAB-nodes currently connected to the IAB-node's cell(s) to another cell(s), or releases the UEs and may stop accepting incoming handovers or connections to the IAB-node that is about to be released. The IAB-donor-CU may also update/release the BH RLC channels in the intermediate hops. At this point, the F1 interface will be released and the corresponding SCTP associations will be removed.
Up

8.9.10.2  IAB-node disorderly releasep. 71

For the disorderly release case, how to remove the IAB-node context is up to network implementation.

8.9.11  IAB-node OAM |R16|p. 71

The IAB-node receives commands, configuration data and software downloads (e.g. for equipment software upgrades) from its OAM system. The IAB-node can also send alarms and traffic counter information to its OAM system. The transport connection between the IAB-node and its OAM, using IP, is provided by the IAB-MT's PDU session via 5G network, or the IAB-MT's PDN connection via LTE network when IAB-MT uses EN-DC.
Alarms in the IAB generate bursts of high-priority traffic, to be transported in real time. Traffic counters generate bursts of traffic, but their transport need not be real-time. Configuration messages from OAM to the IAB will also generate small bursts of traffic, possibly with lower priority than alarms but still delay-sensitive: when a configuration is committed on the OAM, the time interval between the commitment and the effect on the equipment shall be small. Alarm messages and commands should be transported on a high-priority bearer, while counters may be transported on a lower priority bearer.
OAM software download to the IAB may generate larger amounts of data, but both the required data rate and the priority of this kind of traffic are much lower than in the case of alarms, commands and counters.
For different types of OAM traffic, it is necessary to use different DRBs between the IAB-MT and the serving DU, and different BH RLC channels for intermediate hops, with different QoS parameters. Aggregation of F1-U traffic for OAM with other F1-U traffic on the same BH RLC channels is not precluded. The QoS parameters are provided to the IAB-donor during the IAB-MT's PDU session establishment, or the IAB-MT's PDN connection establishment when IAB-MT uses EN-DC.
Up

8.9.12  Handling of IAB-MTs in INACTIVE State |R16|p. 71

The IAB-MT optionally supports the RRC INACTIVE state. Upon the IAB-MT entering the RRC INACTIVE state, it is up to implementation to keep or release the F1 connection of the collocated IAB-DU.

8.9.13  IP Address Allocation for IAB-nodes |R16|p. 71

An IAB-node may obtain IP address(es) either from the IAB-donor or from the OAM system. The IP address(es) is(are) used by the IAB-node for F1 and non-F1 traffic exchange via the backhaul. In case IPsec tunnel mode is used to protect this F1 and non-F1 traffic, the IP address(es) refer to the outer tunnel addresses. The allocation of the inner tunnel IP address(es) is outside of 3GPP scope.
In case of IAB-donor-based IP address allocation, the IP address(es) is(are) allocated by the IAB-donor-CU or IAB-donor-DU. In both cases, the IAB-node requests the IP address(es) via RRC from the IAB-donor-CU. It includes a separate IP address request for each usage, where the usages defined are all traffic, F1-U, F1-C and non-F1. The IAB-donor-CU may initiate the IAB TNL Address Allocation procedure to obtain IP addresses from the IAB-donor-DU. The IAB-donor-CU sends the IP addresses allocated for each usage to the IAB-node via RRC. r each usage to the IAB-node via RRC. In case of IAB inter-CU topology management, the F1-terminating IAB-donor-CU may obtain the IP addresses for each usage in the non-F1-terminating IAB-donor-CU's topology from the non-F1-terminating IAB-donor-CU for the boundary IAB-node and the descendant IAB-nodes of the boundary IAB-node.
The IAB-node may be allocated one or multiple IPv6 addresses or one 64-bit IPv6 prefix for each usage and/or one or multiple IPv4 addresses for each usage. Each allocated IP address/IPv6 prefix is unique within the IAB network and routable from the wireline network.
In case of OAM-based IP address allocation, the IAB-node informs the IAB-donor-CU via an UL RRC message about the IP address(es) it received for each purpose. This occurs before the IAB node uses the IP address(es) for UL and/or DL traffic.
The IAB-donor-CU configures the IAB-donor-DU with mappings between IP header fields and L2 parameters (BAP Routing ID, BH RLC channels) used for DL traffic. Each mapping configuration may hold an IPv4 address, IPv6 address or a 64-bit IPv6 prefix. In case of two mapping entries matching the same IP header where one holds an IPv6 prefix and the other holds a full IPv6 address, the one with full IPv6 address takes precedence at the IAB-donor-DU.
In case of IAB-donor-allocated IP addresses, the IAB-node's IP address(es) can be updated using DL RRC signalling.
For F1-C traffic transfer for NSA IAB, the LTE leg and NR leg should use separate IP address pairs {IAB-DU's IP address, IAB-donor-CU's IP address}. How the IAB-DU gets the remote IP end point(s) and its own IP address for LTE leg is not specified in this release.
Up

Up   Top   ToC