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.9  Overall procedures involving E1 and F1Word‑p. 47
The following clauses describe the overall procedures involving E1 and F1.

8.9.1  UE Initial Access

The signalling flow for UE Initial access involving E1 and F1 is shown in Figure 8.9.1-1.
[not reproduced yet]
Figure 8.9.1-1: UE Initial Access procedure involving E1 and F1
Up
Step 1-8.
Steps 1-8 are defined in clause 8.1.
Step 9.
The gNB-CU-CP sends the BEARER CONTEXT SETUP REQUEST message to establish the bearer context in the gNB-CU-UP.
Step 10.
The gNB-CU-UP sends the BEARER CONTEXT SETUP RESPONSE message to the gNB-CU-CP, including F1-U UL TEID and transport layer address allocated by the gNB-CU-UP.
Step 11-13.
Steps 11-13 are defined in clause 8.1.
Step 14.
The gNB-CU-CP sends the BEARER CONTEXT MODIFICATION REQUEST message to the gNB-CU-UP, including F1-U DL TEID and transport layer address allocated by the gNB-DU.
Step 15.
The gNB-CU-UP sends the BEARER CONTEXT MODIFICATION RESPONSE message to the gNB-CU-CP.
Step 16-22.
Steps 16-22 are defined in clause 8.1.
Up

8.9.2  Bearer context setup over F1-UWord‑p. 48
Figure 8.9.2-1 shows the procedure used to setup the bearer context in the gNB-CU-UP.
[not reproduced yet]
Figure 8.9.2-1: Bearer context setup over F1-U
Up
Step 0.
Bearer context setup (e.g., following an SGNB ADDITION REQUEST message from the MeNB) is triggered in gNB-CU-CP.
Step 1.
The gNB-CU-CP sends a BEARER CONTEXT SETUP REQUEST message containing UL TNL address information for S1-U or NG-U, and if required, DL TNL address information for X2-U or Xn-U to setup the bearer context in the gNB-CU-UP. For NG-RAN, the gNB-CU-CP decides flow-to-DRB mapping and sends the generated SDAP and PDCP configuration to the gNB-CU-UP.
Step 2.
The gNB-CU-UP responds with a BEARER CONTEXT SETUP RESPONSE message containing the UL TNL address information for F1-U, and DL TNL address information for S1-U or NG-U, and if required, UL TNL address information for X2-U or Xn-U.
Step 3.
F1 UE context setup procedure is performed to setup one or more bearers in the gNB-DU.
Step 4.
The gNB-CU-CP sends a BEARER CONTEXT MODIFICATION REQUEST message containing the DL TNL address information for F1-U and PDCP status.
Step 5.
The gNB-CU-UP responds with a BEARER CONTEXT MODIFICATION RESPONSE message.
Up

8.9.3  Bearer context release over F1-UWord‑p. 49

8.9.3.1  gNB-CU-CP initiated bearer context release

Figure 8.9.3.1-1 shows the procedure used to release the bearer context in the gNB-CU-UP initiated by the gNB-CU-CP.
[not reproduced yet]
Figure 8.9.3.1-1: Bearer context release over F1-U - gNB-CU-CP initiated
Up
Step 0.
Bearer context release (e.g., following an SGNB RELEASE REQUEST message from the MeNB) is triggered in gNB-CU-CP.
Step 1.
The gNB-CU-CP sends a BEARER CONTEXT MODIFICATION REQUEST message to the gNB-CU-UP.
Step 2.
The gNB-CU-UP responds with a BEARER CONTEXT MODIFICATION RESPONSE carrying the PDCP UL/DL status.
Step 3.
F1 UE context modification procedure is performed to stop the data transmission for the UE. It is up to gNB-DU implementation when to stop the UE scheduling.
Step 4.
The gNB-CU-CP may receive the UE CONTEXT RELEASE message from the MeNB in EN-DC operation as described in Section 8.4.2.1.
Step 5-7.
Bearer context release procedure is performed.
Step 6.
F1 UE context release procedure is performed to release the UE context in the gNB-DU.
Up

