WO2025201690A1

WO2025201690A1 - Activation of capacity and coverage optimization issue detection in split ng-ran architecture

Info

Publication number: WO2025201690A1
Application number: PCT/EP2025/051317
Authority: WO
Inventors: Hakon Helmers; Anna Pantelidou
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2024-03-28
Filing date: 2025-01-20
Publication date: 2025-10-02
Anticipated expiration: 2026-09-28

Abstract

Various example embodiments relate to devices, methods, apparatuses and computer readable mediums for capacity and coverage optimization, CCO, issue detection in a split next generation radio access network architecture A distributed unit may be configured to send to a centralized unit a request for CCO issue detection, the request indicating one or more cells or beams for which the CCO issue detection is requested, to receive from the centralized unit a CCO issue report indicating a CCO issue associated with at least one of the one or more cells or beams, and to perform a coverage configuration change for the at least one of the one or more cells or beams in response to the received CCO issue report.

Description

ACTIVATION OF CAPACITY AND COVERAGE OPTIMIZATION ISSUE DETECTION IN

SPLIT NG-RAN ARCHITECTURE

TECHNICAL FIELD

[0001] Various example embodiments described herein generally relate to communication technologies, and more particularly, to devices, methods, apparatuses and computer readable mediums for capacity and coverage optimization (CCO) issue detection in a split next generation radio access network (NG-RAN) architecture.

BACKGROUND

[0002] Certain abbreviations that may be found in the description and/or in the figures are herewith defined as follows:

AI/ML Artificial Intelligence/Machine Learning

CP Control Plane

CU Centralized Unit

DU Distributed Unit

El Interface between CU-CP and CU-UP

Fl Interface between CU and DU

Fl-C Fl Control plane

Fl-U Fl User plane gNB next generation Node-B

NG-RAN Next Generation Radio Access Network

0AM Operations Administration and Management

RRC Radio Resource Control

SSB Synchronization Signal and PBCH Block

UE User Equipment

UP User Plane

Xn Interface between NG-RAN Nodes

[0003] Capacity and coverage optimization (CCO) has been identified as one of key use cases for self-organizing network (SON) since Long Term Evolution (LTE). The objective of CCO is to detect and resolve or mitigate CCO issues, e.g. coverage and cell edge interference issues, based on data collection including measurements and events reported from various network elements and user equipment (UEs). As data collection capabilities of cellular networks increase, a large amount of data may be collected for the CCO issue detection, and more complex algorithms are designed to process the large amount of data. Artificial intelligence/machine learning (AI/ML), as a tool for solving complex problems by efficiently processing and categorizing large amounts of data, has been introduced into CCO issue detection solutions.

SUMMARY

[0004] A brief summary of example embodiments is provided below to provide basic understanding of some aspects of various embodiments. It should be noted that this summary is not intended to identify key features of essential elements or define scopes of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a preamble for a more detailed description provided below.

[0005] In a first aspect, example embodiments of a distributed unit are provided. The distributed unit may comprise at least one processor and at least one memory storing instructions. The instructions may, when executed by the at least one processor, cause the distributed unit at least to send a request for capacity and coverage optimization issue detection to a centralized unit, the request indicating one or more cells or beams for which the capacity and coverage optimization issue detection is requested, to receive from the centralized unit a capacity and coverage optimization issue report indicating a capacity and coverage optimization issue associated with at least one of the one or more cells or beams, and to perform a coverage configuration change for the at least one of the one or more cells or beams in response to the received capacity and coverage optimization issue report.

[0006] In a second aspect, example embodiments of a centralized unit are provided. The centralized unit may comprise at least one processor and at least one memory storing instructions. The instructions may, when executed by the at least one processor, cause the centralized unit at least to receive a request for capacity and coverage optimization issue detection from a distributed unit, the request indicating one or more cells or beams for which the capacity and coverage optimization issue detection is requested, to detect a capacity and coverage optimization issue associated with the distributed unit based on measurements received from the distributed unit, one or more neighboring nodes, and user equipment served by the distributed unit and the one or more neighboring nodes, and to send a capacity and coverage optimization issue report indicating the capacity and coverage optimization issue to the distributed unit in case the capacity and coverage optimization issue is associated with at least one of the one or more cells or beams.

[0007] Example embodiments of methods, apparatus and computer readable mediums are also provided. Such example embodiments generally correspond to the above example embodiments of the distributed unit and the centralized unit, and a repetitive description thereof is omitted here for convenience.

[0008] Other features and advantages of the example embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of example embodiments of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Some example embodiments will now be described, by way of non-limiting examples, with reference to the accompanying drawings.

[0010] Fig l is a schematic block diagram illustrating a split architecture for a next generation radio access network (NG-RAN).

[0011] Fig 2 is a schematic message flow diagram illustrating an example process.

[0012] Fig 3 is a schematic message flow diagram illustrating an example process.

[0013] Fig 4 is a schematic diagram illustrating an example framework of an artificial intelligence/machine learning (AI/ML) model used for coverage and capacity optimization (CCO) issue detection.

[0014] Figs 5 A and 5B are schematic diagrams illustrating an example cell shaping action.

[0015] Fig 6 is a schematic block diagram illustrating an example method implemented at a distributed unit (DU).

[0016] Fig 7 is a schematic block diagram illustrating an example method implemented at a centralized unit (CU).

[0017] Fig 8 is a schematic block diagram illustrating an example apparatus.

[0018] Fig 9 is a schematic block diagram illustrating an example apparatus.

[0019] Fig 10 is a schematic block diagram illustrating example devices in a communication system.

[0020] Throughout the drawings, same or similar reference numerals indicate same or similar elements. A repetitive description on the same elements would be omitted.

DETAILED DESCRIPTION

[0021] Herein below, some example embodiments are described in detail with reference to the accompanying drawings. The following description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known circuits, techniques and components are shown in block diagram form to avoid obscuring the described concepts and features.

[0022] Fig 1 illustrates a split next generation radio access network (NG-RAN) architecture in which example embodiments of the present disclosure can be implemented. As shown in Fig. 1, in the split NG-RAN architecture, a base station 110, e.g., a next generation Node-B (gNB), is split into a central unit (CU) 112, which includes a CU control plane (CU-CP) 113 and one or more CU user planes (CU-UPs) 115, and one or more distributed units (DUs) 116 (shown as a first DU 116a and a second DU 116b). In a split option, the CU-CP 113 may host a radio resource control (RRC) protocol and a control plane part of a packet data convergence protocol (PDCP), the CU-UPs 115 each may host a user plane part of the PDCP protocol and a service data adaptation protocol (SDAP), and the DUs 116 each may host radio link control (RLC), medium access control (MAC) and physical (PHY) layers. It would be appreciated that different split options may also be used in the NG-RAN. The CU-CP 113 may connect to each CU-UP 115 via an El interface and to each DU 116 via an Fl-C interface. The DUs 116 each may connect to the CU-UPs 115 via an Fl-U interface. One DU 116 can connect to only one CU-CP 113 and to multiple CU-UPs 115 under control of the same CU-CP 113, one CU-UP 115 can connect to only one CU-CP 113 and to multiple DUs 116 under control of the same CU-CP 113.

[0023] The respective units of the split gNB 110 may be deployed at different locations based on use cases and performance requirements. For instance, the CU-CP 113 may be positioned near the DUs 116 to achieve low latency for CP procedure such as RRC connection establishment and handover. The CU-UPs 115 may be centralized for example in the operator’s data center, which is advantageous for cloud implementations and can provide a centralized termination point for UP traffic in dual connectivity and tight interworking scenarios. In an example, an additional CU-UP 115 may be deployed near the DU 116 to provide low latency for ultra-reliable low- latency communication (URLLC) applications.

