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.10  Multiple TNLAs for E1Word‑p. 61
In the following, the procedure for managing multiple TNLAs for E1 is described.
[not reproduced yet]
Figure 8.10-1: Managing multiple TNLAs for E1.
Up
Step 1.
Either the gNB-CU-CP or gNB-CU-UP establishes the first SCTP association with the gNB-CU-UP or gNB-CU-CP respectively using a configured TNL address.
Step 2-3 (A).
Once the TNLA (gNB-CU-UP initiated) has been established, the gNB-CU-UP initiates the E1 Setup procedure to exchange application level configuration data
Step 2-3 (B).
Once the TNLA (gNB-CU-CP initiated) has been established, the gNB-CU-CP initiates the E1 Setup procedure to exchange application level configuration data
Step 4-6.
The gNB-CU-CP may add additional SCTP Endpoint(s) to be used for E1 signalling between the gNB-CU-CP and the gNB-CU-UP pair using the gNB-CU-CP Configuration Update procedure. The gNB-CU-CP Configuration Update procedure also allows the gNB-CU-CP to request the gNB-CU-UP to modify or release TNLA(s).
Step 7-9.
The gNB-CU-UP may add additional TNL association(s) to be used for E1 signalling using a gNB-CU-CP endpoint already in use for existing TNL associations between the gNB-CU-CP and the gNB-CU-UP pair. The gNB-CU-UP CONFIGURATION UPDATE message including the gNB-CU-UP ID shall be the first E1AP message sent on an additional TNLA of an already setup E1 interface instance after the TNL association has become operational. The E1AP UE TNLA binding is a binding between a E1AP UE association and a specific TNL association for a given UE. After the E1AP UE TNLA binding is created, the gNB-CU-CP can update the UE TNLA binding by sending the E1AP message for the UE to the gNB-CU-UP via a different TNLA. The gNB-CU-UP shall update the E1AP UE TNLA binding with the new TNLA. The gNB-CU-UP Configuration Update procedure also allows the gNB-CU-UP to inform the gNB-CU-CP that the indicated TNLA(s) will be removed by the gNB-CU-UP.
Up

8.11  Support of Network Sharing with multiple cell-ID broadcastWord‑p. 62

8.11.1  General

This section describes necessary additions as compared to the case where network sharing with multiple cell-ID broadcast is not applied.
The signalling flows in the subsequent sections assuming 2 sharing operators, A and B. The F1-C signalling transport deployment used is indicated within the subsequent sections.

8.11.2  Initial Registration - separate PLMN signalling

The signalling flow for Initial Registration for network sharing with multiple cell-ID broadcast with separate per-PLMN signalling is shown in Figure 8.11.2-1.
In this example message flow
  • the UE is assumed to not provide an ue-Identity from which the DU is able to deduce the PLMN ID.
  • each F1-C interface instance uses a separate signalling transport or share signalling transport with other F1-C interface instances.
  • the gNB-DUA/B entity shown in Figure 8.11.2-1 is a simplified representation of the gNB-DUA of PLMN A, the gNB DUB of PLMN B and respective radio resources of the shared cell.
[not reproduced yet]
Figure 8.11.2-1: UE Initial Access procedure and network sharing with multiple cell-ID broadcast
Up
Step 6.
The gNB-DUA sends the F1AP UE CONTEXT RELEASE REQUEST message to the gNB-CUA. including a Cause set to "PLMN not served by the CU".
Step 7.
The gNB-DUB sends the F1AP INITIAL UL RRC MESSAGE to the gNB-CUB. including the NR CGI associated with PLMNB, the C-RNTI indicated by the gNB-DUA at step 2, and the RRC-Container IE and the RRC-Container-RRCSetupComplete IE with the RRC message received in step1 and step 5 respectively. The RRC-Container-RRCSetupComplete IE are included in the INITIAL UL RRC MESSAGE TRANSFER for the case of network sharing and shall contain the RRC messages received via the RRC UL-DCCH-Message IE from the UE, but never previously sent to the gNB-CUB.
Step 8.
The gNB-CUA triggers the F1AP UE Context Release procedure.
Up

8.11.3  RRC Connection Reestablishment - separate PLMN signallingWord‑p. 63
The signalling flow for RRC Connection Reestablishment for network sharing with multiple cell-ID broadcast with separate per-PLMN signalling is shown in Figure 8.11.3-1.
In this example message flow
  • each F1-C/Xn-C interface instance uses either a separate signalling transport or a share signalling transport with other interface instances.
  • the New gNB-DUA/B entity shown in Figure 8.11.3-1 is a simplified representation of the New gNB-DUA of PLMN A, the New gNB DUB of PLMN B and respective radio resources of the shared cell.