8.9.3.2  gNB-CU-UP initiated bearer context releaseWord‑p. 50
Figure 8.9.3.2-1 shows the procedure used to release the bearer context in the gNB-CU-UP initiated by the gNB-CU-UP.
[not reproduced yet]
Figure 8.9.3.2-1: Bearer context release over F1-U - gNB-CU-UP initiated
Up
Step 0.
Bearer context release is triggered in gNB-CU-UP e.g., due to local failure.
Step 1.
The gNB-CU-UP sends a BEARER CONTEXT RELEASE REQUEST message to request the release of the bearer context in the gNB-CU-UP. This message may contain the PDCP status.
Step 2-5.
If the PDCP status needs to be preserved, the E1 Bearer Context Modification and the F1 UE Context Modification procedures are performed. The E1 Bearer Context Modification procedure is used to convey data forwarding information to the gNB-CU-UP. The gNB-CU-CP may receive the UE Context Release from the MeNB.
Step 6.
The gNB-CU-CP sends a BEARER CONTEXT RELEASE COMMAND message to release the bearer context in the gNB-CU-UP.
Step 7.
The gNB-CU-UP responds with a BEARER CONTEXT RELEASE COMPLETE to confirm the release of the bearer context including also data forwarding information.
Step 8.
F1 UE context release procedure may be performed to release the UE context in the gNB-DU.
Up

8.9.4  Inter-gNB handover involving gNB-CU-UP changeWord‑p. 51
Figure 8.9.4-1 shows the procedure used for inter-gNB handover involving gNB-CU-UP change. Overall inter-gNB handover procedure is specified in TS 37.340.
[not reproduced yet]
Figure 8.9.4-1: Inter-gNB handover involving gNB-CU-UP change
Up
Step 1.
The source gNB-CU-CP sends HANDOVER REQUEST message to the target gNB-CU-CP. In case of Conditional Handover, the target gNB is regarded as a candidate gNB which is only accessed by the UE when the CHO condition(s) are fulfilled.
Step 2-4.
Bearer Context Setup procedure is performed as described in Section 8.9.2.
Step 5.
The target gNB-CU-CP responds the source gNB-CU-CP with an HANDOVER REQUEST ACKNOWLEDGE message.
Step 6.
The F1 UE Context Modification procedure is performed to send the handover command to the UE, and to indicate to stop the data transmission for the UE.
Step 7-8.
Bearer Context Modification procedure (gNB-CU-CP initiated) is performed to enable the gNB-CU-CP to retrieve the PDCP UL/DL status and to exchange data forwarding information for the bearer.
Step 9.
The source gNB-CU-CP sends an SN STATUS TRANSFER message to the target gNB-CU-CP.
Step 10-11.
Bearer Context Modification procedure is performed as described in Section 8.9.2. The COUNT related info carried by the EARLY STATUS TRANSFER message is also provided to the target gNB-CU-UP.
Step 12.
Data Forwarding may be performed from the source gNB-CU-UP to the target gNB-CU-UP.
Step 12a.
In case of DAPS Handover or Conditional Handover, the target gNB-CU-CP sends the HANDOVER SUCCESS message to the source gNB-CU-CP to inform that the UE has successfully accessed the target cell.
Step 12b.
In case of DAPS Handover or Conditional Handover, the F1 UE Context Modification procedure is performed to indicate to stop the data transmission for the UE.
Step 12c-12d.
In case of DAPS Handover or Conditional Handover, the Bearer context modification procedure (gNB-CU-CP initiated) is performed to indicate the source gNB-CU-UP to stop packet delivery and also to retrieve the PDCP UL/DL status.
Step 12e.
In case of DAPS Handover or Conditional Handover, the source gNB-CU-CP sends the SN STATUS TRANSFER message to the target gNB-CU-CP.
Step 12f-12g.
In case of DAPS Handover or Conditional Handover, the Bearer context modification procedure is performed to provide the PDCP UL/DL status to the target gNB-CU-UP.
Step 13-15.
Path Switch procedure is performed to update the DL TNL address information for the NG-U towards the core network.
Step 16.
The target gNB-CU-CP sends an UE CONTEXT RELEASE message to the source gNB-CU-CP.
Step 17 and 19.
Bearer Context Release procedure is performed.
Step 18.
F1 UE Context Release procedure is performed to release the UE context in the source gNB-DU.
Up

8.9.5  Change of gNB-CU-UPWord‑p. 53
Figure 8.9.5-1 shows the procedure used for the change of gNB-CU-UP within a gNB.
[not reproduced yet]
Figure 8.9.5-1: Change of gNB-CU-UP
Up
Step 1.
Change of gNB-CU-UP is triggered in gNB-CU-CP based on e.g., measurement report from the UE.
Step 2-3.
Bearer Context Setup procedure is performed as described in Section 8.9.2.
Step 4.
F1 UE Context Modification procedure is performed to change the UL TNL address information for F1-U for one or more bearers in the gNB-DU.
Step 5-6.
Bearer Context Modification procedure (gNB-CU-CP initiated) is performed to enable the gNB-CU-CP to retrieve the PDCP UL/DL status and to exchange data forwarding information for the bearer.
Step 7-8.
Bearer Context Modification procedure is performed as described in Section 8.9.2.
Step 9.
Data Forwarding may be performed from the source gNB-CU-UP to the target gNB-CU-UP.
Step 10-12.
Path Switch procedure is performed to update the DL TNL address information for the NG-U towards the core network.
Step 13-14.
Bearer Context Release procedure (gNB-CU-CP initiated) is performed as described in Section 8.9.3.
Up