[0024] Capacity and coverage optimization (CCO) is a mechanism introduced since LTE to provide required capacity in target coverage areas (i.e., cells) and to minimize interference and connection failures e.g. linked to coverage holes, and maintain an acceptable quality of service in an autonomous way. Currently the CCO may be implemented in a distributed manner or in a centralized manner. The distributed CCO feature may reside in the CU-CP 113 of the gNB 110. The CU-CP 113 may determine CCO issues based on various observations including UE radio measurements, radio link failure (RLF), radio connection establishment failure and observed performance e.g. throughput, packet loss of its served UEs. When a CCO issue is detected, the gNB 110 may perform dynamic cell-level and/or beam-level coverage configuration changes by autonomously switching between pre-configured coverage states, and inform neighboring nodes about the coverage configuration change and the corresponding CCO cause e.g. “coverage” or “cell edge capacity”. A neighboring node that receives the coverage configuration change information from the gNB 110 may adjust its own coverage configuration accordingly, taking into account the CCO cause. The CCO functionality may benefit from the high degree of radio coverage configurability provided by active antenna systems.

[0025] The centralized CCO feature may reside in operations administration and management (0AM). The 0AM may collect measurements from a plurality of NG-RAN nodes and detect CCO issues based on the collected measurements. The centralized CCO feature residing in the 0AM may work on a relatively slow time scale to detect and mitigate coverage and cell edge capacity issues. Compared to the centralized CCO, the distributed CCO residing in the gNB 110 may work on a faster time scale and therefore may enable more dynamic cell and beam adaptations to optimize capacity in scenarios with geographical changes in the UE traffic patterns. However, this improved optimization potential of the distributed CCO comes at the cost of a need to solve optimization problems with possibly a large number of input and output combinations. AI/ML is a tool that enables solving complex problems by efficiently processing and categorizing large amounts of data. In that sense, introduction of AI/ML techniques into the dynamic CCO solution would be useful in order to fully leverage the potential of the distributed CCO.

[0026] In the split NG-RAN architecture, as discussed above, the CCO issue detection function is located in the gNB-CU-CP 113 while the corrective action is performed by the gNB-DUs 116. To accurately detect the CCO issues, the gNB-CU-CP 113 needs to continuously collect, correlate and analyze large amounts of information from different sources such as UEs, gNB- DUs, gNB-CU-UPs and neighboring gNBs, which consumes a great deal of resources including e.g. signaling, processing, memory and energy. In addition, the corrective action performed at the gNB-DU may come with constraints in terms of delay of the coverage reconfiguration and energy costs, which may undesirably impact performance of gNB-DU. However, the gNB-DU doesn’t receive information from the gNB-CU-CP that can help to reduce the impacts.

[0027] Example embodiments of the present disclosure provide a mechanism allowing the gNB-CU-CP to limit CCO issue detection to cells and/or beams when and where such detection is required and also to take into account information from the gNB-DU relative to e.g. available coverage configurations and supported corrective actions. When CCO issue detection is desired, the gNB-DU may send a request for CCO issue detection to the gNB-CU-CP which, when received by the gNB-CU-CP, triggers data collection for relevant cells and/or beams in order to detect CCO issues. The request may contain a list of cells and/or beams for which the CCO issue detection is desired. In some example embodiment, the request may also contain information about available coverage configurations and supported corrective actions at the gNB-DU. When the CCO issue detection is not desired or the gNB-DU is not able to perform coverage reconfigurations corresponding to any detected CCO issue any longer, the gNB-DU may request the gNB-CU-CP to cancel the CCO issue detection. Therefore, the CCO issue detection can be performed only when it is needed and if the gNB-DU serving the concerned cells and/or beams can perform coverage reconfiguration required to solve the detected CCO issue. As a consequence, it will reduce the need for AI/ML model training, retraining or inference and at the same time reduce the data collection requirements from served UEs as well as from other network elements. The overall result is to reduce resource consumption for CCO including e.g. signaling, processing, memory, energy. In addition, the gNB-DU will benefit from receiving less information related to the CCO issue detection from the gNB-CU-CP. For instance, the gNB- CU-CP would not send information about the CCO issue detection to the gNB-DU if the gNB- DU does not support an appropriate corrective action for the detected CCO issue.

[0028] In some example embodiments, when the gNB-CU-CP informs the gNB-DU about the detected CCO issue, it may also include predicted information of the CCO issue in the message sent to the gNB-DU. The predicted information may include e.g. prediction of when the CCO issue will occur and how long it will last. The gNB-DU may use this information to determine the new coverage configuration to use to solve the CCO issue, e.g. by taking into account the delay and potential energy cost or gain related to the coverage reconfiguration. Therefore, it will reduce impacts on performance of the gNB-DU caused by constraints of the corrective action.

[0029] Throughout the present disclosure, the term “CCO issue detection” is used to encompass estimation, prediction and more generally application of any algorithm or model that enables the gNB-CU-CP to determine an existing or future CCO issue and possibly its duration including starting and ending time. Throughout the present disclosure, the terms “CCO issue detection” and “CCO issue prediction” may be interchangeably used.

[0030] Fig 2 is a schematic message flow diagram illustrating an example process 200. The process 200 may be implemented at the gNB 110, one or more neighboring gNBs 120 (only one is shown), and UEs 101 served by the gNB 110 and/or the neighboring gNBs 120. It is assumed in the process 200 that the CU-CP 113 of the gNB 110 will detect CCO issues relative to cells and/or beams supported by the first DU 116a of the gNB 110.

[0031] Referring to Fig. 2, at 210, the first DU 116a may optionally determine available coverage configurations pre-configured at the first DU 116a in support of CCO. The available coverage configurations may be configured by 0AM (not shown) and may contain relevant radio parameters and a range for how each parameter is allowed to be adjusted. Each of the available coverage configurations may be associated with a coverage state indicator. In other words, the first DU 116a may determine available coverage states at 210. [0032] At 212, the first DU 116a may send a request for CCO issue detection to the CU-CP 113 to trigger the CCO issue detection procedure. In an example, the first DU 116a may send the request via an Fl setup request message. In another example, the first DU 116a may send the request for CCO issue detection after the Fl setup procedure. For instance, the first DU 116a may use a gNB-DU configuration update message or other legacy F1AP messages to send the request for CCO issue detection. The first DU 116a may monitor cells, beams and/or UEs performance and dynamically trigger the CCO issue detection when the monitored performance falls below a threshold.

[0033] In another example, the first DU 116a may use a new F1AP message to send the request for CCO issue detection. From Fl AP protocol design point of view, use of a signaling framework over Fl similar to the Xn application protocol (XnAP) data collection procedure for this purpose would contribute to a signaling framework for AI/ML-related data collection that provides consistent data and enables reuse of mechanisms for other needed functionality like unsubscription of the CCO issue detection. An example of such framework over Fl is illustrated in Fig. 3.

[0034] Referring to Fig. 3, there is shown an example CCO issue detection request procedure 300. At 310, the first DU 116a may send an Fl AP data collection request message to the CU-CP 113. The data collection request message may include a gNB-DU measurement identifier (ID), measurement configuration related to the measurement ID, and the request for CCO issue detection. Similar to the XnAP data collection request message, the measurement configuration may include a reporting characteristics bitmap, and each bit in the bitmap may indicate an object the CU-CP 113 is requested to report. In some example embodiments, the reporting characteristics bitmap may include one bit serving as a simple flag indicating whether the CU- CP 113 is requested to report CCO issues. For example, if the bit is set to “1”, the CU-CP 113 is requested to perform CCO issue detection and report the detected CCO issues to the first DU 116a. If the bit is set to “0”, the CU-CP 113 is not requested to perform the CCO issue detection. Therefore, the first DU 116a may use the F1AP data collection request message to request the CCO issue detection or to cancel the request.

