Summary based on the input provided by CMCC in RP-220822.
This work item introduces enhancement of SON and MDT features support in NR standalone and MR-DC, including
CCO, inter-system inter-RAT energy saving, inter-system load balancing, 2-step RACH optimization, mobility enhancement optimization, PCI selection, energy efficiency (OAM requirements), Successful Handovers Reports, UE history information in EN-DC, load balancing enhancement, MRO for SN change failure, RACH Optimisation enhancements, MDT enhancement and L2 measurements.
The key functionalities of this WI are described as below.
NR Coverage and Capacity Optimization (CCO)
NR Coverage and Capacity Optimization (CCO) function is to detect and mitigate coverage and cell edge interference issues. Each NG-RAN node 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. An NG-RAN node may autonomously adjust within and switch between coverage configurations. When a change is executed, a NG-RAN node may notify its neighbour NG-RAN nodes using the NG-RAN NODE CONFIGURATION UPDATE message with the list of cells and SSBs with modified coverage included. The list contains the CGI of each modified cell with its coverage state indicator and optionally the SSB index of each modified SSB with its coverage state indicator.
Inter-system inter-RAT energy saving
The solution builds upon the possibility for the NG-RAN node owning a capacity booster cell to autonomously decide to switch-off such cell to dormant state. The decision is typically based on cell load information, consistently with configured information. The switch-off decision may also be taken by O&M. The NG-RAN node indicates the switch-off action to the eNB over NG interface and S1 interface. The NG-RAN node could also indicates the switch-on action to the eNB over NG interface and S1 interface.
The eNB providing basic coverage may request a NG-RAN node's cell re-activation based on its own cell load information or neighbour cell load information, the switch-on decision may also be taken by O&M. The eNB requests a NG-RAN node's cell re-activation and receives the NG-RAN node's cell re-activation reply from the NG-RAN node over the S1 interface and NG interface. Upon reception of the re-activation request, the NG-RAN node's cell should remain switched on at least until expiration of the minimum activation time. The minimum activation time may be configured by O&M or be left to the NG-RAN node's implementation.
Inter-system load balancing
The load reporting function for inter-system load balancing is executed by exchanging load information between NG-RAN and E-UTRAN. Both event-triggered and periodic inter-system load reporting are supported. Event-triggered inter-system load reports are sent when the reporting node detects crossing of cell load thresholds.
The following load related information should be supported:
Cell Capacity Class value (UL/DL relative capacity indicator);
Capacity value (per cell: UL/DL available capacity);
RRC connections (number of RRC connections, and available RRC Connection Capacity);
Number of active UEs.
PRB usage (per cell: UL/DL)
NGAP procedures used for inter-system load balancing are Uplink RAN Configuration Transfer and Downlink RAN Configuration Transfer.
S1AP procedures used for inter-system load balancing are eNB Configuration Transfer and MME Configuration Transfer.
2-step RACH optimization
2-step RACH optimization is supported by UE reported 2-step RACH related information made available at the NG RAN node and by PRACH parameters exchange between NG RAN nodes.
For aggregated architecture and centralized PCI assignment in gNB, the OAM assigns a single PCI for each NR cell in the gNB, and the gNB selects this value as the PCI of the NR cell.
For Aggregated architecture and distributed PCI assignment in gNB, the OAM assigns a list of PCIs for each NR cell in the gNB, and the gNB selects a PCI value from the list of PCIs. The gNB may restrict this list by removing some PCIs that are reported by UEs, reported over the Xn interface by neighboring gNBs, and/or acquired through other methods, e.g. detected over the air using a downlink receiver.
The PCI Optimization Function in split gNB case, 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 confilict 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.
Energy efficiency (OAM requirements)
To calculate the energy efficiency of base stations, ETSI ES 203 228 ("Environmental Engineering (EE); Assessment of mobile network energy efficiency"
) defines the following high-level EE KPI:
In which Mobile Network data Energy Efficiency (EEMN,DV) is the ratio between the performance indicator (i.e. Data Volume DVMN) and the energy consumption (ECMN).
Successful Handovers Reports
Successful Handovers Reports is reported by the UE to detect failure events happened during successful handovers.
The solution for the problem may consist of the following steps:
UE is configured with triggering conditions to compile the Successful Handover Report;
Only if the conditions are met, UE generates Successful Handover Report comprising a set of measurements collected during the successful handover phase, i.e. measurement at the handover trigger, measurement at the end of handover execution or measurement after handover execution.
The availability of a Successful Handover Report may be indicated by Completed message (RRCReconfigurationComplete, RRCReestablishmentComplete, RRCSetupComplete, RRCResumeComplete) transmitted from UE to NG-RAN node over RRC. The NG-RAN node may fetch information of a successful handover report via UE Information Request/Response mechanism.
NG-RAN node could forward the Successful Handover Report to the source NR-RAN node to indicate failures experienced during a successful handover event.
Upon reception of a Successful HO Report, the receiving node is able to analyse whether its mobility configuration needs adjustment.
UE history information in EN-DC
UE history information is introduced in EN-DC to avoid Ping Pong effect. The MN stores and correlates the UE History Information from MN and SN(s) as long as the UE stays in MR-DC, forwards UE History Information and optional UE History Information from the UE to its connected SNs. The resulting information is then used by SN in subsequent handover preparation. The SN is in charge of collecting SCG UE history information and providing the collected information to the MN based on MN request or MN subscription on the PSCell change.
The MN may retrieve the SCG UE history information via the SN Addition and SN Modification procedures. SN shall provide the SCG UE history information, if available, in the SN Addition, SN Modification, SN Release, and SN initiated SN Change procedures.
Load balancing enhancement
The load reporting function is executed by exchanging load information over the Xn/X2/F1/E1 interfaces. Besides the load metrics introduced in Rel-16, some more metrics are introduced for intra-system load balancing, including, PRB usage for slice(s): DL/UL GBR PRB usage, DL/UL non-GBR PRB usage, and DL/UL Total PRB allocation) and PRB utilisation for MIMO
To achieve load reporting function, Resource Status Reporting Initiation & Resource Status Reporting procedures are used.
MRO for SN change failure
For analysis of PSCell change failure, the UE makes the SCG Failure Information available to the MN.
MN performs initial analysis to identify the node that caused the failure. If the failure is caused by a SN, the MN forwards the SCG Failure Information to the SN. The SN performs the final root cause analysis. The details of the solution, including the description in this paragraph are FFS.
One of the functions of self-optimization for PSCell change is to detect PSCell change failures that occur due to Too late PSCell change or Too early PSCell change, or Triggering PSCell change to wrong PSCell. These problems are defined as follows:
Too late PSCell change: an SCG failure occurs after the UE has stayed for a long period of time in the PSCell; a suitable different PSCell is found based on the measurements reported from the UE.
Too early PSCell change: an SCG failure occurs shortly after a successful PSCell change from a source PSCell to a target PSCell or a PSCell change failure occurs during the PSCell change procedure; source PSCell is still the suitable PSCell based on the measurements reported from the UE.
Triggering PSCell change to wrong PSCell: an SCG failure occurs shortly after a successful PSCell change from a source PSCell to a target PSCell or a PSCell change failure occurs during the PSCell change procedure; a suitable PSCell different with source PSCell or target PSCell is found based on the measurements reported from the UE.
Support for NR MDT IDC mechanism
Extension to LoggedMeasurementConfiguration with a flag to indicate if an early measurement/idle mode configuration has relevance for logged measurement purposes
UE support to assist the network in preventing management based logged MDT overwriting signalling based logged MDT
Extension to LoggedMeasurementConfiguration with Logged MDT type indication used for signalling MDT protection
RACH failure report extension with 2-step RACH relevant information
Support for multiple CEF reports
Support of M5~M7 for EN-DC SN terminated MCG bearer/split bearers and MN terminated SCG/split bearers
Immediate MDT configuration support for MN terminated SCG bearer and SN terminated MCG/split bearer by the terminated node, e.g., MN in case of MN terminated SCG bearer
RLF report support for CHO and DAPS HO
Support for logging of on-demand SI
PRB usage for MIMO was first introduced to NR in Rel-16 to reflect the PRB usage at the case of MU-MIMO and multiple MIMO layers. Configuring the same constant value Alpha for all the cells sometimes is not suitable, especially for cells in bad radio condition. And it is also difficult to manually configure Alpha for each cell, considering the large number of NR base stations. In Rel-17, PRB Usage based on statistical MIMO layer and Enhanced PRB Usage for MIMO are specified. Comparing with R16 PRB usage measurement, the new PRB usage measurement can adjust Alpha autonomously, e.g., based on statistical data of MIMO layer. The objectives of the measurements are to measure usage of time and frequency resources. A use-case is OAM performance observability.
In addition, PDCP excess packet delay is also specified for delay sensitive services, e.g., URLLC. The objective of this measurement performed by UE is to measure Excess Packet Delay in Layer PDCP for QoS verification of MDT.
RP-22xxxx: Status report for WI on enhancement of SON_MDT support for NR and MR-DC, CMCC
Summary based on the input provided by China Mobile in SP-220580.
This WI specifies the concepts for autonomous networks, autonomous network level (ANL), and use cases, requirements and solutions for the levels of autonomous functions in a 3GPP network. Examples of enablers for autonomous network are: Self-Organization Network (SON), management data analytics (MDA), intent driven management (IDM), closed loop SLS assurance (COSLA).
Autonomous network is a telecommunication system (including management system and network) with autonomy capabilities which is able to be governed by itself, with minimal to no human intervention. ANL is used to describe the level of autonomy capabilities in the autonomous network. A framework approach for evaluating ANL is as follows:
Summary based on the input provided by vivo/China Mobile in SP-220629.
In addition to NWDAF related work initiated in Rel-15 and Rel-16, this WI (eNA_Ph2) further specify framework enhancements and define extensions to existing Nnwdaf service for supporting network automation.
The Network Data Analytics Function (NWDAF) is to support network automation as listed in TS 23.288
and includes one or more of the following functionalities:
Support data collection from NFs, AFs and OAM as shown;
NWDAF service registration and metadata exposure to NFs and AFs;
Support analytics information provisioning to NFs and AFs as shown;
Support Machine Learning (ML) model training and provisioning to NWDAFs (containing Analytics logical function).
In addition to the framework specified in Rel-15 and Rel-16, further specify framework enhancements to support network data analytics service:
Logical function decomposition of NWDAF (Model Training logical function, Analytics logical function) and the interactions between these logical functions as shown in Figure 9.4.3-1;
Increasing efficiency of data collection;
Trained data model sharing between multiple NWDAF instances, limited to single vendor environments;
multiple NWDAF instances;
UE data as an input for analytics generation (via AF);
User consent for UE data collection/analysis;
Triggering conditions for the Data Analytics;
Enhancement for real-time communication.