Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 38.401  Word version:  18.3.0

Top   Top   Up   Prev   Next
1…   5…   6…   6.1.4   6.1.5…   6.2…   7…   8…   8.2…   8.2.1.4…   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.15.2…   8.16…   8.17…   8.17.3…   8.17.4   8.18…   8.19…   8.19.2   8.19.3   8.19.4…   8.21…   8.22…   8.23…   8.24…   9…   A… 
7 NG-RAN functions description  7.0 General  7.1 NG-RAN sharing  7.2 Remote Interference Management  7.3 Cross-Link Interference Management  7.4 Support for Non-Public Networks  7.5 RACH Optimisation Function  7.6 Positioning  7.7 Support for NR MBS  7.7.1 Support of dynamic PTP and PTM switching  7.7.2 Support of resource efficiency for RAN Sharing  7.7.2.1 General  7.7.2.2 Support of resource efficiency for MOCN  7.7.2.3 Support of resource efficiency for RAN Sharing with multiple cell-ID broadcast  7.7.3 Support of Multicast reception for UEs in RRC_INACTIVE  7.7.4 Recovery of shared F1-U Failure  7.8 PCI Optimisation Function  7.9 Support for CCO  7.9.1 General  7.9.2 OAM requirements  7.9.3 Dynamic coverage configuration changes  7.10 Support of RAN visible QoE measurement  7.11 Support of AI/ML for NG-RAN 
...

 

7  NG-RAN functions description  p. 26

7.0  General  p. 26

For the list of functions refer to TS 38.300.

7.1  NG-RAN sharing  p. 27

NG-RAN supports radio access network sharing as specified in TS 23.501 and TS 38.300 and TS 36.300.

7.2  Remote Interference Management |R16|  p. 27

The Remote Interference Management function in non-split gNB case is specified in TS 38.300.
In case of split gNB architecture, in the victim set, a gNB-DU detects the remote interference. If remote interference is detected, the gNB-DU can send out the RIM-RS. In the aggressor set, if a gNB-DU detects the RIM-RS sent by the victim gNB(s), it sends to the gNB-CU the RIM-RS detection status and the victim Set ID. The gNB-CU acts as a coordinator on behalf of its affiliated gNB-DUs, where the gNB-CU merges the outgoing RIM information received from its gNB-DUs in the aggressor set and forwards the merged information to all the gNBs in the victim set.
Similarly, in the victim set, the gNB-CU distributes the incoming RIM information to all the gNB-DUs in the set, as indicated in the RIM information received from the aggressor set.
In addition, to facilitate consolidation of RIM information, the gNB-DU provides the associated aggressor set ID and the victim set ID of each serving cell to the gNB-CU.
Up

7.3  Cross-Link Interference Management |R16|  p. 27

The Cross-Link Interference Management function in non-split gNB case is specified in TS 38.300.
In case of split gNB architecture, the gNB-CU forwards the TDD DL/UL patterns received from neighboring nodes to each concerned gNB-DU. The gNB-DU reports the TDD DL/UL patterns of its serving cells to the gNB-CU if Cross-Link Interference is detected.

7.4  Support for Non-Public Networks |R16|  p. 27

NG-RAN supports NPN as specified in TS 23.501 and TS 38.300.

7.5  RACH Optimisation Function |R16|  p. 27

The RACH Optimization Function in non-split gNB case is specified in TS 38.300.
In case of split gNB architecture, RACH configuration conflict detection and resolution function is located at the gNB-DU. To perform RACH optimisation at gNB-DU, gNB-CU sends the RA Report retrieved from the UE(s) to gNB-DU via F1AP signalling. The gNB-DU signals the PRACH configuration per-cell to gNB-CU. The gNB-CU may forward a limited set of neighbour cell's PRACH configurations received from neighbour gNBs and other gNB-DUs to the gNB-DU to resolve the configuration conflict.
RA Report retrieval
When a UE performs successful random access attempts which are only known by the gNB-DU (e.g., beam failure recovery, UL synchronization issue, scheduling request failure, no PUCCH resource available), the gNB-DU may inform the gNB-CU about the occurrences of successful random access procedures in the gNB-DU via a RACH indication. The gNB-CU may then retrieve the RA Report from the UE(s) based on the RACH indication received via F1AP signalling from the gNB-DU.
Up