[0035] At 312, the CU-CP 113 may send a data collection response message to the first DU 116a confirming receipt of the data collection request message. The data collection response message may contain the gNB-DU measurement ID, a corresponding gNB-CU measurement ID, and optionally a failed reporting characteristics bitmap. Each bit in the failed reporting characteristics bitmap may indicate a measurement object that failed to be initiated in the CU- CP 113. For example, if the CU-CP 113 failed to initiate the CCO issue detection requested by the first DU 116a, the CU-CP 113 may set the corresponding bit in the failed reporting characteristics bitmap to “1”.

[0036] Referring back to Fig. 2, the request for CCO issue detection sent at 212 may indicate one or more cells and/or beams for which the CCO issue detection is requested. For instance, in case only a subset of the cells served by the first DU 116a support autonomous coverage reconfiguration that requires use of an active antenna system (AAS), or the first DU 116a determines to perform CCO for only a subset of the served cells, the request may contain a list of cells for which the CCO issue detection is requested. The above-mentioned flag may be set per cell indicating whether the CCO issue detection is requested for the cell. In some example embodiments, the request may optionally contain available coverage configurations per cell. The available coverage configurations may be represented by a simple list of indices known as coverage state indicator. A coverage state indicator may refer to an OAM-configured coverage configuration, which may be physically realized e.g. by configuring azimuth, tilt and reference signal power at an antenna unit connected to and under control of the first DU 116a. A possible representation of such coverage configuration at the CU-CP 113 may be the corresponding geographical area covered when the coverage configuration is applied. In some example embodiments, the request may optionally indicate type(s) of CCO issues requested per cell, e.g. cell edge capacity, coverage, or both, and may also indicate type(s) of corrective actions supported per cell, e.g. one or more of cell split, cell merge and cell shaping. Alternatively or additionally, the request may indicate corrective actions supported at the first DU 116a for all cells served by the first DU 116a.

[0037] In some example embodiments, similar CCO issue detection configuration information may be provided per beam. For instance, for a cell indicated in the request for CCO issue detection, the request may indicate a list of beams for which the CCO issue detection is requested. In some example embodiments, the request may further indicate one or more of the following: available coverage configurations per beam, type(s) of CCO issues requested per beam, and type(s) of corrective actions supported per beam.

[0038] An example information element (IE) for the CCO issue detection configuration contained in the CCO issue detection request is shown in Table 1 below.

Table 1 : Example of CCO Issue Detection Configuration Information

[0039] In response to the request for CCO issue detection received at 212, the CU-CP 113 may determine to activate the CCO issue detection for the cells and/or beams indicated in the request. Then at 214, the CU-CP 113 may configure measurement collection from UEs 101 and relevant network elements such as one or more of the CU-UP 115, the first DU 116a, the second DU 116b, and the neighboring gNB 120. The CU-CP 113 may configure measurement collection for the CCO issue detection using legacy or new messages on corresponding interfaces between the CU- CP 113 and the network elements or UEs. In some example embodiments, the CU-CP 113 may configure measurement collection from the neighboring gNB 120 e.g. via a resource status request message, a data collection request message and/or a NG-RAN node configuration update message. In some example embodiments, the CU-CP 113 may configure measurement collection from the first DU 116a and the second DU 116b e.g. via a resource status request message, a gNB-CU configuration update message and/or a data collection request message. In some example embodiments, the CU-CP 113 may configure measurement collection from the CU-CP 115 via an El message. In some example embodiments, the CU-CP 113 may configure measurement collection from UEs served by the first DU 116a and the second DU 116b via RRC signaling e.g. RRCConnectionConfiguration and/or RRCConnectionReconfiguration, and optionally from UEs served by the neighboring gNB 120 via an XnAP message sent to the neighboring gNB 120. In Fig. 2, UEs served by the first DU 116a, UEs served by the second DU 116b and UEs served by the neighboring gNB 120 are collectively shown as UEs 101.

[0040] At 216, the CU-CP 113 may receive measurement results reported from the UEs 101 and one or more of the CU-UP 115, the first DU 116a, the second DU 116b and the neighboring gNB 120. The UEs 101, the CU-UP 115, the first DU 116a, the second DU 116b and the neighboring gNB 120 may collect and report the measurement results according to the measurement collection configuration received at 214. Examples of the measurement results reported to the CU-CP 113 for the CCO issue detection may include but not be limited to: UE- generated reports following diverse scenarios, e.g. connection failure (such as radio link failure, handover failure), connection establishment failure, successful handover report, random access report; radio measurements received from the UEs, e.g. reference signal received power (RSRP), reference signal received quality (RSRQ), signal to interference plus noise ratio (SINR); location information reported by the UEs 101 or determined by the network; UE performance reports received from the CU-UP 115 or the gNB-DUs 116a, 116b, e.g. packet delay, packet loss, throughput; resource usage information received from the gNB-DUs 116a, 116b and the neighboring gNB 120, e.g. physical resource block (PRB) load, composite available capacity. It would be appreciated that additional measurements may also be configured and collected for the CCO issue detection.

[0041] In some example embodiments, if the CCO issue detection request received from the first DU 116a prescribes specific cells and/or beams for which the CCO issue detection is requested, the CU-CP 113 may configure and collect only measurements relevant to the prescribed cells and/or beams and their neighboring cells and/or beams for the CCO issue detection. It will reduce data collection for the CCO issue detection from UEs and relevant network entities and mitigate the signaling overhead of the network.

[0042] The CU-CP 113 may provide the received measurements as input information to an algorithm, e.g. an AI/ML model, running at the CU-CP 113. The input information may be used as training data for training the AI/ML model or as inference data for executing the AI/ML model. Before providing the measurements to the AI/ML model, the CU-CP 113 may pre-process the measurements, e.g. parsing, formatting and transforming the measurements, such that the obtained input information meets requirements of the AI/ML model. At 218, based on the input information, the algorithm, e.g. the AI/ML model, running at the CU-CP 113 may detect whether a CCO issue has occurred or will occur.

[0043] Fig 4 illustrates an example framework of the AI/ML model that can be used at the CU- CP 113 for CCO issue detection. As shown in Fig. 4, the AI/ML model may receive the measurement collection as input, and provide inference output based on the received input. The AI/ML model may detect CCO issues based on the following symptoms:

Coverage hole: A coverage hole is an area where the pilot signal strength is below a threshold which is required by a UE to access the network, or the SINR of both serving and neighboring cells is below a level needed to maintain the basic service. Coverage hole is usually caused by physical obstructions such as new buildings, hills, or by unsuitable antenna parameters, or just inadequate RF planning. UEs around coverage hole will suffer from call drop and radio link failure. Typical phenomenon of coverage hole is either handover failure happens frequently and cannot be optimized by handover parameter optimization or call drop happens frequently and cannot be rescued by RRC reestablishment.

Weak coverage: Weak coverage occurs when the pilot signal strength or the SNR or SINR of the serving cell is below a level needed to maintain a planned performance requirement (e.g. cell edge bit-rate).

Pilot pollution: In areas where coverage of different cells overlap a lot, interference levels are high, power levels are high, energy consumption is high and cell performance may be low. Typically in this situation UEs may experience high SNR to more than one cell and high interference levels.

Overshoot coverage: Overshoot occurs when coverage of a cell reaches far beyond what is planned. It can occur as an “island” of coverage in the interior of another cell, which may not be a direct neighbor. Reasons for overshoot may be reflections in buildings or across open water, lakes etc. UEs in this area may suffer call drops or high interference.

Downlink (DL) and uplink (UL) channel coverage mismatch: DL channel coverage is larger than UL channel coverage is one typical scenario of DL and UL channel coverage mismatch. The UE will suffer UL problems when it moves into the mismatch area.