[not reproduced yet]
Figure 8.11.3-1: RRC Connection Reestablishment and network sharing with multiple cell-ID broadcast
Up
Step 1.
The UE sends the RRCReestablishmentRequest.
Step 2A-5A.
Depicts the case where the UE context could not be retrieved by the new gNB-CUA. In step 2A, the NR CGI associated to PLMNA is indicated. In step 5A, the gNB-CUA would prepare the possibility to revert back to normal RRC Connection Establishment, indicating that the UE Context was not retrieveable and may include the re-directed RRC message as received in step 1. After step 5A, the gNB-DUA may redirect the UE towards the PLMN indicated in DL RRC message transfer, if the PLMN assistance information is provided by the gNB-CUA. If the New gNB-DUA/B was not able to deduce the RRC message from step 1, this indicator triggers step 2B. The New gNB-DUA is supposed to trigger the release the UE-associated signalling connection (not shown).
Step 2B-5B.
Depicts the case where the UE context was retrieveable by the New gNB-CUB. In step 2B, the NR CGI associated to PLMNB is indicated. Step 2B also includes the C-RNTI allocated at reception of step 1.
Step 6-8.
The RRC Connection Reestablishment continues with the New gNB-CUB.
Up

8.11.4  Support of shared signalling transportWord‑p. 64
This section specifies for F1-C, Xn-C and, in case of EN-DC, for X2-C, how an interface instance is identified in case of network sharing with multiple cell ID broadcast with shared signalling transport.
For UE associated signalling, the interface instance is identified by assigning on F1-C appropriate UE F1AP IDs, on Xn-C appropriate UE XnAP IDs and on X2-C appropriate UE X2AP IDs.
For non-UE associated signalling, the interface instance is identified on F1-C by the assigning an appropriate value to the Transaction ID, on Xn-C and X2-C by including the Interface Instance Indication in the respective message and assigning an appropriate value to it.
Up

8.12  IAB-node Integration Procedure |R16|Word‑p. 65

8.12.1  Standalone IAB integration

A high-level flow chart for SA-based IAB integration is shown in the Figure 8.12.1-1:
[not reproduced yet]
Figure 8.12.1-1: The integration procedure for IAB-node in SA
Up
Phase 1)
IAB-MT setup. In this phase, the IAB-MT of the new IAB-node (e.g. IAB-node 2 in Figure 8.12.1-1) connects to the network in the same way as a UE, by performing RRC connection setup procedure with IAB-donor-CU, authentication with the core network, IAB-node 2-related context management, IAB-node 2's access traffic-related radio bearer configuration at the RAN side (SRBs and optionally DRBs), and, optionally, OAM connectivity establishment by using the IAB-MT's PDU session. The IAB-node can select the parent node for access based on an over-the-air indication from potential parent node IAB-DU (transmitted in SIB1). To indicate its IAB capability, the IAB-MT includes the IAB-node indication in RRCSetupComplete message, to assist the IAB-donor to select an AMF supporting IAB.
Phase 2-1)
BH RLC channel establishment. During the bootstrapping procedure, one default BH RLC channel for non-UP traffic e.g. carrying F1-C traffic/non-F1 traffic to and from the IAB-node 2 in the integration phase, is established. This may require the setup of a new BH RLC channel or modification of an existing BH RLC channel between IAB-node 1 and IAB-donor-DU. The IAB-donor-CU may establish additional (non-default) BH RLC channels. This phase also includes configuring the BAP Address of the IAB-node 2 and default BAP Routing ID for the upstream direction.
Phase 2-2)
Routing update. In this phase, the BAP sublayer is updated to support routing between the new IAB-node 2 and the IAB-donor-DU. For the downstream direction, the IAB-donor-CU initiates F1AP procedure to configure the IAB-donor-DU with the mapping from IP header field(s) to the BAP Routing ID related to IAB-node 2. The routing tables are updated on all ancestor IAB-nodes (e.g. IAB-node 1 in Figure 8.12.1-1) and on the IAB-donor-DU, with routing entries for the new BAP Routing ID(s). This phase may also include the IP address allocation procedure for IAB-node 2. IAB-node 2 may request one or more IP addresses from the IAB-donor-CU via RRC. The IAB-donor-CU may send the IP address(es) to the IAB-node 2 via RRC. The IAB-donor-CU may obtain the IP address(es) from the IAB-donor-DU via F1-AP or by other means (e.g. OAM, DHCP). IP address allocation procedure may occur at any time after RRC connection has been established.
Phase 3)
IAB-DU part setup. In this phase, the IAB-DU of IAB-node 2 is configured via OAM. The IAB-DU of IAB-node 2 initiates the TNL establishment, and F1 setup (as defined in clause 8.5) with the IAB-donor-CU using the allocated IP address(es). The IAB-donor-CU discovers collocation of IAB-MT and IAB-DU from the IAB-node's BAP Address included in the F1 SETUP REQUEST message. After the F1 is set up, the IAB-node 2 can start serving the UEs.
Up

