Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 38.401  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   5…   6…   6.2…   7…   8…   8.2…   8.2.2   8.2.3   8.2.4…   8.3   8.4…   8.5…   8.9…   8.10…   9…

 

8.2.4  Intra-CU topological redundancy procedure |R16|

The intra-CU topological redundancy procedure enables the establishment and release of redundant paths in the IAB-topology underneath the same IAB-donor-CU. The redundant paths may use different IAB-donor-DUs. They may also have common intermediate nodes. Since topological redundancy uses NR-DC for the IAB-MT, it is only supported for IAB-nodes operating in SA mode. Figure 8.2.4-1 shows an example for an IAB topology, where one IAB-node, referred to as the dual-connecting IAB-node, has two paths towards the IAB-donor via different IAB-donor-DUs.
[not reproduced yet]
Figure 8.2.4-1: Example for IAB topology with two redundant paths
Up
[not reproduced yet]
Figure 8.2.4-2: Procedure for establishment of redundant path in IAB topology
Up
Figure 8.2.4-2 shows the procedure for the establishment of the second path. This procedure has the following steps:
Step 1.
The dual-connecting IAB-MT sends a MeasurementReport message to the first parent node IAB-DU. This report is based on a Measurement Configuration the dual-connecting IAB-MT received from the IAB-donor-CU before.
Step 2.
The first parent node IAB-DU sends an UL RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received MeasurementReport.
Step 3.
The IAB-donor-CU sends the UE CONTEXT SETUP REQUEST message to the second parent node IAB-DU, to create the UE context for the dual-connecting IAB-MT and to set up one or more bearers. These bearers can be used by the dual-connecting IAB-MT for its own signalling, and, optionally, data traffic.
Step 4.
The second parent node IAB-DU responds to the IAB-donor-CU with a UE CONTEXT SETUP RESPONSE message.
Step 5.
The IAB-donor-CU sends a DL RRC MESSAGE TRANSFER message to the first parent node IAB-DU, which includes a generated RRCReconfiguration message. The RRCReconfiguration message may contain one or more TNL address(es) for the dual-connecting IAB-DU, which are anchored at the second-path IAB-donor-DU. The IAB-donor-CU can proactively obtain these TNL addresses from the second-path IAB-donor-DU. In case IPsec tunnel mode is used to protect the F1 and non-F1 traffic, the allocated TNL address is the outer IP address. The TNL address allocation is not necessary if the first and second paths use the same IAB-donor-DU.
Step 6.
The first parent node IAB-DU forwards the received RRCReconfiguration message to the dual-connecting IAB-MT.
Step 7.
The dual-connecting IAB-MT responds to the first parent node IAB-DU with an RRCReconfigurationComplete message.
Step 8.
The first parent node IAB-DU sends an UL RRC MESSAGE TRANSFER message to the IAB-donor-CU, to convey the received RRCReconfigurationComplete message.
Step 9.
A Random Access procedure is performed at the second parent node IAB-DU.
Step 10.
The IAB-donor-CU configures BH RLC channels and BAP-layer route entries on the second path between dual-connecting IAB-node and second-path IAB-donor-DU. These configurations may be performed at an earlier stage, e.g. immediately after step 3.
Step 11.
The new TNL addresses allocated in step 5 (if any) are added to the dual-connecting IAB-DU's F1-C association(s) with the IAB-donor-CU. The IAB-donor-CU may configure new UL BH information on the second path for F1AP messages.
Step 12.
The IAB-donor-CU may migrate the F1-U tunnels it has with the dual-connecting IAB-DU from the first path to the second path via the UE CONTEXT MODIFICATION REQUEST message.
Step 13.
The dual-connectivity IAB-DU replies with a UE CONTEXT MODIFICATION RESPONSE message.
Steps 12 and 13 can be performed for a subset of UE bearers, e.g., to balance the load between the first and the second path.
In case the second path is used for the dual-connecting IAB-node's descendant node(s), Steps 10 and 11 are also performed for the descendant node(s), as follows:
When the second path uses a different IAB-donor-DU, the IAB-donor-CU shall configure the descendent IAB-DU(s) with one or more new TNL addresses, which are anchored on the IAB-donor-DU of the second path.
If needed, the IAB-donor-CU configures BH RLC channels, BAP-layer route entries on the target path for the descendant nodes and the BH RLC channel mappings on the descendant nodes in the same manner as described for the dual-connecting IAB-node in step 10.
The descendant nodes' new TNL addresses (if any) are added to the descendant node IAB-DU's F1-C association(s) with the IAB-donor-CU. The IAB-donor-CU may configure UL BH information for the second path to carry F1AP messages.
The IAB-donor-CU may migrate the F1-U tunnels it has with the dual-connecting IAB-node's descendant node(s) from the first path to the second path, as described for step 12.
Based on implementation, these steps can be performed after or in parallel with the redundant path addition of the dual connecting IAB-node.
The IAB-donor-CU may initiate the release of the redundant path by releasing the BAP routing entries and modifying/releasing the BH RLC channels on that path.
Up

8.2.5  Intra-CU Backhaul RLF recovery for IAB-nodes in SA mode |R16|Word‑p. 36
The intra-CU backhaul RLF recovery procedure for IAB-nodes in SA mode enables migration of an IAB-node to another parent node underneath the same IAB-donor-CU, when the IAB-MT declares a backhaul RLF. The declaration of backhaul RLF is described in TS 38.331.
Figure 8.2.5-1 shows an example of the BH RLF recovery procedure for an IAB-node in SA mode. In this example, the IAB-node changes from its initial parent node to a new parent node, where the new parent node is served by an IAB-donor-DU different than the one serving its initial parent node.
[not reproduced yet]
Figure 8.2.5-1: IAB intra-CU backhaul RLF recovery procedure for an IAB-node in SA mode
Up
Step 1.
The IAB-MT declares BH RLF for the MCG as described in TS 38.331, clause 5.3.10.3.
Step 2.
The IAB-MT undergoing recovery from RLF conducts the RRC re-establishment procedure at the new parent node, as defined in clause 8.7. In this procedure, the IAB-donor-CU may provide new TNL address(es), which is(are) anchored at the new IAB-donor-DU, to the IAB-MT via RRC signalling. Furthermore, the IAB-donor-CU may also provide a new default UL mapping which includes a default BH RLC channel and a default BAP Routing ID for UL F1-C/non-F1 traffic on the target path, to the IAB-node undergoing recovery from RLF via RRCReconfiguration message in this procedure.
Step 3.
The remaining part of the procedure follows the steps 11-15 of the intra-CU topology adaptation procedure defined in clause 8.2.3.1.
Descendant node(s) of the IAB-node undergoing recovery from RLF may also need to switch to new TNL address(es) anchored in the target-path IAB-donor-DU following the same mechanism as described for IAB intra-CU topology adaptation procedure in clause 8.2.3.1. The descendant node(s) may also be provided with new default UL mapping via RRC, after the IAB-node undergoing recovery from RLF connects the IAB-donor-CU via the recovery path.
Up


Up   Top   ToC