[0044] It would be appreciated that the above symptoms are described here as non-limiting examples of symptoms of CCO issues, and the AI/ML model may also be designed and trained to detect other symptoms. In a realistic network, these symptoms may be tolerated to a certain level, and they may be considered a real problem when combined with other factors such as frequency of symptoms, duration of symptoms, or affected population. For example, if the AI/ML model detects that a coverage hole, i.e., UEs from an area experiencing/reporting radio link failures, lasts longer than a time duration (threshold), then the AI/ML model can identify it as a CCO issue. In another example, if the AI/ML model identifies that frequency of pilot pollution occurrence, e.g., served UEs experiencing/reporting high SNR to more than one cell and high inference levels, exceeds a threshold, the AI/ML model can diagnose a CCO issue. Such factors may be integrated as a part of the AI/ML model for CCO issue detection.

[0045] In some example embodiments, the AI/ML model may predict future CCO issues based on historic or experiential measurement data. For instance, if the historic measurement data indicates a large number of UEs move to a cell edge area at a certain time every day, the AI/ML model can predict that a cell edge capacity issue will occur at that time. The AI/ML model can output prediction of when the CCO issue will occur and how long the CCO issue will last.

[0046] As shown in Fig. 4, the output from the AI/ML model may be provided to an actor, which may trigger or perform corresponding actions based on the output. The actor may trigger actions directed to other entities or to itself. After the triggered actions are performed, the actor may also provide feedback information to the AI/ML model. The feedback information may be used to derive training data, inference data or to evaluate performance of the AI/ML Model. In the use case of CCO issue detection shown in Fig. 2, the first DU 116a may play a role of the actor, which will be described below.

[0047] Referring back to Fig. 2, at 220, the CU-CP 113 may send a CCO issue report indicating the detected CCO issue to the first DU 116a. The CCO issue report may be sent via e.g. a data collection update message, a gNB-CU configuration update message, or other legacy or new F1AP messages. In some example embodiments, if the CCO issue detection request received from the first DU 116a prescribes one or more cells and/or beams for which the CCO issue detection is requested, the CU-CP 113 may report the detected CCO issue to the first DU 116a only when the CCO issue is associated with at least one of the prescribed cells and/or beams. For instance, the CU-CP 113 may detect CCO issues at the first DU 116a regardless of whether the CCO issues are associated with the one or more cells or beams indicated in the CCO issue detection request, but the CU-CP 113 would refrain from reporting the CCO issues to the first DU 116a if the CCO issues are not associated with the cells or beams indicated in the request. In other words, the CU-CP 113 would report only CCO issues associated with the one or more cells or beams for which the CCO issue detection is requested. In some example embodiments, the CCO issue report may contain a list of cells and/or beams affected by the detected CCO issue, an example of which is shown in Table 2 below.

Table 2: A list of cells and/or beams affected by CCO issue

[0048] In some example embodiments, if the CCO issue detection request received from the first DU 116a prescribes additional requirements or attributes for the CCO issue detection, the CU-CP 113 may not report the detected CCO issue to the first DU 116a unless the CCO issue satisfies the prescribed requirements or attributes. For example, if the request indicates that coverage issue detection is requested for a cell, the CU-CP 113 would not report a cell edge capacity issue detected for the cell to the first DU 116a. As another example, if the request indicates that cell shaping is supported for a cell, the CU-CP 113 may report a CCO issue detected for the cell to the first DU 116a only when the CCO issue can be addressed by cell shaping.

[0049] In some example embodiments, in addition to the list of cells and/or beams affected by the detected CCO issue, the CCO issue report may further indicate type(s) of CCO issues associated with one or more cells and/or beams, prediction of when the CCO issue will occur, and/or prediction of how long the CCO issue will last. With the prediction information, the first DU 116a can appropriately determine and perform corrective actions to resolve or mitigate the CCO issue, reducing impacts due to constraints of the corrective actions.

[0050] With continuous reference to Fig. 2, the first DU 116a may determine a corrective action to resolve or mitigate the CCO issue at 222. The CCO feature provides support for corrective actions including cell shaping, cell split and cell merge, all of which involve coverage configuration changes. An example of cell shaping is illustrated in Figs. 5A and 5B. Referring to Fig. 5Afirst, a first cell is served by SSB beams #l-#3, and a second cell is served by SSB beams #4-#6. It is assumed that a cell edge capacity issue is detected for Beam #2 because a number of UEs are located at the edge of Beam #2. Referring to Fig. 5B, the first cell may apply a new coverage configuration for Beam #2 to extend the coverage of Beam #2 so that the number of UEs are located at a strong beam area, instead of at the beam edge. Therefore, the cell edge capacity is optimized by re-shaping the cell. In response to the coverage configuration change of Beam #2, the second cell may also apply a new coverage configuration for Beam #5 to reduce overlapping between Beam #2 and Beam #5, thereby reducing interference in the overlapping area. Cell split/merge also involves coverage configuration changes e.g. for a new/replacing cell obtained by splitting and/or merging existing cells, details being omitted here for convenience. [0051] Referring back to Fig. 2, after determining the corrective action for the CCO issue at 222, the first DU 116a may carry out the determined corrective action at 224 by performing a coverage configuration change for the cells and/or beams affected by the CCO issue. The first DU 116a may autonomously adjust within and switch between the available coverage configurations to resolve or mitigate the CCO issue. In some example embodiments, if the CCO issue report received from the CU-CP 113 contains the prediction information of the CCO issue, e.g. prediction of when the CCO issue will occur and how long the CCO issue will last, the first DU 116a may appropriately schedule the determined corrective action taking into account the prediction information and constraints e.g. delay, energy consumption of the corrective action, so that impacts caused by implementation of the corrective action can be reduced or minimized. [0052] At 226, the first DU 116a may report the coverage configuration change to the CU-CP 113. In an example, the first DU 116a may send the coverage configuration change report via a gNB-DU configuration update message. In another example, the first DU 116a may use other legacy or new F1AP messages to send the coverage configuration change report. The coverage configuration change report may contain a list of cells and/or beams for which the coverage configuration is changed, a coverage state indicator of the cells and/or beams, and cause of the coverage change.

[0053] After receiving the coverage configuration change report from the first DU 116a, the CU-CP 113 may notify the neighboring gNB 120 of the coverage configuration change at 228. In an example, the CU-CP 113 may send the coverage configuration change notification via a NG-RAN node configuration update message. In another example, the CU-CP 113 may use other legacy or new XnAP messages to send the coverage configuration change notification. The coverage configuration change notification may contain the list of cells and/or beams for which the coverage configuration is changed, the coverage state indicator of the cells and/or beams, and the cause of the coverage change. The neighboring gNB 120 may use the coverage state indicator to adopt coverage configurations matching with neighboring cells coverage configurations, an example of which is shown in Fig. 5B.

[0054] In some example embodiments, if cell split/merge is needed for the CCO issue detected at 218, the CU-CP 113 may send a pre-change notification (not shown) to the neighboring gNB 120 before the coverage configuration change is actually performed at 224. The pre-change notification may be sent via a NG-RAN node configuration update message or other XnAP messages and may indicate the cell coverage state which is planned to be used at the next reconfiguration. The NG-RAN node configuration update message may also contain cell replacing information including a list of replacing cells. The neighboring gNB 120 may use the list to avoid mobility actions leading to connection or re-establishment failures during the reconfiguration.

[0055] At 230, the CU-CP 113 may receive feedback information for evaluating performance of the AI/ML model. In an example, the feedback information for model performance evaluation may be obtained using the same measurement configurations as those used to collect the input information for the AI/ML model. This can avoid unnecessary configuration of UEs and relevant network entities to generate the feedback information for model performance evaluation. As an example, the CU-CP 113 may evaluate the AI/ML model performance by comparing the measurements obtained before and after performing the coverage configuration change for resolving the CCO issue. The CU-CP 113 may use one or more of the following measurements as key performance indicators (KPIs) for evaluating the AI/ML model performance: the UE performance e.g. quality of service (QoS) parameters such as packet delay, packet loss, throughput, the UE measurements e.g. RSRP, RSRQ, SINR, and/or the observed connection failure e.g. radio link failure, handover failure, connection establishment failure. If the KPIs are improved after performing the coverage configuration change for resolving the detected CCO issue, the CU-CP 113 may determine that the AI/ML model has good performance.