8.12.2  NSA IAB Integration procedureWord‑p. 66
The IAB integration procedure for NSA is shown in Figure 8.12.2-1.
[not reproduced yet]
Figure 8.12.2-1: Signalling flow for IAB integration procedure in NSA
Up
Phase 1-1)
IAB-MT part setup with E-UTRAN. In this phase, the IAB-MT part connects to the LTE network as a UE, by performing RRC connection setup procedure with an eNB, authentication with the EPC, IAB-node's access traffic-related radio bearer configuration at the E-UTRAN side, and optionally, OAM connectivity establishment by using the IAB-MT's PDN connection. The IAB-node can select the IAB-supporting eNB based on an over-the-air indication from eNB (transmitted in SIB1). To indicate its IAB capability, the IAB-MT includes the IAB-node indication in RRCConnectionSetupComplete message, to assist the eNB to select an MME supporting IAB. The eNB then configures the IAB-MT part with an NR measurement configuration in order to perform discovery, measurement and measurement reporting of candidate gNBs. To enable the eNB choose an en-gNB which supports IAB function, the IAB capability of neighbour gNBs can be pre-configured in the eNB (e.g. by OAM).
Phase 1-2)
SgNB addition. In this phase, the IAB-MT part connects to the parent node IAB-DU and IAB-donor-CU via the EN-DC SgNB Addition procedure. The procedure defined in section 8.4.1 is reused. The eNB includes "IAB Node Indication" in SGNB ADDITION REQUEST message to inform the IAB-donor-CU that the request is for an IAB-node. In addition, SRB3 can be set up for the IAB-MT, to transmit RRC message between the IAB-MT and the IAB-donor-CU via the NR links directly.
Phase 2-1)
BH RLC channel establishment. This phase is the same as Phase 2-1 in the standalone IAB integration procedure (refer to the Phase 2-1 in clause 8.12.1). This step may occur in Phase 1-2.
Phase 2-2)
Routing update. This phase is the same as Phase 2-2 in the standalone IAB integration procedure (refer to the Phase 2-2 in clause 8.12.1), except that the IP traffic on the F1-C interface may be transmitted via the MeNB.
Phase 3)
IAB-DU part setup. This phase is the same as Phase 3 in the standalone IAB integration procedure (refer to the Phase 3 in clause 8.12.1), except that the IP traffic on the F1-C interface may be transmitted via the MeNB.
The IAB-donor-CU decides to only configure LTE leg, or only to configure NR leg, or to configure both LTE leg and NR leg, to be used for F1-C traffic transfer. The configuration may be performed before IAB-DU part setup. IAB-donor-CU may also change the configuration after IAB-DU part setup. In case the configuration is not performed before IAB-DU part setup, the IAB node uses the NR leg as the default one. When both LTE leg and NR leg are configured, it is up to the implementation to select the leg for F1-C traffic transfer.
Up

8.13  Overall procedures for MDT |R16|Word‑p. 67
The following clauses describe the overall procedures for MDT measurement involving E1 and F1.

8.13.1  Signalling based MDT activation

The signalling flow for Signalling based MDT activation involving E1 and F1 is shown in Figure 8.13.1-1.
[not reproduced yet]
Figure 8.13.1-1: Signalling based MDT Activation
Up
Step 1.
The AMF starts a trace session and sends a TRACE START message to the gNB. The AMF shall consider the MDT user consent information when activating an MDT trace session for the UE as defined in TS32.422 [20]. TRACE START message includes the parameters for configuring MDT measurements.
Step 2.
The gNB-CU-CP decides if the gNB-CU-UP, or the gNB-DU, or both, should be involved in the MDT measurement. If the gNB-CU-UP should be involved in the MDT measurement, the gNB-CU-CP sends TRACE START message to the gNB-CU-UP, including MDT configuration parameters.
Step 3.
If the gNB-DU should be involved in the MDT measurement, the gNB-CU-CP sends TRACE START message to the gNB-DU, including MDT configuration parameters.
Up

8.13.2  Management based MDT activation