7.6  Positioning |R16|  p. 27

The NG-RAN supports the positioning functionality as specified in TS 38.305.

7.7  Support for NR MBS |R17|  p. 27

The Support of NR MBS in non-split gNB case is specified in TS 38.300.

7.7.1  Support of dynamic PTP and PTM switching  p. 28

For UEs in RRC_CONNECTED, NG-RAN supports dynamic switch between PTP and PTM for a multicast MBS session as specified in TS 38.300.
In case of split gNB architecture, for a MRB with common PDCP involving both PTP (RLC leg) and PTM (RLC leg), upon receiving the MBS data from the gNB-CU via a shared F1-U tunnel, the gNB-DU makes decision of using PTP (RLC leg) or PTM (RLC leg) or both.
For UEs in RRC_INACTIVE only PTM is supported for a multicast MBS session as specified in TS 38.300.
Up

7.7.2  Support of resource efficiency for RAN Sharing |R18|  p. 28

7.7.2.1  General  p. 28

Resource efficiency for RAN sharing is supported in both MOCN scenario and Multiple Cell-ID Broadcast scenario.
In case of split gNB,
  • for each broadcast MBS session, the gNB-CU triggers the establishment of a Broadcast MBS Session Context over the F1 interface regardless of whether F1-U or NG-U resources associated with the broadcast MBS session are established.

7.7.2.2  Support of resource efficiency for MOCN  p. 28

The Associated Session ID is used to enable identifying broadcast MBS sessions for which RAN resources could be shared by the involved gNB-DUs and the gNB-CU-UP and is provided by the gNB-CU-CP. For location dependent MBS services, the MBS Service Area provided by the gNB-CU-CP is also taken into account. Only one set of shared F1-U resources is established and kept as long as there is one PLMN keeping the MBS Broadcast service.

7.7.2.3  Support of resource efficiency for RAN Sharing with multiple cell-ID broadcast  p. 28

gNB-DUs sharing the same physical cell resources receive via F1-C information to enable identifying broadcast MBS sessions providing identical content. The identification is based on Associated Session ID and, for location dependent MBS services, the MBS Service Area is also taken into account.
While applying resource efficiency for RAN Sharing with multiple cell-ID broadcast
  • the entity controlling the involved gNB-DUs sharing the same physical cell resources resolve different QoS requirements and slicing information received from the involved gNB-CUs in an implementation specific way.
  • F1-U resources are established towards either all involved gNB-CUs or only some of them which is decided by the entity controlling the involved gNB-DUs sharing the same physical cell resources. The gNB-DU is able to trigger the gNB-CU to establish F1-U resources.
  • the gNB-CU-CP takes into account the decision to establish F1-U resources to decide whether to establish NG-U resources.
If a broadcast MBS session is released by a 5GC but kept by other 5GC(s), for an MBS Session Context not associated with any user plane resource,
  • F1AP supports triggering the setup of F1-U resources by the gNB-DU by means of the Broadcast Transport Resource Request procedure.
  • NGAP supports triggering the setup NG-U resources by the gNB by means of the Broadcast Session Transport procedure for unicast transport.
Up

7.7.3  Support of Multicast reception for UEs in RRC_INACTIVE |R18|  p. 28

F1AP supports:
  • enabling and disabling multicast reception for UEs in RRC_INACTIVE state for a specific multicast MBS session on cell level.
  • retrieval of PTM configuration information from the the gNB-DU by means of the gNB-CU triggered Multicast Context Modification procedure.
  • keeping the gNB-CU updated during active multicast MBS sessions with the latest PTM configuration by means of the gNB-DU initiated Multicast Context Notification procedure.