[0056] If the first DU 116a determines at a certain time that the CCO issue detection is no longer needed for one or more cells and/or beams, the first DU 116a may send a request to cancel the CCO issue detection associated with the one or more cells and/or beams to the CU-CP 113 at 232. In some example embodiments, the cancellation request may reuse the gNB-DU configuration update message or the F1AP data collection request message conveying the CCO issue detection request as discussed above. The gNB-DU configuration update message or the F1AP data collection request message may contain a list of cells and/or beams, and the flag associated with the cell or beam may be set to “0” indicating that the CCO issue detection is not needed. [0057] In response to the cancellation request, the CU-CP 113 may stop the CCO issue detection for the cells and/or beams indicated in the cancellation request at 234. In some example embodiments, the CU-CP 113 may also notify the UEs 101 and relevant network elements such as the CU-UP 115, the first DU 116a, the second DU 116b and the neighboring gNB 120 to stop reporting measurements for the CCO issue detection of the concerned cells and/or beams.

[0058] Fig 6 is a schematic flowchart illustrating an example method 400. The method 400 may be performed at a distributed unit (DU) in a split radio access network (RAN), such as the DU 116 of the gNB 110 shown in Fig. 1.

[0059] Referring to Fig. 6, at 410, the DU 116 may send a request for CCO issue detection to the CU 112, or in particular to the CU-CP 113 of the CU 112, which governs the DU 116. The request may indicate one or more cells or beams for which the CCO issue detection is requested. For example, the request may contain a list of cells for which the CCO issue detection is requested. For one or more cells in the list, the request may also indicate a list of beams for which the CCO issue detection is requested.

[0060] In some example embodiments, the request may contain a flag per cell or beam indicating whether the CCO issue detection is requested for the cell or beam. For example, if the flag is set to “1”, the CCO issue detection is requested, if the flag is set to “0”, the CCO issue detection is not requested, or vice versa. In some example embodiments, the flag may be set for all the cells and/or beams indicated in the request.

[0061] In some example embodiments, the request may further indicate type(s) of CCO issues requested for one or more cells or beams, type(s) of corrective actions supported for one or more cells or beams, and/or available coverage configurations for one or more cells or beams. Examples of the CCO issues may include coverage issue and cell edge capacity issue. Examples of the corrective actions may include cell shaping, cell split and cell merge. The available coverage configurations may be pre-configured by 0AM for coverage and capacity optimization at the DU 116. If needed, the DU 116 may determine the available coverage configurations for the cells or beams before sending the request to the CU 112. In some example embodiments, the request may indicate the corrective actions supported at the DU 116 for all the cells and/or beams for which the CCO issue detection is requested, instead of indicating the corrective actions on a per cell or per beam basis.

[0062] At 420, the DU 116 may receive a CCO issue report from the CU 112, or in particular from the CU-CP 113 of the CU 112. The CCO issue report may indicate a CCO issue associated with the DU 116 detected at the CU 112 (or exactly at the CU-CP 113 of the CU 112). The CCO issue may also indicate one or more cells and/or beams affected by the CCO issue. The one or more cells and/or beams indicated in the CCO issue report may be a subset of the cells and/or beams indicated in the CCO issue detection request sent at 410. In other words, the CU 112 may merely report CCO issues associated with the cells and/or beams for which the CCO issue detection is requested.

[0063] In some example embodiments, the CCO issue report may further contain additional prediction information of the CCO issue. For example, the CCO issue report may indicate prediction of when the CCO issue will happen and how long it will last.

[0064] At 430, the DU 116 may perform a coverage configuration change for the one or more cells or beams that are affected by the CCO issue. For instance, the DU 116 may autonomously adjust within and switch between the available coverage configurations pre-configured at the DU 116 to resolve or mitigate the CCO issue. In some example embodiments, the DU 116 may perform the coverage configuration change taking into account the prediction information of the CCO issue, e.g. prediction of when the CCO issue will happen and how long it will last. For example, taking into account the prediction information, the DU 116 may schedule the coverage configuration change to reduce impacts caused by constraints e.g. delay and energy cost of the coverage configuration change.

[0065] In some example embodiments, before performing the coverage configuration change, the DU 116 may determine a corrective action supported at the DU 116 for the CCO issue indicated in the CCO issue report. The corrective action may include for example one or more of cell shaping, cell split and cell merge. When the corrective action is determined, the DU 116 may select and apply a new coverage configuration at 430 to implement the corrective action.

[0066] In an example embodiment, after the coverage configuration change is performed, the DU 116 may also report the coverage configuration change to the CU 112.

[0067] If the DU 116 determines that the CCO issue detection is no longer needed for one or more cells and/or beams for which the CCO issue detection is already requested at 410, the DU 116 may send a request to cancel the CCO issue detection for the one or more cells and/or beams to the CU 112 at 440. In some example embodiments, the cancellation request may reuse the gNB-DU configuration update message or the F1AP data collection request message conveying the CCO issue detection request as discussed above. The message may contain a list of the one or more cells and/or beams and the flag associated with the one or more cell and/or beam may be set to “0” indicating that the CCO issue detection is not needed. As indicated by the dashed line box representing the step 440, the step 440 may not be performed if the CCO issue detection is needed or if the CCO issue detection request designates an ending time for the requested CCO issue detection. In the latter case, the CU 112 will autonomously stop the CCO issue detection when the ending time expires.

[0068] Fig. 7 is a schematic flowchart illustrating an example method 500. The method 500 may be performed at a centralized unit (CU) in a split radio access network (RAN), such as the CU 112 of the gNB 110 shown in Fig. 1. In particular, the method 500 may be performed at the CU-CP 113 of the CU 112.

[0069] Referring to Fig. 7, at 510, the CU 112 may receive a request for CCO issue detection from the DU 116 which is under control of the CU 112. The request may indicate one or more cells and/or beams for which the CCO issue detection is requested. The step 510 may correspond to the step 410 shown in Fig. 6, details being omitted here for convenience.

[0070] In response to the CCO issue detection request, the CU 112 may detect CCO issues associated with the indicated cells and/or beams at 520. The CU 112 may run an AI/ML model or algorithm to detect the CCO issues. The AI/ML model or algorithm may receive measurements from relevant network entities and their served UEs as input and provide the CCO issue detection as output. Before the CCO issue detection, the CU 112 may configure measurement collection from the relevant network entities and UEs for the CCO issue detection. In some example embodiments, the CU-CP 113 of the CU 112 may configure measurement collection from one or more of the following: the CU-UPs 115 of the CU 112, the DUs 116 under control of the CU 112, the neighboring gNBs 120, and UEs 110 served by such network entities. [0071] If the CU 112 detects a CCO issue associated with one or more cells and/or beams for which the CCO issue detection is requested, the CU 112 may send a CCO issue report to the DU 116 at 530. The step 530 may correspond to the step 420 shown in Fig. 6. The CCO issue report may indicate the CCO issue associated with the one or more cells and/or beams. In some example embodiment, the CCO issue report may further contain prediction information of the CCO issue, e.g. prediction of when the CCO issue will happen and how long it will last.

[0072] In some example embodiments, the CU 112 may detect and report only CCO issues associated with the cells and beams for which the CCO issue detection is requested. In some other example embodiments, the CU 112 may detect all CCO issues associated with the DU 116, regardless of whether or not the CCO issues are associated with the cells and beams for which the CCO issue detection is requested. Then the CU 112 may selectively report CCO issues associated with the cells and beams for which the CCO issue detection is requested to the DU 116. In other words, the CU 112 will refrain from reporting the CCO issues associated with a cell or beam other than the cells and beams for which the CCO issue detection is requested to the DU 116.