8.13.2.1  General

In Management Based Trace Activation towards a gNB-CU-CP, gNB-CU-UP or a gNB-DU can be fulfilled with the Cell Traffic trace functionality defined in TS32.422 [20]. The configuration parameters of the Trace Session that are received by a node in split RAN architecture are defined in TS32.422 [20].
The following description is valid for both an en-gNB and a gNB.
If the MDT measurement is initiated by the EM towards the gNB-CU-CP, and if the activation involves measurements collected by multiple nodes under the same gNB-CU-CP control in a split RAN architecture, the EM sends MDT measurement activation to the gNB-CU-CP and the gNB-CU-CP may further decide which gNB-DU(s) or which gNB-CU-UP(s) to perform the MDT measurement.
When gNB-CU-CP or a gNB-DU receive the Trace Session Activation message from the management system for a given cell or a list of cell(s) under its control, the gNB-CU-CP or gNB-DU shall start a Trace Session for the given cell or list of cell(s). For Management Based MDT sent directly to a gNB-CU-UP, no MDT Area Configuration (apart from PLMN IDs) is to be included in the MDT activation indication.
Each node receiving an MDT activation indication reports the measurements collected according to such activation directly to the TCE the node has been configured with.
The signalling flow for management based MDT in gNB-CU-CP, gNB-DU and gNB-CU-UP is shown in Figure 8.13.2.2-1, Figure 8.13.2.3-1 and in Figure 8.13.2.4-1 respectively.
Up

8.13.2.2  Management based MDT Activation in gNB-CU-CPWord‑p. 68
The signalling flow for Management based MDT Activation in gNB-CU-CP is shown in Figure 8.13.2.2-1.
[not reproduced yet]
Figure 8.13.2.2-1: Management based MDT Activation in gNB-CU-CP
Up
Step 1.
The EM sends a Trace Session activation request to the gNB-CU-CP. This request includes the parameters for configuring UE measurements.
Step 2.
The gNB-CU-CP shall select the suitable UEs for MDT data collection. If the UE is not in the specified area or if the serving PLMN is not within the Management Based MDT PLMN List the UE shall not be selected by the gNB-CU-CP for MDT data collection as defined in TS32.422 [20].
For each selected UE, if the gNB-CU-UP should perform MDT measurement, the gNB-CU-CP sends TRACE START message to the gNB-CU-UP, including MDT configuration parameters.
Step 3.
For each selected UE, if the gNB-DU should perform MDT measurement, the gNB-CU-CP sends TRACE START message to the gNB-DU, including MDT configuration parameters.
Step 4.
The gNB-CU-CP may send CELL TRAFFIC TRACE message to the AMF for the selected UE, including Trace ID for MDT. The AMF forwards Trace ID and UE identity to the TCE.
Up

8.13.2.3  Management based MDT Activation in gNB-DU

The signalling flow for Management based MDT Activation in gNB-DU is shown in Figure 8.13.2.3-1.
[not reproduced yet]
Figure 8.13.2.3-1: Management based MDT Activation in gNB-DU
Up
Step 1.
The gNB-CU-CP sends UE CONTEXT SETUP REQUEST message to the gNB-DU, including Management based MDT PLMN List.
Step 2.
The gNB-DU sends UE CONTEXT SETUP RESPONSE message to the gNB-CU-CP.
Step 3.
The EM sends a Trace Session activation request to the gNB-DU. This request includes the parameters for configuring UE measurements.
Step 4.
The gNB-DU shall select the suitable UEs for MDT data collection. If the UE is not in the specified area or if the serving PLMN is not within the Management Based MDT PLMN List the UE shall not be selected by the gNB-DU for MDT data collection as defined in TS32.422 [20].
For each selected UE, the gNB-DU may send CELL TRAFFIC TRACE message to the gNB-CU-CP in the F1 UE associated signalling, including Trace ID for MDT.
Step 5.
Upon reception of a CELL TRAFFIC TRACE message from F1, the gNB-CU-CP shall send CELL TRAFFIC TRACE message to the AMF for this UE, including Trace ID for MDT. The AMF forwards Trace ID and UE identity to the TCE.
Up