8.9.6  RRC State transitionWord‑p. 54

8.9.6.1  RRC Connected to RRC Inactive

The procedure for changing the UE state from RRC-connected to RRC-inactive is shown in Figure 8.9.6.1-1.
[not reproduced yet]
Figure 8.9.6.1-1: RRC Connected to RRC Inactive state transition.
Up
Step 1.
The gNB-CU-CP sends BEARER CONTEXT SETUP REQUEST message with UE/PDU session/DRB level inactivity timer.
Step 2.
The gNB-CU-UP sends BEARER CONTEXT SETUP RESPONSE message.
Step 3.
The gNB-CU-UP sends BEARER CONTEXT INACTIVITY NOTIFICATION message with inactivity monitoring results.
Step 4.
The gNB-CU-CP determines that the UE should enter RRC-inactive (e.g., after receiving Bearer Context Inactivity Notification procedure).
Step 5.
The gNB-CU-CP sends BEARER CONTEXT MODIFICATION REQUEST message with a Bearer Context Status Change to the gNB-CU-UP, which indicates that the UE is entering RRC-inactive state. The gNB-CU-CP keeps the F1 UL TEIDs.
Step 6.
The gNB-CU-UP sends the BEARER CONTEXT MODIFICATION RESPONSE message including the PDCP UL and DL status that may be needed for e.g., data volume reporting. The gNB-CU-UP keeps the Bearer Context, the UE-associated logical E1-connection, the NG-U related resource (e.g., NG-U DL TEIDs) and the F1 UL TEIDs.
Step 7.
The gNB-CU-CP sends the UE CONTEXT RELEASE COMMAND message to the gNB-DU serving the UE, together with the RRCRelease message to be sent to the UE.
Step 8.
The gNB-DU sends the RRCRelease message to the UE.
Step 9.
The gNB-DU sends the UE CONTEXT RELEASE COMPLETE message to the gNB-CU-CP.
Up

8.9.6.2  RRC Inactive to other statesWord‑p. 55
The procedure for changing the UE state from RRC-inactive to RRC-connected is shown in Figure 8.9.6.2-1.
[not reproduced yet]
Figure 8.9.6.2-1: RRC Inactive to RRC Connected state transition.
Up
Step 0.
The gNB-CU-UP receives DL data on NG-U interface.
Step 1.
The gNB-CU-UP sends DL DATA NOTIFICATION message to the gNB-CU-CP.
Step 2.
The gNB-CU-CP initiates PAGING procedure.
Step 3.
The gNB-DU sends the Paging message to the UE.
Step 4.
The UE sends RRCResumeRequest message either upon RAN paging or UL data arrival.
Step 5.
The gNB-DU sends the INITIAL UL RRC MESSAGE TRANSFER message to the gNB-CU-CP.
Step 6.
The gNB-CU-CP sends UE CONTEXT SETUP REQUEST message including the stored F1 UL TEIDs to create the UE context in the gNB-DU.
Step 7.
The gNB-DU responds with the UE CONTEXT SETUP RESPONSE message including the F1 DL TEIDs allocated for the DRBs.
Step 8.
The gNB-CU-CP and the UE perform the RRC-Resume procedure via the gNB-DU.
Step 9.
The gNB-CU-CP sends BEARER CONTEXT MODIFICATION REQUEST message with a RRC Resume indication, which indicates that the UE is resuming from RRC-inactive state. The gNB-CU-CP also includes the F1 DL TEIDs received from the gNB-DU in step 7.
Step 10.
The gNB-CU-UP responds with theBEARER CONTEXT MODIFICATION RESPONSE message.
Up

8.9.7  Trace activation/deactivation over F1 and E1 |R16|Word‑p. 57
Figure 8.9.6-1 shows the procedure used for the activation and the deactivation of UE traces in the gNB-DU, the gNB-CU-UP or both.
[not reproduced yet]
Figure 8.9.6-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|

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.
[not reproduced yet]
Figure 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|Word‑p. 59

8.9.9.1  Traffic Mapping from IP-layer to Layer-2

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

8.9.9.2  BH RLC Channel Mapping on BAP Layer

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|

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 release

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 releaseWord‑p. 60
For the disorderly release case, how to remove the IAB-node context is up to network implementation.

8.9.11  IAB-node OAM |R16|

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|

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|

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