[0073] The CU 112 may receive a request to cancel the CCO issue detection for one or more cells and/or beams from the DU 116 at 540. The step 540 may correspond to the step 440 shown in Fig. 6, details being omitted here for convenience. In response to the cancellation request, the CU 112 may stop the CCO issue detection for the one or more cells and/or beams at 550. In some example embodiments, the CU 112 may also stop measurement collection from the UEs 101 and the relevant network entities for the CCO issue detection.

[0074] As indicated by the dashed line boxes representing the steps 540, 550, the steps 540, 550 may not be performed for example if the CCO issue detection is needed. In another example embodiment, if the CCO issue detection request designates an ending time for the requested CCO issue detection, the step 540 may not be performed, and the CU 112 may autonomously stop at 550 the CCO issue detection when the ending time expires.

[0075] Fig 8 is a schematic block diagram illustrating an example apparatus 600. The apparatus 600 may be implemented to comprise or to form at least a part of a distributed unit (DU) such as the DU 116 discussed above to perform at least a part of operations related to the DU 116. The blocks of the apparatus 600 may be implemented with software, hardware, firmware or any combination thereof.

[0076] Referring to Fig. 8, the apparatus 600 may comprise a first means 610 for sending a request for CCO issue detection to a centralized unit (or in particular to a centralized unit control plane), a second means 620 for receiving a CCO issue report from the centralized unit (or in particular to the centralized unit control plane), and a third means 630 for performing a coverage configuration change in response to the received CCO issue report.

[0077] The CCO issue detection request sent from the first means 610 may indicate one or more cells or beams for which the CCO issue detection is requested. For instance, the request may contain a list of cells for which the CCO issue detection is requested. For one or more cells in the list, the request may further indicate a list of beams for which the CCO issue detection is requested. The request may also contain a flag per cell or beam indicating whether the CCO issue detection is requested for the cell or beam. In another example embodiment, the flag may be set for all the cells and/or beams indicated in the request.

[0078] In some example embodiments, the CCO issue detection request may further indicate type(s) of CCO issues requested for one or more cells or beams, e.g. coverage, cell edge capacity or both, type(s) of corrective actions supported for one or more cells or beams, e.g. one or more of cell shaping, cell split and cell merge, and/or available coverage configurations for one or more cells or beams. In an example embodiment, the apparatus 600 may optionally comprise a means (not shown) for determining the available coverage configurations pre-configured at the distributed unit. When the available coverage configurations are determined, the first means 610 can indicate the available coverage configurations for the concerned cells or beams in the CCO issue detection request.

[0079] In an example, the CCO issue detection request may contain one or more of the following: a flag indicating whether the capacity and coverage optimization issue detection is requested; a list of cells for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more cells; type of corrective action supported for one or more cells; available coverage configurations for one or more cells; or an indication of whether cell split, cell merge or cell shaping is supported.

[0080] In another example, the CCO issue detection request may further contain one or more of the following: a list of beams for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more beams; type of corrective action supported for one or more beams; or available coverage configurations for one or more beams.

[0081] The CCO issue report received at the second means 620 may indicate a CCO issue associated with one or more cells and/or beams. The one or more cells and/or beams indicated in the CCO issue report may be a subset of the cells and/or beams indicated in the CCO issue detection request sent from the first means 610. In some example embodiments, the CCO issue report may further contain additional prediction information of the CCO issue, e.g. prediction of when the CCO issue will happen and how long it will last.

[0082] In an example, the CCO issue report may contain one or more of the following: information of one or more cells affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more cells; prediction of when the capacity and coverage optimization issue will occur at the one or more cells; or prediction of how long the capacity and coverage optimization issue will last at the one or more cells.

[0083] In another example, the CCO issue report may further contain one or more of the following: information of one or more beams affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more beams; prediction of when the capacity and coverage optimization issue will occur with the one or more beams; or prediction of how long the capacity and coverage optimization issue will last with the one or more beams.

[0084] The third means 630 may perform the coverage configuration change for the one or more cells and/or beams to resolve or mitigate the CCO issue indicated in the CCO issue report. In an example embodiment, the apparatus 600 may optionally comprise a means (not shown) for determining a correction action for the CCO issue indicated in the CCO issue report. The correction action may comprise one or more of cell shaping, cell split and cell merge. After the correction action is determined, the third means 630 may select a new coverage configuration and perform the coverage configuration change to implement the determined correction action. [0085] In an example embodiment, the apparatus 600 may optionally comprise a fourth means 640 for sending a request to cancel the CCO issue detection for one or more cells or beams to the centralized unit. For example, if the CCO issue detection is no longer needed or the correction action for the CCO issue is no longer supported, the fourth means 640 may request the centralized unit to cancel the CCO issue detection.

[0086] Fig. 9 is a schematic block diagram illustrating an example apparatus 700. The apparatus 700 may be implemented to comprise or to form at least a part of a centralized unit (CU) such as the CU 112 discussed above to perform at least a part of operations related to the CU 112. In particular, the apparatus 700 may be implemented to comprise or to form at least a part of a centralized unit control plane (CU-CP) such as the CU-CP 113 discussed above to perform at least a part of operations related to the CU-CP 113. The blocks of the apparatus 700 may be implemented with software, hardware, firmware or any combination thereof.

[0087] Referring to Fig. 9, the apparatus 700 may comprise a first means 710 for receiving a request for CCO issue detection from a distributed unit, the request indicating one or more cells or beams for which the CCO issue detection is requested, a second means 720 for detecting a CCO issue associated with the distributed unit based on measurements received from the distributed unit, one or more neighboring nodes, and UEs served by the distributed unit and the one or more neighboring nodes, and a third means 730 for sending a CCO issue report indicating the CCO issue to the distributed unit in case the CCO issue is associated with at least one of the one or more cells or beams. Examples of the CCO issue detection request and the CCO issue report have been discussed above, a repetitive description thereof being omitted here for convenience.

[0088] In some example embodiments, the apparatus 700 may optionally comprise a fourth means 740 for receiving from the distributed unit a request to cancel the CCO issue detection for at least one of the one or more cells or beams, and a fifth means 750 for stopping the CCO issue detection for the at least one of the one or more cells or beams in response to the received cancellation request.

[0089] In an example, the one or more neighboring nodes include at least one of the following: one or more additional distributed units, the distributed unit and the one or more additional distributed units being associated with a centralized unit control plane; one or more centralized unit user planes associated with the centralized unit control plane; or one or more neighboring base stations.

[0090] In some example embodiments, the second means 720 may be configured to detect only CCO issues associated with the cells and beams for which the CCO issue detection is requested. Then the third means 730 may report the CCO issues in the CCO issue report to the distributed unit. In some other example embodiments, the second means 720 may be configured to detect all CCO issues associated with the distributed unit, regardless of whether or not the CCO issues are associated with the cells and beams for which the CCO issue detection is requested. The third means 730 may be configured to selectively report the CCO issues associated to the cells and beams for which the CCO issue detection is requested to the distributed unit. The apparatus 700 may further comprise a means (not shown) for refraining from reporting the CCO issue associated with a cell or beam for which the CCO issue detection is not requested to the distributed unit.

[0091] Fig 10 is a schematic block diagram illustrating devices in an example communication system 800. As shown in Fig. 10, the communication system 800 may include a distributed unit (DU) 810 and a centralized unit (CU) 820, or in particular a CU control plane (CU-CP) 820. Fig. 10 shows one DU 810 as an example, but the communication system 800 may comprise more than one DUs 810 that are connected to the CU/CU-CP 820. The communication system 800 may comprise additional devices like one or more CU user planes (CU-UPs) connected to the CU-CP 820 and to the DU 810, and one or more core network devices, which are not shown in Fig. 10 for convenience.