8.13.2.4  Management based MDT Activation in gNB-CU-UPWord‑p. 69
The signalling flow for Management based MDT Activation in gNB-CU-UP is shown in Figure 8.13.2.4-1.
[not reproduced yet]
Figure 8.13.2.4-1: Management based MDT Activation in gNB-CU-UP
Up
Step 1.
The gNB-CU-CP sends BEARER CONTEXT SETUP REQUEST message to the gNB-CU-UP, including Management based MDT PLMN List.
Step 2.
The gNB-CU-UP sends BEARER CONTEXT SETUP RESPONSE message to the gNB-CU-CP.
Step 3.
The EM sends a Trace Session activation request to the gNB-CU-UP. This request includes the parameters for configuring UE measurements.
Step 4.
The gNB-CU-UP shall select the suitable UEs for MDT data collection. If the serving PLMN is not within the Management Based MDT PLMN List the UE shall not be selected by the gNB-CU-UP for MDT data collection as defined in TS32.422 [20].
For each selected UE, the gNB-CU-UP may send CELL TRAFFIC TRACE message to the gNB-CU-CP in the E1 UE associated signalling, including Trace ID for MDT
Step 5.
Upon reception of a CELL TRAFFIC TRACE message from E1, the gNB-CU-CP shall send CELL TRAFFIC TRACE message to the AMF for this UE, including Trace ID for MDT. The AMF forwards Trace ID and UE identity to the TCE.
Up

8.13.2.5  User consent propagation in EN-DCWord‑p. 70
In the EN-DC case, the EM provides the MDT configuration to both MeNB and en-gNB independently.
As specified in TS32.422 [20] in Management based MDT getting user consent is required before activating the MDT functionality because of privacy and legal obligations. In the case of EN-DC user consent gets communicated to the MeNB at the UE context setup procedure using the INITIAL CONTEXT SETUP REQUEST message. In particular when the Management Based MDT Allowed IE is contained in the INITIAL CONTEXT SETUP REQUEST message, the MeNB stores it in the UE context and uses it, together with information in the Management Based MDT PLMN List IE, if available, to allow subsequent selection of the UE for management based MDT as specified in TS 32.422. The MeNB will forward the MDT user consent to the SgNB at EN-DC setup. In particular, if available in the UE context, the MeNB will include the Management Based MDT Allowed IE and the Management Based MDT PLMN List IE in the SGNB ADDITION REQUEST message to the SgNB. Furthermore, the user consent will be forwarded to the relevant gNB-CU-UP at the bearer context setup or to the gNB-DU by including the Management Based MDT PLMN List IE in the BEARER CONTEXT SETUP REQUEST or UE CONTEXT SETUP REQUEST.
The signalling flow for User consent proposation in EN-DC is shown in Figure 8.13.2.5-1.
[not reproduced yet]
Figure 8.13.2.5-1: User consent propagation in EN-DC
Up
Step 0.
User Context information are made available at the MME.
Step 1.
The MME sends INITIAL CONTEXT SETUP REQUEST message to the MeNB, including Management Based MDT Allowed IE and the Management based MDT PLMN List IE to communicate user consent to the eNB.
Step 2.
The MeNB sends SGNB ADDITION REQUEST to the gNB-CU-CP at EN-DC setup. This request includes Management Based MDT Allowed IE and, optionally, the Management based MDT PLMN List IE, if available.
Step 3a.
The user consent is communicated to the gNB-DU at the UE context setup by including the Management based MDT PLMN List IE in the UE CONTEXT SETUP REQUEST.
Step 3b.
The user consent is communicated to the gNB-CU-UP at the bearer context setup by including the Management based MDT PLMN List IE in the BEARER CONTEXT SETUP REQUEST.
Up

8.14  Self-optimisation |R16|Word‑p. 71

8.14.1  Overall procedures for MRO

The following clauses describe the overall procedures for MRO involving F1.

8.14.1.1  Signalling of RLF information from gNB-CU to gNB-DU

The signalling flow for signalling of RLF information from gNB-CU to gNB-DU is shown in Figure 8.14.1.1-1, where the example where NG-RAN nodes exchange the RLF Report via the Xn: FAILURE INDICATION message has been considered.
[not reproduced yet]
Figure 8.14.1.1-1: Example of signalling of RLF information from gNB-CU to gNB-DU in NG RAN
Up
Step 1.
A UE with a logged RLF Report connects to a cell in gNB2 and it signals the RLF Report to gNB2 by means of the RRC UE Information Request/Response procedures.
Step 2.
The gNB2 sends an Xn: Failure Indication to gNB1-CU where the UE may have previously been connected prior to the connection failure. This includes also the RLF Report.
Step 3.
The gNB1-CU sends the F1: Access and Mobility Indication message to the gNB1-DU, including the RLF Report.
It is also possible for the gNB-CU receiving the RLF Report from the UE to signal it directly to the gNB-DU by means of the F1: Access and Mobility Indication procedure.
Up


Up   Top   ToC