The gNB-CU decides whether multicast reception in RRC_INACTIVE state is applied.
Up

7.7.4  Recovery of shared F1-U Failure |R18|  p. 29

Recovery of shared F1-U failure is supported for broadcast MBS sessions with the gNB-DU detecting the F1-U failure and triggering recovery handling. If the gNB-DU detects failure of a shared F1-U bearer of a broadcast MBS session it may send the F1AP Broadcast Transport Resource Request message to the gNB-CU CP indicating the F1-U failure and optionally including a new DL F1-U transport address. The gNB-CU CP should understand that any shared F1-U resources previously established for the broadcast MBS session have been implicitly released by the gNB-DU.
The gNB-CU CP should then:
  • trigger towards gNB-CU UP the release of the current gNB-CU UP UL transport resources of the shared F1-U bearer and establishment of new ones and the provision of the new DL F1-U transport addresses if received;
  • trigger the F1AP Broadcast Context Modification procedure to deliver the corresponding new gNB-CU UP address to the gNB-DU to establish the new F1-U resources.
Up

7.8  PCI Optimisation Function |R17|  p. 29

The PCI Optimization Function in non-split gNB case is specified in TS 38.300.
In split gNB architecture, the OAM configures a PCI for each NR cell to the gNB-DU.
For centralized PCI assignment in split gNB architecture, the gNB-CU detects PCI conflict of NR cells and reports the NR cells suffering PCI conflict to OAM directly. The OAM is in charge of reassigning a new PCI for the NR cell subject to PCI conflict.
For distributed PCI assignment in split gNB architecture, the OAM assigns a list of PCIs for each NR cell and sends the configured PCI list to the gNB-CU. If the gNB-CU detects PCI conflict, the gNB-CU may select a new PCI value from the preconfigured PCI list for the NR cell and send it to the gNB-DU by either F1 Setup procedure or gNB-CU configuration update procedure.
For mobile IAB deployments, the legacy mechanisms can be reused for PCI collision detection. The PCI space can be partitioned between mobile IAB cells and stationary cells by implementation.
Up

7.9  Support for CCO |R17|  p. 29

7.9.1  General  p. 29

The NR Capacity and Coverage Optimization (CCO) Function in non-split gNB case is specified in TS 38.300. The objective of this function is to detect and mitigate coverage and cell edge interference issues.

7.9.2  OAM requirements  p. 29

Each gNB-DU may be configured with alternative coverage configurations by OAM. The alternative coverage configurations contain relevant radio parameters and may also include a range for how each parameter is allowed to be adjusted.

7.9.3  Dynamic coverage configuration changes  p. 30

In case of split gNB architecture, CCO detection function is located at the gNB-CU. The gNB-CU signals to the gNB-DU the CCO issue and the affected cells and beams. The gNB-DU resolves the CCO issue concerning own served cell by local action within the OAM configured limits. The gNB-DU may also take into account information received for other cells when adopting the CCO configuration. The gNB-DU informs the gNB-CU of the new coverage states adopted.

7.10  Support of RAN visible QoE measurement |R17|  p. 30

The RAN visible QoE measurement function is specified in TS 38.300.
In split gNB architecture, upon the reception of the RAN visible QoE measurement report from the UE, the gNB-CU may forward the corresponding QoE information to the gNB-DU. The QoE information transferred to the gNB-DU may include the RAN visible QoE measurement results received from the UE, along with the corresponding DRB ID(s).
The gNB-DU may deactivate the transfer of RAN visible QoE measurement results from the gNB-CU, by initiating QoE Information Transfer Control procedure towards the gNB-CU.
Up

7.11  Support of AI/ML for NG-RAN |R18|  p. 30

The support of AI/ML for NG-RAN is specified in TS 38.300.
In case of CU-DU split architecture, the following scenarios may be supported:
  • AI/ML Model Training is located in the OAM and AI/ML Model Inference is located in the gNB-CU.
  • AI/ML Model Training and Model Inference are both located in the gNB-CU.

Up   Top   ToC