[0092] The DU 810 may comprise one or more processors 811, one or more memories 812 and one or more network interfaces 814 interconnected through one or more buses 815. The one or more buses 815 may be address, data, or control buses, and may include any interconnection mechanism such as series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. The one or more network interfaces 814 may provide wired or wireless communication links through which the DU 810 may communicate with other network devices, entities, elements or functions. For example, the DU 810 may communicate with the CU-CP 820 via a midhaul link 802. The one or more memories 812 may include instructions 813 which, when executed by the one or more processors 811, may cause the DU 810 to perform operations and procedures relating to the DUs 116 of the gNB 110 as described above.

[0093] The CU/CU-CP 820 may comprise one or more processors 821, one or more memories 822 and one or more network interfaces 824 interconnected through one or more buses 825. The one or more buses 825 may be address, data, or control buses, and may include any interconnection mechanism such as series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. The one or more network interfaces 824 may provide wired or wireless communication links through which the CU/CU- CP 820 may communicate with other devices, entities, elements or functions. For example, the CU/CU-CP 820 may communicate with the DU 810 via the midhaul link 802 and with a core network device (not shown) via a backhaul link. The one or more memories 822 may include instructions 823 which, when executed by the one or more processors 821, may cause the CU/CU-CP 820 to perform operations and procedures relating to the CU 112/CU-CP 113 of the gNB 110 as described above.

[0094] The one or more processors 811, 821 discussed above may be of any appropriate type that is suitable for the local technical network, and may include one or more of general purpose processors, special purpose processor, microprocessors, a digital signal processor (DSP), one or more processors in a processor based multi-core processor architecture, as well as dedicated processors such as those developed based on Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC). The one or more processors 811, 821 may be configured to control other elements of the DU 810 and the CU/CU-CP 820 and operate in cooperation with them to implement the procedures discussed above.

[0095] The one or more memories 812, 822 may include at least one storage medium in various forms, such as a transitory memory and/or a non-transitory memory. The transitory memory may include, but not limited to, for example, a random access memory (RAM) or a cache. The non- transitory memory may include, but not limited to, for example, a read only memory (ROM), a hard disk, a flash memory, and the like. The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM). Further, the one or more memories 812, 822 may include but not limited to an electric, a magnetic, an optical, an electromagnetic, an infrared, or a semiconductor system, apparatus, or device or any combination of the above.

[0096] It would be understood that blocks in the drawings may be implemented in various manners, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks may be implemented using software and/or firmware, for example, machine-executable instructions stored in the storage medium. In addition to or instead of machine-executable instructions, parts or all of the blocks in the drawings may be implemented, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-Chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0097] Some exemplary embodiments further provide program instructions which, when executed by one or more processors, may cause a device or apparatus to perform the procedures described above. The program instructions for carrying out procedures of the exemplary embodiments may be written in any combination of one or more programming languages. The program instructions may be provided to one or more processors or controllers of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program instructions, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program instructions may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0098] Some exemplary embodiments further provide a computer program product or a computer readable medium having the program instructions stored therein. The computer readable medium may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0099] As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[00100] Throughout the present disclosure, reference to “one embodiment,” “an embodiment,” “some embodiments,” “other embodiments,” etc. indicates that one or more particular features, structures, steps, concepts, and/or characteristics in accordance with principles of the present disclosure may be included in connection with the embodiment. However, such references do not necessarily mean that all embodiments include the particular features, structures, steps, concepts, and/or characteristics, or that an embodiment includes all features, structures, steps, concepts, and/or characteristics. Some embodiments may include one or more such features, structures, steps, concepts, and/or characteristics, in various combinations thereof. It should be understood that one or more of the features, structures, steps, concepts, and/or characteristics described with reference to one embodiment can be combined with one or more of the features, structures, steps, concepts, and/or characteristics of any of the other embodiments provided herein. That is, any of the features, structures, steps, concepts, and/or characteristics described herein can be mixed and matched to create hybrid embodiments, and such hybrid embodiments are within the scope of the present disclosure. Moreover, references to “one embodiment,” “an embodiment,” “some embodiments,” “other embodiments,” etc. in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. It should further be understood that various features, structures, steps, concepts, and/or characteristics of disclosed embodiments are independent of and separate from one another, and may be used or present individually or in various combinations with one another to create alternative embodiments which are considered part of the present disclosure. Therefore, the present disclosure is not limited to only the embodiments specifically described herein, as it would be too cumbersome to describe all of the numerous possible combinations and subcombinations of features, structures, steps, concepts, and/or characteristics, and the examples of embodiments disclosed herein are not intended as limiting the broader aspects of the present disclosure.

[00101]Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination. [00102] Although the subject matter has been described in a language that is specific to structural features and/or method actions, it is to be understood the subject matter defined in the appended claims is not limited to the specific features or actions described above. On the contrary, the above-described specific features and actions are disclosed as an example of implementing the claims.

Claims

CLAIMS:

1. A distributed unit, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the distributed unit at least to perform: sending, to a centralized unit, a request for capacity and coverage optimization issue detection, the request indicating one or more cells or beams for which the capacity and coverage optimization issue detection is requested; receiving, from the centralized unit, a capacity and coverage optimization issue report indicating a capacity and coverage optimization issue associated with at least one of the one or more cells or beams; and performing a coverage configuration change for the at least one of the one or more cells or beams, in response to the received capacity and coverage optimization issue report.

2. The distributed unit of claim 1, wherein the request for capacity and coverage optimization issue detection contains one or more of the following: a flag indicating whether the capacity and coverage optimization issue detection is requested; a list of cells for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more cells; type of corrective action supported for one or more cells; available coverage configurations for one or more cells; or an indication of whether the distributed unit supports cell split, cell merge or cell shaping.

3. The distributed unit of claim 2, wherein the request for capacity and coverage optimization issue detection further contains one or more of the following: a list of beams for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more beams; type of corrective action supported for one or more beams; or available coverage configurations for one or more beams.

4. The distributed unit of any of claims 1-3, wherein the capacity and coverage optimization issue report contains one or more of the following: information of one or more cells affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more cells; prediction of when the capacity and coverage optimization issue will occur at the one or more cells; or prediction of how long the capacity and coverage optimization issue will last at the one or more cells.

5. The distributed unit of claim 4, wherein the capacity and coverage optimization issue report further contains one or more of the following: information of one or more beams affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more beams; prediction of when the capacity and coverage optimization issue will occur with the one or more beams; or prediction of how long the capacity and coverage optimization issue will last with the one or more beams.

6. The distributed unit of any of claims 1-5, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the distributed unit at least to perform: determining available coverage configurations pre-configured at the distributed unit, before sending the request for capacity and coverage optimization issue detection.

7. The distributed unit of any of claims 1-6, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the distributed unit at least to perform: determining a correction action to perform based on the capacity and coverage optimization issue report before performing the coverage configuration change, the correction action comprising one or more of cell shaping, cell split and cell merge, and the coverage configuration change being performed to implement the determined correction action.

8. The distributed unit of any of claims 1-7, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the distributed unit at least to perform: sending, to the centralized unit, a request to cancel the capacity and coverage optimization issue detection for at least one of the one or more cells or beams.

9. A centralized unit, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the centralized unit at least to perform: receiving, from a distributed unit, a request for capacity and coverage optimization issue detection, the request indicating one or more cells or beams for which the capacity and coverage optimization issue detection is requested; detecting a capacity and coverage optimization issue associated with the distributed unit based on measurements received from the distributed unit, one or more neighboring nodes, and user equipment served by the distributed unit and the one or more neighboring nodes; and sending, to the distributed unit, a capacity and coverage optimization issue report indicating the capacity and coverage optimization issue in case the capacity and coverage optimization issue is associated with at least one of the one or more cells or beams.

10. The centralized unit of claim 9, wherein the request for capacity and coverage optimization issue detection contains one or more of the following: a flag indicating whether the capacity and coverage optimization issue detection is requested; a list of cells for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more cells; type of corrective action supported for one or more cells; available coverage configurations for one or more cells; or an indication of whether the distributed unit supports cell split, cell merge or cell shaping.

11. The centralized unit of claim 10, wherein the request for capacity and coverage optimization issue detection further contains one or more of the following: a list of beams for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more beams; type of corrective action supported for one or more beams; or available coverage configurations for one or more beams.

12. The centralized unit of any of claims 9-11, wherein the capacity and coverage optimization issue report contains one or more of the following: information of one or more cells affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more cells; prediction of when the capacity and coverage optimization issue will occur at the one or more cells; or prediction of how long the capacity and coverage optimization issue will last at the one or more cells.

13. The centralized unit of claim 12, wherein the capacity and coverage optimization issue report further contains one or more of the following: information of one or more beams affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more beams; prediction of when the capacity and coverage optimization issue will occur with the one or more beams; or prediction of how long the capacity and coverage optimization issue will last with the one or more beams.

14. The centralized unit of any of claims 9-13, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the centralized unit at least to perform: receiving, from the distributed unit, a request to cancel the capacity and coverage optimization issue detection for at least one of the one or more cells or beams; and stopping the capacity and coverage optimization issue detection for the at least one of the one or more cells or beams in response to the received request.

15. The centralized unit of any of claims 9-14, wherein the centralized unit is a centralized unit control plane, and the one or more neighboring nodes include at least one of the following: one or more additional distributed units associated with the centralized unit control plane; one or more centralized unit user planes associated with the centralized unit control plane; or one or more neighboring base stations.

16. The centralized unit of any of claims 9-15, wherein the centralized unit detects the capacity and coverage optimization issue associated with the distributed unit regardless of whether the capacity and coverage optimization issue is associated with the one or more cells or beams indicated in the request for capacity and coverage optimization issue detection, and the centralized unit refrains from reporting the capacity and coverage optimization issue to the distributed unit in case the capacity and coverage optimization issue is associated with a cell or beam other than the one or more cells or beams indicated in the request for capacity and coverage optimization issue detection.

17. A method, comprising: sending, to a centralized unit, a request for capacity and coverage optimization issue detection, the request indicating one or more cells or beams for which the capacity and coverage optimization issue detection is requested; receiving, from the centralized unit, a capacity and coverage optimization issue report indicating a capacity and coverage optimization issue associated with at least one of the one or more cells or beams; and performing a coverage configuration change for the at least one of the one or more cells or beams, in response to the received capacity and coverage optimization issue report.

18. The method of claim 17, wherein the request for capacity and coverage optimization issue detection contains one or more of the following: a flag indicating whether the capacity and coverage optimization issue detection is requested; a list of cells for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more cells; type of corrective action supported for one or more cells; available coverage configurations for one or more cells; or an indication of whether cell split, cell merge or cell shaping is supported.

19. The method of claim 18, wherein the request for capacity and coverage optimization issue detection further contains one or more of the following: a list of beams for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more beams; type of corrective action supported for one or more beams; or available coverage configurations for one or more beams.

20. The method of any of claims 17-19, wherein the capacity and coverage optimization issue report contains one or more of the following: information of one or more cells affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more cells; prediction of when the capacity and coverage optimization issue will occur at the one or more cells; or prediction of how long the capacity and coverage optimization issue will last at the one or more cells.

21. The method of claim 20, wherein the capacity and coverage optimization issue report further contains one or more of the following: information of one or more beams affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more beams; prediction of when the capacity and coverage optimization issue will occur with the one or more beams; or prediction of how long the capacity and coverage optimization issue will last with the one or more beams.

22. The method of any of claims 17-21, further comprising: determining available coverage configurations pre-configured at a distributed unit, before sending the request for capacity and coverage optimization issue detection.

23. The method of any of claims 17-22, further comprising: determining a correction action to perform based on the capacity and coverage optimization issue report before performing the coverage configuration change, the correction action comprising one or more of cell shaping, cell split and cell merge, and the coverage configuration change being performed to implement the determined correction action.

24. The method of any of claims 17-23, further comprising: sending, to the centralized unit, a request to cancel the capacity and coverage optimization issue detection for at least one of the one or more cells or beams.

25. A method, comprising: receiving, from a distributed unit, a request for capacity and coverage optimization issue detection, the request indicating one or more cells or beams for which the capacity and coverage optimization issue detection is requested; detecting a capacity and coverage optimization issue associated with the distributed unit based on measurements received from the distributed unit, one or more neighboring nodes, and user equipment served by the distributed unit and the one or more neighboring nodes; and sending, to the distributed unit, a capacity and coverage optimization issue report indicating the capacity and coverage optimization issue in case the capacity and coverage optimization issue is associated with at least one of the one or more cells or beams.

26. The method of claim 25, wherein the request for capacity and coverage optimization issue detection contains one or more of the following: a flag indicating whether the capacity and coverage optimization issue detection is requested; a list of cells for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more cells; type of corrective action supported for one or more cells; available coverage configurations for one or more cells; or an indication of whether the distributed unit supports cell split, cell merge or cell shaping.

27. The method of claim 26, wherein the request for capacity and coverage optimization issue detection further contains one or more of the following: a list of beams for which the capacity and coverage optimization issue detection is requested; type of capacity and coverage optimization issue requested for one or more beams; type of corrective action supported for one or more beams; or available coverage configurations for one or more beams.

28. The method of any of claims 25-27, wherein the capacity and coverage optimization issue report contains one or more of the following: information of one or more cells affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more cells; prediction of when the capacity and coverage optimization issue will occur at the one or more cells; or prediction of how long the capacity and coverage optimization issue will last at the one or more cells.

29. The method of claim 28, wherein the capacity and coverage optimization issue report further contains one or more of the following: information of one or more beams affected by the capacity and coverage optimization issue; type of capacity and coverage optimization issue associated with the one or more beams; prediction of when the capacity and coverage optimization issue will occur with the one or more beams; or prediction of how long the capacity and coverage optimization issue will last with the one or more beams.

30. The method of any of claims 25-29, further comprising: receiving, from the distributed unit, a request to cancel the capacity and coverage optimization issue detection for at least one of the one or more cells or beams; and stopping the capacity and coverage optimization issue detection for the at least one of the one or more cells or beams in response to the received request.

31. The method of any of claims 25-30, wherein the one or more neighboring nodes include at least one of the following: one or more additional distributed units, the distributed unit and the one or more additional distributed units being associated with a centralized unit control plane; one or more centralized unit user planes associated with the centralized unit control plane; or one or more neighboring base stations.

32. The method of any of claims 25-31, wherein the capacity and coverage optimization issue associated with the distributed unit is detected regardless of whether the capacity and coverage optimization issue is associated with the one or more cells or beams indicated in the request for capacity and coverage optimization issue detection, and the capacity and coverage optimization issue is refrained from being reported to the distributed unit in case the capacity and coverage optimization issue is associated with a cell or beam other than the one or more cells or beams indicated in the request for capacity and coverage optimization issue detection.

33. An apparatus for a distributed unit, comprising means for performing the method of any of claims 17-24.

34. An apparatus for a centralized unit, comprising means for performing the method of any of claims 25-32.

35. A computer readable medium comprising instructions that, when executed by an apparatus for a distributed unit, cause the apparatus to perform the method of any of claims 17-

24.

36. A computer readable medium comprising instructions that, when executed by an apparatus for a centralized unit, cause the apparatus to perform the method of any of claims 25- 32.