WO2025207005A1

WO2025207005A1 - Predicting coverage and capacity issues

Info

Publication number: WO2025207005A1
Application number: PCT/SE2025/050263
Authority: WO
Inventors: Luca LUNARDI; Vengatanathan KRISHNAMOORTHI; Ioanna Pappa; Angelo Centonza; Philipp BRUHN
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2024-03-29
Filing date: 2025-03-25
Publication date: 2025-10-02
Anticipated expiration: 2026-09-29

Abstract

A first Radio Access Network, RAN, node (120a) predicts a Coverage and Capacity Optimization, CCO, issue impacting a coverage area (130) served by a second RAN node (120b) The first RAN node (120a) transmits, to the second RAN node (120b), a notification message indicating the predicted CCO issue. The second RAN node (120b) receives the notification message from the first RAN node (120a).

Description

PREDICTING COVERAGE AND CAPACITY ISSUES

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 63/571606, filed 29 March 2024, the entire disclosure of which is hereby incorporated by reference herein.

TECHNICAL FIELD

The present disclosure generally relates to the technical field of wireless communication and, more particularly, to predicting coverage and capacity issues within a Radio Access Network (RAN) of the wireless communication network.

BACKGROUND

Coverage and Capacity Optimization (CCO) is the practice of tuning a network to improve coverage and/or capacity. Traditionally, this practice has involved performing drive tests to identify coverage and capacity problems and planning out corresponding solutions. Conventional approaches to CCO are often heavily reliant on measurements taken by the RAN and reported by User Equipment (UE). Network operators then use a variety of largely manual planning tools to produce a tuning solution, which they then implement within the network.

SUMMARY

The present disclosure generally relates to enabling a network to address predicted CCO issues. Particular embodiments include a first RAN node that predicts a CCO issue impacting a coverage area served by a second RAN node and transmitting, to the second RAN node, a notification message indicating the CCO issue. Correspondingly, the second RAN node receives the notification from the first ran node. In some embodiments, the second RAN node modifies coverage of the coverage area to address the CCO issue.

Embodiments include a method implemented by a first RAN node. The method comprises predicting a CCO issue impacting a coverage area served by a second RAN node. The method further comprises transmitting, to the second RAN node, a notification message indicating the predicted CCO issue.

In some embodiments, the second RAN node is a Distributed Unit (DU). The first RAN node is a Centralized Unit (CU) controlling the DU.

In some embodiments, the method further comprises the notification message further indicates a time when the predicted CCO issue will occur.

In some embodiments, the method further comprises receiving, from the second RAN node, an indication of a future time at which the second RAN node will provide a coverage modification associated with the predicted CCO issue.

In some embodiments, the method further comprises indicating, to a third RAN node, a time when one or more cells and/or Synchronization Signal Blocks (SSBs) served by the second RAN node will assume a certain coverage state corresponding to the predicted CCO issue. In some such embodiments, the third RAN node is a CU not controlling the DU. In some embodiments, the notification message further indicates one or more cells and/or beams associated with the coverage area and predicted to be affected by the predicted CCO issue.

In some embodiments, the notification message further indicates an identifier of the CCO issue.

In some embodiments, the notification message further indicates a metric for detecting the predicted CCO issue.

In some embodiments, the notification message indicates a configuration parameter for providing feedback associated with the CCO issue.

In some embodiments, the method further comprises receiving, from the second RAN node, a response message indicating whether the second RAN node will address the predicted CCO issue.

In some embodiments, the method further comprises receiving, from the second RAN node, a configuration modification message indicating a coverage modification that the second RAN node will apply to address the predicted CCO issue.

Other embodiments include a first RAN node. The first RAN node is configured to predict a CCO issue impacting a coverage area served by a second RAN node. The first RAN node is further configured to transmit, to the second RAN node, a notification message indicating the predicted CCO issue.

In some embodiments, the first RAN node is further configured to perform any one of the first RAN node methods described above.

In some embodiments, the first RAN node comprises interface circuitry and processing circuitry communicatively connected to the interface circuitry. The processing circuitry is configured to perform any one of the first RAN node methods described above.

Yet other embodiments include a computer program comprising instructions which, when executed on processing circuitry of a first RAN node, cause the processing circuitry to carry out any one of the first RAN node methods described above.

Still other embodiments include a carrier containing said computer program. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Other embodiments include a method implemented by a second RAN node. The method comprises receiving, from a first RAN node, a notification message indicating a predicted CCO issue impacting a coverage area served by the second RAN node.

In some embodiments, the second RAN node is a DU. The first RAN node is a CU controlling the DU.

In some embodiments, the notification message further indicates a time when the predicted CCO issue will occur. In some embodiments, the method further comprises sending, to the first RAN node, an indication of a future time at which the second RAN node will provide a coverage modification associated with the predicted CCO issue.

In some embodiments, the notification message further indicates one or more cells and/or beams associated with the coverage area and predicted to be affected by the predicted CCO issue.

In some embodiments, the notification message further indicates an identifier of the predicted CCO issue.

In some embodiments, the notification message indicates a configuration parameter for providing feedback associated with the predicted CCO issue.

In some embodiments, the method further comprises transmitting, to the first RAN node, a configuration modification message indicating a coverage modification that the second RAN node will apply to address the predicted CCO issue.

In some embodiments, the method further comprises modifying coverage of the coverage area to address the predicted CCO issue.

Yet other embodiments include a second RAN node. The second RAN node is configured to receive, from a first RAN node, a notification message indicating a predicted CCO issue impacting a coverage area served by the second RAN node.

In some embodiments, the second RAN node is further configured to perform any one of the second RAN node methods described above.

In some embodiments, the second RAN node comprises interface circuitry and processing circuitry communicatively connected to the interface circuitry. The processing circuitry is configured to perform any one of the second RAN node methods described above.

Still other embodiments include a computer program comprising instructions which, when executed on processing circuitry of a second RAN node, cause the processing circuitry to carry out any one of the second RAN node methods described above.

Yet still other embodiments include a carrier containing said computer program. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying figures with like references indicating like elements.

FIG. 1 is a schematic block diagram illustrating an example network, according to one or more embodiments of the present disclosure.

FIG. 2 is a schematic block diagram illustrating an example RAN, according to one or more embodiments of the present disclosure. FIG. 3 is a schematic block diagram illustrating an example gNB, according to one or more embodiments of the present disclosure.

FIG. 4 is a flow diagram illustrating an example method implemented by a first RAN node, according to one or more embodiments of the present disclosure.

FIG. 5 is a flow diagram illustrating an example method implemented by a first RAN node, according to one or more embodiments of the present disclosure.

FIGS. 6-9 are signaling diagrams illustrating different examples of signaling exchanged between RAN nodes, according to one or more embodiments of the present disclosure.

FIG. 10 is a schematic block diagram illustrating an example RAN node, according to one or more embodiments of the present disclosure.

FIGS. 11A-D are a table describing lEs in accordance with a first implementation example.

FIGS. 12A-D are a table describing lEs in accordance with a second implementation example.

FIG. 13 is a table describing lEs in accordance with the first step of a third implementation example.

FIGS. 14A-B are a table describing lEs in accordance with the second step of a third implementation example.

FIG. 15 is a table describing lEs in accordance with a fourth implementation example.

FIG. 16 is a table describing lEs in accordance with a fifth implementation example.

FIG. 17 is a table describing lEs in accordance with a first step of a sixth implementation example.

FIGS. 18A-C are a table describing lEs in accordance with a second step of a sixth implementation example.

DETAILED DESCRIPTION

The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.

In the examples provided herein, examples may be given that are commonly associated with a particular generation of Third Generation Partnership Project (3GPP) networks. For example, the term gNB (a term that was first used in connection with Fifth Generation (5G) networks) may be used to refer to a RAN node of a 5G RAN. These specific examples are given solely for purposes of illustration and should not be interpreted to exclude other network elements, whether presently known or to be developed in the future. Indeed, the embodiments described herein may be applied to any generation of 3GPP network unless otherwise specified. FIG. 1 is a schematic block diagram illustrating an example of a UE 1 10 connected to a wireless communication network 100. The wireless communications network 100 comprises a core network 160 and a Radio Access Network (RAN) represented in this example by a first RAN node 120a and a second RAN node 120b. In this example, each RAN node 120a and 120b serves a respective coverage area 130a and 130b, in which the UE 110 may access the core network 160. Each coverage area 130a, 130b may be served by one or more cells and/or beams and/or reference signals. The core network 160 comprises one or more core network nodes 140 that support the UE 1 10 in accessing core network services and/or resources provided by an external data network 170.

FIG. 2 is a schematic block diagram illustrating the RAN 150 described above. As previously noted, the RAN 150 comprises RAN nodes 120a and 120b. The RAN nodes 120a and 120b are interconnected. Each RAN node 120a, 120b may support communication with one or more UEs 1 10 using one or more Radio Access Technologies (RATs) (e.g., Long Term Evolution (LTE), New Radio (NR)). In this regard, each RAN node 120a, 120b may support Frequency Division Duplexing (FDD), Time Division Duplexing (TDD), Orthogonal Frequency Division Multiplexing (OFDM), or any combination thereof (e.g., dual mode FDD/TDD).

In this example, RAN node 120a may comprise a Centralized Unit (CU) 250 and one or more Distributed Units (DUs) 220a, 220b. The CU 250 is connected to each of the DUs 220a, 220b. The CU 250 and the DUs 220a and 220b may be configured to handle different parts of the radio protocol stack. For example, a CU 250 may support higher protocol layers (e.g., Radio Resource Control (RRC)). A DU 220a, 220b may provide support for lower protocol layers (e.g., Radio Link Control (RLC), Medium Access Control (MAC)). Typically (but not necessarily), there is a single CU 250 and any number of DUs 220, each DU 220 supporting one or more cells. In some embodiments, there may be more than a hundred DUs 220 that operate under the control of a single CU 250.

Either or both of the RAN nodes 120a, 120b may be a gNodeB (gNB). In such an example, the CU 250 may be a gNB-CU and each DU 220 may be a gNB-DU. The gNB-CU may be connected to each of the gNB-DUs via an F1 interface. The core network 160 may be a Fifth Generation Core (5GC) and each RAN node 120a, 120b may be connected to the core network 160 over a Next Generation (NG) interface (e.g., in accordance with a traditional NG- RAN architecture). Further, the RAN nodes 120a, 120b may be interconnected by one or more Xn interfaces, e.g., an Xn User Plane (Xn-U) interface and an Xn Control Plane (Xn-C) interface.

According to other embodiments, either or both of the RAN nodes 120a, 120b may be a Next Generation eNodeB (ng-eNB). In such an ng-eNB, the CU 250 may be an ng-eNB-CU and each DU 220 may be an ng-eNB-DU(s). In such an embodiment, the ng-eNB-CU and an ng-eNB-DU may be connected via a W1 interface. The core network 160 may be an Evolved Packet Core (EPC) and each RAN node 120a, 120b may be connected to the EPC via one or more S1 interfaces (e.g., an S1 User Plane (S1-U) interface and an S1-Control Plane (S1-C) interface.

The RAN 150 may, in some embodiments, support Evolved Non-standalone Dual Connectivity (EN-DC) in which one of the RAN nodes 120a is a gNB and the other RAN node 120b is an eNB. The NG and Xn-C interfaces for a gNB comprising a gNB-CU and one or more gNB-DUs terminate in the gNB-CU. For, the S1-U and X2-C interfaces for a gNB comprising a gNB-CU and gNB-DUs terminate in the gNB-CU. The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB.

FIG. 3 illustrates the overall architecture of a gNB 260. As shown, a feature of the gNB architecture is control plane I user plane separation. A gNB 260 may comprise a CU 250 for the control plane (i.e., a gNB-CU-CP 265), one or more CUs 250 for the user plane (i.e., one or more gNB-CU-UPs 270) and one or more gNB-DUs 280. The gNB-CU-CP 265 is connected to each gNB-DU 280 through an F1-C interface. One or more of the gNB-CU-UPs 270 may be connected to one or more of the gNB-DUs 280 through an F1-U interface. The gNB-CU-UP 265 is connected to each gNB-CU-CP 270 through an E1 interface. A gNB-DU 280 is connected to only one gNB-CU-CP 265. A gNB-CU-UP 270 is connected to only one gNB-CU-CP 265.

In some embodiments, a gNB-DU 280 may comprise a lower DU 285 and an upper DU 290 that are connected by a fronthaul interface. The lower DU 290 handles Physical Layer (PHY) protocol and Radio Frequency (RF) aspects. The upper DU 285 handles RLC and MAC. In some embodiments, the upper DU 285 may be called an O-DU, whereas the lower DU may be called an O-RU.

Given the above, for purposes of this disclosure, a network node may refer to a core network node 160 or a RAN node 120. A RAN node 120 may refer to any node in the RAN 150, e.g., a gNB 260, an eNB, a CU 250, a DU 220, and so on.

Many aspects of the RAN 150 and the RAN nodes 120 for the next generation of wireless networks are under development. Accordingly, many implementation details have yet to be understood. In particular, many CCO use cases with respect to the RAN 150 and its components have yet to be developed. Further, Artificial Intelligence (Al) and Machine Learning (ML) (collectively referred to as AI/ML or AIML) use cases for the RAN 150 and its components have yet to be developed. AI/ML uses cases that leverage AL/ML techniques are particularly underdeveloped at present.

For example, it is presently unknown what kind of timing information needs to be exchanged in order to ensure that a new recommended CCO configuration is promptly adopted. There is also no current solution for what to do when a predicted CCO issue is no longer valid. It is also not known how ensure that knowledge of a predicted CCO issue detected by one network node can be properly handled by another. As another example, it is currently how to characterize UE distribution and UE performance when it is recognized that they can be used. In particular, there are no specifics regarding how such can be applied to tackle a CCO issue. Another aspect that is not currently understood is how to ensure that solutions to a predicted CCO issue do not conflict with network optimization tasks that may already be underway and what to do when such a conflict is present. Current techniques lack detail regrading how to evaluate actions undertaken as part of CCO reconfiguration, especially with regard to actions derived based on predicted CCO issues.

When a predicted CCO issue is used as a basis for change the existing network configuration such that a potential problem is preempted, observing whether the potential CCO issue would have manifested in the network without the corrective actions being taken is not straightforward given that data generated by the network after an action has been initiated (e.g., to prevent the predicted issue) will be tainted by this action.

Such a situation may lead to unjustified reliance on the CCO algorithm performing predictions, lack of understanding of why certain issues manifest, ping-ponging, and an inability to explain actions taken by a network node changing the network configuration (e.g., a gNB-DU 280) based on a predicted CCO issue, e.g., indicated by a gNB-CU 265, 270. Metrics of greater granularity would also be helpful toward extract additional performance from the network and understanding network performance in detail.

Accordingly, embodiments of the present disclosure include a method 300 performed by a first RAN node 120a, e.g., as illustrated in FIG. 4. The method 300 comprises predicting a CCO issue impacting a coverage area 130 served by a second RAN node 120b (block 310). The method 300 further comprises transmitting, to the second RAN node (120b), a notification message indicating the predicted CCO issue (block 320).

Correspondingly, other embodiments of the present disclosure include a method 400 performed by a second RAN node 120b, e.g., as illustrated in FIG. 5. The method 400 comprises receiving, from a first RAN node, a notification message indicating a predicted CCO issue impacting a coverage area 130 served by the second RAN node 120b (block 410). In some embodiments, the method 300 further comprises modifying coverage of the coverage area 130 to address the CCO issue (block 420).

Generally speaking, one or more embodiments of the present disclosure may comprise a CCO self-optimization function that is assisted by AIML algorithms and models. For example, an AIML inference function may predict certain CCO issues (e.g., a capacity issue and/or a coverage issue) a coverage area 130 affected by the predicted CCO issue (e.g., cells and/or Synchronization Signal Block (SSB) beams serving the coverage area 130), and/or other parameters associated to the CCO issues (e.g., a reference time in the future when the CCO issue is predicted to occur, the percentage of users impacted, etc.). Further, one or more embodiments enable validation of CCO issue predictions of a model and the evaluation of the actions performed in reaction to a predicted CCO issue, such that an ideal time at which actions need to conducted can be learned. One or more embodiments may advantageously preempt or alleviate potential CCO issue by proactively enable coverage modifications of cells and/or SSB beams. The actions taken by one network node to avoid I counteract the degradation in network performance may be shared with other network nodes, which may allow the other nodes to coordinate their cells configurations and maintain/improve the network performances and/or the user performances in a geographical area whose coverage is provided by multiple network nodes.

The problem of CCO optimization can be performed at different logical entities. In the proposed solution, two network nodes exchange information related to predicted CCO issue(s) detection and resolution. From a functional point of view (and assuming NR as radio access technology in use) the CCO prediction function is deployed in the first network node (e.g., a gNB-CU) and the network node (or function) acting on the predicted CCO information, i.e., the function to choose a cell/beam coverage shape to perform interventions on the predicted CCO issue is in the second network node (e.g., a gNB-DU 280). Feedback related to the predicted CCO issue can be sent from the gNB-DU 280 to the gNB-CU. In a scenario where two (or more) RAN nodes are involved (e.g., a first gNB and a second gNB), a predicted CCO issue (affecting cells/beams of the first RAN node and/or cells/beams of the second RAN node) and/or the corresponding information related to the predicted CCO issue resolution and/or associated feedback are signaled via inter-RAN node signaling protocols (e.g., via Xn Application Protocol (XnAP)).

Embodiments may also be performed if the proposed function are deployed in different logical entities. Similarly, the feedback obtained as part of the proposed solution could be exchanged to different nodes depending on the functionality that may be employed at the different nodes.

Understanding if a predicted CCO issue would materialize in the network at the predicted time, and with the expected characteristics are important both for the logical node providing the prediction (e.g., as AIML inference output) and for the logical node using the prediction to perform a corresponding action aiming at preventing the issue to occur (or mitigate the potential effects), resulting in a net better performance of the network. For the node performing the actions, it means that the actions taken are in relation to an issue with certain characteristics (e.g., high number of UE with high demand of network resources at cell edge), which may have started to materialize, even though the detrimental effect is not yet at its peak, and as a consequence, the taken actions are in the right direction that would result in an improvement of the KPIs or in another option, the taken actions result in keeping the KPIs to a stable level, or in a further option, the taken actions results in a recovery of initially degraded KPIs, before the KPI values degrades to much and become unsatisfactory. In a variation of the above, the KPIs are instead one or more indicators (or Performance Indicators), used as metrics to evaluate if a specific configuration adopted by the network is good or not, or whether a function in the network is working as expected or not. Examples of KPIs or Performance Indicators can be the average throughput per cell or per UE, the amount (or percentage) of calls dropped, failures in the execution of mobility procedures (particularly at cell edge), inbalance between uplink and downlink coverage, pilot pollution, etc. For the node performing the predictions, when compared to external validation, performing validation on predictions performed on real traffic can aid in continuous alignment of a model to the existing network characteristics. It is also reasonable to ascertain that when the predicted issues map well to real issues that manifest in the network, the number of interactions between the two entities in fine tuning a CCO related action would be minimized.

While it is expected and it should be the case that the AIML model executing in the node performing the predictions is to be externally validated before deployment, the AIML model output validation suggested as part of this invention can be used as continual input to the model to fine-tune a deployed model without having the need to retrain the model externally and redeploy.

The solutions described herein could also be applied to other use-cases, where continual model refinement is beneficial, and the use-case makes it possible to perform the real- world validation without significantly degrading the purpose for which the AIML model output is used for.

While one or more goals of the prediction may be to accurately predict the occurrence of a CCO issue, both in relation to the time and the magnitude of the issue ahead of time, the logical entity I network node receiving the CCO issue prediction (and affected cells/beams) and/or the logical entity / network node performing the actions based on the received prediction has the entire time horizon, i.e., time between when a prediction is available at the receiving entity until the time of occurrence of the event within which it may execute actions to minimize/deter the impact of the predicted issues. At any point in this time horizon, the entity performing the actions is free to initiate actions to resolve the predicted CCO issue. However, the point in time at which an action is taken may result in interactions with other existing/ongoing CCO related interventions, or other optimization procedures, or interact with UE mobility differently. The node performing the actions and the node performing the predictions can vastly improve their operation if in addition to learning a CCO action in relation to a predicted CCO issue, it can also learn the time at which a certain intervention should be triggered depending on parameters such as the neighbor configuration, AI/ML model, predicted CCO issue, planned action, etc.

Aspects related to timing of detection and/or resolution of a predicted CCO issue may also be considered. This may be captured as intra-RAN node signaling and/or inter-RAN node signaling.

For example: in a first gNB 260, the gNB-CU predicts a CCO issue and indicates to a controlled gNB-DU 280 a reference time in the future indicating when the CCO issue is expected to occur. The gNB-DU 280 replies to the gNB-CU with an indication, saying that a corresponding coverage modification can be applied (or alternatively, that it will be applied starting from certain time in the future).

In one embodiment of this method, the gNB-DU 280 informs the gNB-CU of the CCO configuration that will be adopted to prevent and/or resolve the predicted issue. The gNB-CU uses this information to inform another gNB-DU 280 (of the same gNB 260) or another gNB-CU (of another gNB) that a predicted CCO issue is being addressed (or will be addressed starting from a certain time in the future). Additionally, the gNB-CU may inform such other gNB-DU 280 and/or gNB-CU of the actions that the first gNB-DU 280 declared to take to prevent/resolve the predicted issue. This approach presents the advantage that, if any of the other gNB-DU 280 or the other gNB-CU determine that the same issue will occur or is occurring, they would not need to react to it with actions that prevent or resolve the issue because they have been informed that the issue has been addressed by the first gNB-CU and gNB-DU 280. Instead, the other gNB-DU 280 and gNB-CU may take actions aimed at coordinating their cells configurations with the CCO actions the first gNB-DU 280 decided to take to prevent/resolve the predicted CCO issue.

Two successive predicted CCO issues may (or may not) be resolved if the time period between when a certain CCO issue is predicted to occur and when a subsequent CCO issue is predicted to occur is too short (e.g. “CCO issue 1 ” is predicted at time T1 , “CCO issue 2” is predicted at time T2, and (T2-T1) is very short. To consider this, a gNB-DU 280 can inform the gNB-CU of a reference time in the future at which it will be able to provide a coverage modification corresponding to a predicted CCO issue detected by the gNB-CU. Namely, a time needed at the gNB-DU 280 to derive a CCO configuration upon reception of a predicted CCO issue. By providing this information the gNB-CU is able to deduce that any predicted CCO issue issued within a time window shorter than the time the gNB-DU 280 is able to generate a CCO configuration should not be signaled to the gNB-DU 280 as this would result in the gNB-DU 280 potentially never converging to a stable selection of a CCO action.

Another option is that the gNB-DU 280 informs the gNB-CU of a reference time in the future until which no predicted CCO issue will be considered by the gNB-DU 280. Or, the gNB- DU 280 can inform the gNB-CU of a reference time in the future from which it will be able to provide a coverage modification associated to a predicted CCO issue.

It is also of note that a certain predicted CCO issue detection may no longer be valid after some time. Therefore, a gNB-CU can send a gNB-DU 280 subsequent/refined predicted CCO detection, or inform the gNB-DU 280 that a previously predicted CCO issue is no longer valid.

A gNB-DU 280 might not be able to perform a coverage modification to resolve a predicted CCO issue in due time, due to other ongoing actions (conflict).

A gNB-DU 280 may inform the gNB-CU that by applying a certain coverage modification to resolve a predicted CCO issue this will impact the available capacity for a certain network slice. A coverage modification to resolve a predicted CCO issue that is no longer valid may either be reverted, or a new coverage modification may be chosen based on existing/predicted CCO issues.

In a different embodiment, the predicted CCO issue may be signaled by the gNB-CU to the gNB-DU 280 together with certain conditions that need to occur for the prediction to be valid. As an example, the gNB-CU may signal to the gNB-DU 280 a prediction that an issue of cell edge interference will occur between Cell A and Cell B, if the overall power detected over the frequency bands on which Cell A and/or Cell B operate reaches levels above a given threshold. The gNB-DU 280 can therefore monitor the power of signals over Cell A and/or Cell B and determine if such metric is above or below the threshold indicated by the gNB-CU. Consequently, the gNB-DU 280 will know if the prediction issued b y the gNB-CU is valid or not.

Another example of such conditions could be that a given CCO issue prediction is valid if a certain number of UEs move to a specific cell of the gNB-DU 280 (this includes UEs moving to the cell via RRC Connected Handover procedures, or if a certain number of UEs move into RRC Connected within a specific cell of the gNB-DU 280.

Further, in any of the embodiments here, a RAN node 120 (e.g. a gNB-DU 280) can be instructed to provide feedback on the basis of configuration parameters received by another node.

FIG. 6 is a signaling diagram illustrating an example message flow according to one or more embodiments of the present disclosure. In this example, the first RAN node 120a may be a gNB-CU and the second RAN node 120b may be a gNB-DU 280. According to this example, The gNB-CU transmits, to the gNB-DU 280, a CCO issue notification message 510. The CCO configuration message indicates a predicted CCO issue with a coverage area (e.g., one or more cells and/or SSB beams) served by the second RAN node 120b. The CCO configuration message may further comprise one or more optional parameters as will be described in greater detail below. The parameters may include, e.g., an identifier for the predicted CCO issue, a reference time within which (or at which) the predicted CCO issue is expected, the cells and SSB beams that are affected by the predicted issue, among others. This initial set of one or more parameters (e.g., Information Elements (IEs)) may describe core information about the CCO issue to the second RAN node 120b and may be extended with one or more enhancements that may indicate the way in which the CCO issue has to be handled, when an intervention may be triggered, the metrics that are to be used as feedback the suggested type/method of intervention, etc.

The second RAN node 120b may accept or reject the CCO issue in a CCO issue acknowledgement message 520. The second RAN node 120b may then send a CCO feedback message 530 to carry the feedback from the second RAN node 120b to the first RAN node 120a. The first RAN node 120a may send a CCO intervention settings message 540 to the second RAN node 120b indicating one or more settings the node should use when handling a predicted CCO issue in the future.

FIG. 7 is a signaling diagram illustrating another example message flow according to one or more embodiments of the present disclosure. As before, the first RAN node 120a may be a gNB-CU and the second RAN node 120b may be a gNB-DU. The gNB-CU transmits a first CCO issue notification message 510a to the gNB-DU. As noted above, the CCO issue notification message 510a indicates a predicted CCO issue with a coverage area 130 served by the second RAN node 120b. The gNB-DU 280 receives and accepts the predicted CCO issue and sends a CCO issue acknowledgement message 520 in response. Before the second RAN node 120b modifies coverage based on the predicted CCO issue (after time T in FIG. 7), the gNB-CU 295a sends a second CCO issue notification message 510b to the gNB-DU 280. The second CCO issue notification message 510b comprises a refinement of the predicted CCO issue. The gNB-DU 280 modifies coverage according to the refined predicted CCO configuration and sends a coverage modification message 550 to notify the gNB-CU that coverage has been modified. The gNB-DU 280 collects feedback under the modified coverage and sends coverage feedback to the gNB-CU in a CCO feedback message 530.

FIG. 8 is a signaling diagram illustrating another example message flow according to one or more embodiments of the present disclosure. As before, the first RAN node 120a may be a gNB-CU and the second RAN node 120b may be a gNB-DU 280. In this example, the gNB-DU 280 sends a CCO issue request message 560 to the gNB-CU. The CCO configuration request message requests that the gNB-CU provide a CCO issue prediction relating to the coverage area 130 served by the gNB-DU 280. The gNB-CU sends a CCO issue request acknowledgement message 570 that acknowledges the request. The gNB-CU predicts a CCO issue and indicates the predicted CCO issue in a CCO issue notification message 510a. The gNB-DU 280 notifies the gNB-CU that the predicted CCO configuration has been accepted using a CCO issue acknowledgement message 520. Before the second RAN node 120b modifies coverage based on the predicted CCO issue (after time T in FIG. 8), the gNB-CU sends a second CCO issue notification message 510b to the gNB-DU 280. The second CCO issue notification message 510b comprises a refinement of the predicted CCO issue. The gNB- DU 280 modifies coverage according to the refined predicted CCO configuration and sends a coverage modification message 550 to notify the gNB-CU of that coverage has been modified. The gNB-DU 280 collects feedback under the modified coverage and sends coverage feedback to the gNB-CU in a CCO feedback message 530.

For purposes of explaining various scenarios and uses of messages that may be exchanged between RAN nodes 120, the examples of FIGS. 6-8 were discussed in terms of a gNB-CU and gNB-DU communicating with each other. That said, embodiments are not limited to these particular nodes. As noted above, any of the nodes in the RAN 150 may communicate with any other using the signaling described above, provided that such communication comports with the intended purposes of the messages described herein, as will be explained in greater detail below.

FIG. 9 illustrates an example that involves not only intra-gNB communication, but also Inter-gNB communication. In this regard, the example of FIG. 9 includes a first gNB 260a and a second gNB 260b. The first gNB 260a comprises a first gNB-CU 295a and a first gNB-DU 280a. The second gNB 260b comprises a second gNB-CU 295b and a second gNB-DU 280b. Consistent with the examples above, the gNB-CU 295a may be considered a first RAN node 120a, the gNB-DU 280a may be considered a second RAN node 120b, gNB-CU 295b may be considered a third RAN node, and gNB-DU 280b may be considered a fourth RAN node.

In the example of FIG. 9, the first gNB-CU 295a sends a predicted CCO issue to the first gNB-DU 280a (e.g., via the F1AP interface) in a first CCO issue notification message 510a. As discussed above, the gNB-DU 280a may respond with a CCO configuration acknowledgment message 520.

The predicted CCO configuration is also sent to the second gNB-CU 295b (e.g., via the XnAP interface) in a second CCO issue notification message 510b. The second gNB-CU 295b sends the predicted CCO issue to the second gNB-DU 280b using a third CCO issue notification message 510c. The first gNB-DU 280a sends a first coverage modification message 550a to notify its controlling gNB-CU 295a of that coverage of coverage area 130a served by the gNB- DU 280a has been made. The first gNB-CU 295a may correspondingly send a second coverage modification message 550b to notify the second gNB-CU 295b that the coverage area 130a served by gNB-DU 280a has been modified.

The second gNB-DU 280b sends a third coverage modification message 530c to notify its controlling gNB-CU 295a of that coverage of coverage area 130b served by the gNB-DU 280b has been made. The gNB-DUs 280a, 280b inform their respective controlling gNB-CUs 295a, 295b of the feedback associated with their respective coverage areas 130a, 130b using respective CCO feedback messages 530a, 530b.

In view of the examples above, the first RAN node 120a transmits a first message (e.g., a CCO issue notification message 510) to a second RAN node 120b (e.g., a gNB-DU 280), that may indicate to the second network node:

• a predicted CCO issue;

• a reference time in the future for the occurrence of the CCO issue;

• an indication of the predicted affected cells/SSB beams due to the CCO issue.

The first message also optionally comprises one or more elements that provide indication on how the predicted CCO issue should be handled by the second network node. The different indications may include:

• an identity associated with the predicted CCO issue that shall/can be used in future messages in the context of the predicted CCO issue; • to treat the predicted CCO issue the same way as non-predicted (i.e., detected) CCO issue indications;

• to treat the predicted CCO issue using the default settings for handling CCO predictions (in this case, the default settings refer to a processing and decision pipeline where further nuances, such as validating the prediction, may not be considered);

• to treat/handle the predicted CCO issue where interventions are performed at an indicated time that is just ahead of the reference time at which the issue is predicted to occur;

• to treat/handle the predicted CCO issue where interventions are performed only after the time at which CCO issues are predicted to manifest (e.g., the reference time at which the issue is predicted to occur);

• to treat/handle the predicted CCO issue where interventions are performed only after the occurrence of the issue has been detected by the first or the second node. Depending on the location of the detection function there may be additional signaling to initiate interventions in the context of a previously indicated CCO issue. The predicting node may suggest metrics that should be measured by the node that performs the intervention and indicate additional thresholds to indicate fulfilment of a CCO issue. Such metrics could be one or more of the following: o UE measurements/reports taken from UEs served by cells and/or beams affected by the predicted CCO issue, such as RSRP, RSRQ, SINR measurements, revealing whether a CCO issue occurred, reports containing information concerning to failure events or sub-optimal mobility events, such as the RLF Report, the Successful HO Report, the RA Report, the CEF report. o Performance measurements taken by the node serving the UEs in cells and/or beams affected by the predicted CCO issue, revealing whether any CCO issue occurred. Such measurements may consist of per UE .

• In certain scenarios, the occurrence of the CCO issue may manifest before or after the reference time at which the CCO issue is predicted to manifest. Another indication may indicate to the node if any interventions shall be performed if the detection is before or at the reference time at which the CCO issue is predicted to manifest.

• To treat/handle the predicted CCO issue where interventions are performed only after measurements performed by the second network node indicate that the occurrence of the issue is imminent. • To treat/handle the predicted CCO issue where interventions are performed only after a certain time has elapsed after the predicted occurrence of the CCO issue.

• To treat/handle the predicted CCO issue where interventions are performed only after a certain time has elapsed after detection of the CCO issue.

• To treat/handle the CCO issue where interventions taken by the current node and the neighbor node are enabled and disabled with a certain periodicity. In this case, the neighbor nodes that are affected by the intervention action corresponding to a certain CCO issue (either predicted or ongoing), i.e. , two or more nodes who modified their cells/beams coverage state, will turn this on and off in a coordinated fashion to observe the problem/performance in both the neighbor cells.

• To revert a predicted CCO issue, e.g., indicating that a previously indicated prediction concerning a CCO issue is no longer valid (or is no longer accurate, or its uncertainty is higher than a threshold, or its accuracy is lower than a threshold)

• To update the reference time in the future at which the predicted CCO issue expected to occur.

• To treat/handle the predicted CCO issue only if no other actions are performed or initiated or planned to be initiated which would modify the coverage of cells and/or SSB beams before the reference time at which the issue is predicted to occur

• To prioritize the handling of predicted CCO issue over other actions planned to be initiated which would modify the coverage of cells and/or SSB beams (e.g., prioritize the resolution of a predicted CCO issue compared to an action caused by Network Energy Saving)

Further, a first RAN node 120a (e.g., a gNB-CU 295) may obtain (or derive) a predicted CCO issue affecting one or more cells and/or SSB beams served by the first RAN node 120a and/or cells and/or SSB beams served by another RAN node 120b (e.g., another gNB-CU 295, or another gNB 260). The occurrence of a predicted CCO issue can be detected by the same gNB-CU controlling the gNB-DU or another gNB-CU and similarly the prediction of the CCO issue may be performed by the same gNB-CU controlling the gNB-DU or another gNB-CU.

As noted above, the first message transmitted to a second RAN node may indicate at least one predicted CCO issue. The first message may additionally comprises one or more of the following elements:

• One or more indications or requests concerning the timing of a predicted CCO issue;

• One or more indications or requests concerning the impact of a predicted CCO issue; • One or more indications or requests concerning conditions associated to a predicted CCO issue;

• One or more identities associated with a predicted CCO issue, such as cell identities or beam identities for cells/beams affected by the issue;

• One or more configuration parameters for proving feedback associated to a predicted CCO issue;

The second network node (e.g., a gNB-DU) transmits a second message (e.g., a CCO issue notification message 510, a CCO issue acknowledgement message 520) to a first network node (e.g., a gNB-CU) comprising one or more of the following:

• One or more indications or requests concerning the timing of a predicted CCO issue

• One or more indications or requests concerning the impact of a predicted CCO issue

• One or more indications or requests concerning conditions associated to a predicted CCO issue

• One or more identities associated with a predicted CCO issue

• A CCO configuration involving the one or more cell/beam impacted by the predicted CCO issue or cells/beams not explicitly associated to the issue. Additionally, timing information about when such CCO configuration will be adopted may be included.

As just described, both a first message and a second message can comprise one or more of the following types of information:

• One or more indications or requests concerning the impact of a predicted CCO issue;

• One or more indications or requests concerning conditions associated to a predicted CCO issue.

The above indications, requests and configuration parameters can be different depending on which entity/function is the sender (and therefore which entity/function is the receiver). How they differ when they are included in one or the other message is described further below.

In general, any indication, request and configuration parameters described below may relate to the detection of a predicted CCO issue and/or to the resolution of a predicted CCO issue, and/or to the inaction or failure of a predicted CCO issue.

In one embodiment, the first RAN node 120a transmits to a second network node 120b a subsequent first message (e.g., a further CCO issue notification message 510) comprising a refined prediction of a previously predicted CCO issue. In one embodiment, the second network node sends to the first network node a third message (e.g., a coverage modification message 550) to indicate/notify a coverage modification executed (or a planned coverage modification) in response to a received predicted CCO issue or a refinement thereof.

In one embodiment, the second network node returns to the first network node a failure in treating/handling of a predicted CCO issue when another action which would modify the coverage of cells and/or SSB beams is undergoing or is planned to be executed - optionally before the reference time at which the issue is predicted to occur if specified.

In one embodiment, the second RAN node 120b (e.g., a gNB-DU 280), based on parameters received from the first network node in a first message, related to the collection of feedback for a certain predicted CCO issue, sends to the first network node (e.g., a gNB-CU) a fourth message (e.g., a CCO feedback message 530) with feedback for the received predicted CCO issue or a refinement thereof.

In one embodiment, the second network node (e.g., a gNB-DU 280) is implicitly requested by the first network node to collect feedback on a predicted CCO issue. Upon executing a coverage modification to address a received predicted CCO issue, the second network initiates collection of feedback and terminates the collection at expiration of a timer initialized when the coverage modification is performed. The second network node sends the feedback to the first network node in a fourth message.

In one embodiment, the second network node (e.g., a gNB-DU) is implicitly requested by the first network node to collect feedback on a predicted CCO issue. Upon receiving a predicted CCO issue, the second network initiates to collect feedback and provides it to the first network node in a fourth message:

• upon receiving a refinement of a previously received predicted CCO issue; or

• periodically; or

• when the coverage modification addressing the received predicted CCO issue is applied; or

• when initiating an action which has a further impact on coverage, e.g., a reduction or an increase in power for a reference signal, or when a cell is (re)activated, or when a cell is deactivated

Of the various embodiments discussed above, distinct groups of solutions exist. These solutions include:

• Solutions which do not distinguish between a predicted CCO issue and an ongoing CCO issue.

• Solutions which initiate interventions just ahead of a reference time corresponding to a predicted CCO issue.

• Solutions which initiate interventions just after a reference time corresponding to a predicted CCO issue. • Solutions which initiate interventions only after confirming the occurrence of the CCO issue is imminent.

• Solutions which initiate interventions only after confirming the occurrence of the CCO issue is ongoing.

• Solutions which initiate and stop interventions periodically across neighboring nodes.

• Solutions which initiate and/or stop intervention on the basis of updated predicted CCO issue

• Solutions which stops intervention on the basis of indication to invalidate a previously received predicted CCO issue

• Solutions which starts intervention on the basis of indication to validate a previously received predicted CCO issue

The extent to which a CCO prediction can be validated may depend on which solution/indication the prediction maps to.

Solutions which initiate CCO interventions just after the reference time or just after confirmation that the CCO issue is ongoing have access to the information if the CCO issue was observed in the network and any additional information detailing the occurrence of the event and its relation to the predicted CCO event. In some such embodiments, the RAN node 120 issuing the CCO issue prediction may request that the RAN nodes 120 serving the cells/beams involved in the CCO issue, and optionally the RAN nodes not affected by the CCO issue but neighboring such nodes, signal back UE measurements taken from UEs 110 selected according to one or more criteria below:

• UEs that are served by cells/beams affected by the CCO issue predicted

• UEs in neighbor cells/beams of the cells/beams affected by the CCO issue predicted

• UEs at cell edge of one or more cell/beam affected by the predicted CCO issue Measurements collected from such UEs reveal whether coverage, capacity or interference issues were monitored by the UE. Therefore, such measurements may for example consist of RSRP, RSRQ, SINR. At the same time UE performance metrics may be reported to from the node requested to provide measurements to the node requesting such measurements, such as UL/DL UE throughput, UL/DL packet error rate, UL/DL packet delay, UL/DL packet delay jitter.

Solutions which initiate CCO interventions just ahead of the reference time or as soon as imminent occurrence of the CCO issue is expected may not be able to indicate to the other network node if the CCO issue predicted by the first network node materialized (or started to materialize) at the time of the intervention. However, the RAN node issuing the CCO issue prediction may requests to the RAN nodes serving the cells/beams involved in the CCO issue, and optionally the RAN nodes not affected by the CCO issue but neighbouring such nodes, to signal back an indication stating whether the CCO issue materialized or not (e.g., by echoing the issue and/or indicating a list of affected cells and/or beams), i.e., during the intervention, and this may be used to evaluate if a chosen CCO action or a predicted CCO issue was performed correctly. Alternatively, the RAN node issuing the CCO issue prediction may requests to the RAN nodes serving the cells/beams involved in the CCO issue, and optionally the RAN nodes not affected by the CCO issue but neighbouring such nodes, to signal back UE measurements following the description above. Such measurements may be used to extrapolate whether the predicted CCO issue may have occurred.

In any of the above possibilities where the network node enacting CCO interventions, e.g., a gNB-DU, has the ability to detect the occurrence/manifestation of CCO problems (regardless of it being during the predicted occurrence of the CCO issue or after the predicted occurrence of the CCO issue), this information about the time difference between the prediction and actual occurrence of the CCO issue may be signaled to the network node that predicted the occurrence of CCO event together with other information, such as metrics used to detect the CCO issue together with corresponding values, an indication of the effect of the mismatch between the prediction and the actual event, and other data that may be useful to correlate with, such as data volumes, reported signal strength, number of UEs, etc.

The category where the two or more RAN nodes 120 affected by a predicted CCO issue enable and disable their interventions either after detection of the issue or after the predicted time of the CCO issue has passed perhaps offers the best possibility to introspect how the CCO issue manifests and continues in the network. The aforementioned coordination, at the same time, is expensive in terms of the number of UE mobility events that the network has to cope with, however the information learnt could be used to explore the extent to which interventions have an effect on the predicted CCO issues and how the issues and the interventions are correlated with the predictions.

However, when the two RAN nodes 120 coordinate on a mechanism to enable and disable the CCO interventions at the same time, depending on the number of UEs in the affected coverage area, the action may trigger back-and-forth movement of UEs from one node to another. Such additional load on the network, its impact on the Key Performance Indicators (KPIs) needs to be evaluated before such actions are undertaken.

When it comes to performing an intervention where coverage states of cells belonging to two or more nodes are changed, the time at which the above change is performed can be crucial to both the network-level KPIs and the effect that the change of cell coverage state has on the predicted CCO issue.

A node receiving a CCO prediction, in theory, has the entire time span until when the event is predicted to occur to take actions to avoid the issue. In practice though, it may be the case that actions have to be initiated at least a certain amount of time ahead of the predicted CCO issue to ensure that any of the transient issues resulting from a change in coverage state of two neighboring nodes does not affect the intervention to the predicted CCO issue.

As means to tackle the above issue, the node indicating the predicted CCO issue may also indicate the time before which any intervention has to be taken by the receiving node. While this may simply be set as an offset time before the occurrence of a CCO issue, the offset may not satisfactorily work in all scenarios.

The node performing the prediction may together with each predicted CCO indication continually attempt to alter the time at which the receiving node may intervene with actions to the predicted CCO issue. This indication may be used either independently or together with other indications on how a predicted CCO issue should be handled. The intervention time may be learnt by a AI/ML algorithm which evaluates the minimum time required for a certain intervention to perform certain actions before a predicted CCO issue.

Furthermore, depending on when the second network node initiated the intervention, it may optionally indicate to the first node the offset between the time at which an intervention was triggered relative to the predicted occurrence of the CCO issue, and potentially other information such as when the CCO issue was detected/measured to have occurred in the real network.

This feedback on the timing information may be collected at the first network node and may then be analyzed to arrive at a time before the occurrence of a CCO prediction that interventions must be triggered. This value may be customized depending on the detected issue, number of UE affected by the issue, first/second network nodes and their properties, and other parameters.

Indications or requests concerning the timing of a predicted CCO issue may include:

• The “sending network node’’ is the network node sending a predicted CCO issue.

• The “receiving network node” is the node receiving a predicted CCO issue.

When indications or requests concerning the timing of a predicted CCO issue are transmitted by the network node sending a predicted CCO issue (e.g., a gNB-CU, or a first RAN node), towards the network node receiving the predicted CCO issue (e.g., a gNB-DU, or a second RAN node) they can be one or more of the following:

• an indication of a time in the future to which the predicted CCO issue refers to (e.g., an indication of a reference time for predicted CCO issue detection).

• a request to receive an indication of a reference time in the future until when no predicted CCO issue will be considered by the receiving network node

• an indication of a time in the future at which the sending network node expects/wishes that the receiving network node will provide (or may provide) a coverage modification associated to the predicted CCO issue (e.g., an indication of an expected reference time for predicted CCO issue resolution).

• a request to receive from the receiving network node an indication of a time in the future (e.g., a reference time for predicted CCO issue resolution) from which the receiving network node will be capable to (or may be able to) provide a coverage modification associated to a predicted CCO issue (e.g., a request of a reference time for predicted CCO issue resolution). Alternatively, a request to receive an indication of a time before which the receiving network node will not be able to provide a coverage modification associated to a predicted CCO issue.

• an indication of a time in the future within which the sending network node expects to receive from the receiving network node a coverage modification associated to a predicted CCO issue (e.g., an indication of an expected reference end time period for a predicted CCO issue resolution).

• a request to receive from the receiving network node a time in the future within which the receiving network node is capable of (or may be able to) provide a coverage modification associated to the predicted CCO issue (e.g., a request of a reference end time for a predicted CCO issue resolution).

• a reference time in the future from which it is expected that a cell served by the receiving network node will assume a certain coverage (e.g., a coverage state) corresponding to a predicted CCO issue.

• a reference time in the future from which an SSB served by the receiving network node is expected to assume a certain coverage (e.g., a coverage state) corresponding to a predicted CCO issue

• a reference time in the future from which it is expected that a cell not served by the receiving network node will assume a certain coverage (e.g., a coverage state) corresponding to a predicted CCO issue.

• a reference time in the future from which an SSB not served by the receiving network node is expected to assume a certain coverage (e.g., a coverage state) corresponding to a predicted CCO issue detected by the sending network node.

• an indication of a time duration (predicted start and predicted end time) in which a predicted CCO issue will happen if the receiving network node is unable to provide coverage modifications in relation to the CCO issue.

• a request for reference duration from the receiving network node in which the receiving network node can act upon the above mentioned CCO issue.

• an indication of a predicted periodic CCO issue with a predicted frequency and a predicted start time

• a request for a reference frequency and also a start time that the receiving network node can act upon

• an indication of simultaneously occurring (or quite close in time) predicted CCO issues and a preference of which issue to tackle first

• a request for reference times that the receiving network node can act upon the above mentioned closely occurring CCO issues • an indication of time before which there should be no modification

• a reference time in the future from which a cell or SSB not served by the receiving network node is expected to initiate coverage modification actions in relation to the predicted CCO issue. This reference time may be used to indicate the time from which the receiving network node should initiate its actions and/or the indicates the time of occurrence of the CCO issue indicated by the sending network node.

• an indication of a time in future at which a predicted or an ongoing CCO issue is predicted to be no longer valid

• an indication of conditions upon the occurrence of which a given CCO issue prediction becomes valid. Examples of conditions could be mobility events, radio signal measurements being above/below a given threshold.

When “indications or requests concerning the timing of a predicted CCO issue” are transmitted by the network node receiving a predicted CCO issue (e.g., a gNB-DU, or a second RAN node), towards the network node sending the predicted CCO issue (e.g., a gNB-CU, or a first RAN node) they can be one or more of the following:

• an indication of a reference time in the future until when no predicted CCO issue will be considered by the receiving network node

• an indication of a time in the future at which the receiving network node will provide (or may provide) a coverage modification associated to the predicted CCO issue (e.g., an indication of an expected reference time for a predicted CCO issue resolution).

• an indication of a time in the future (e.g., an estimated time in the future) from which the receiving network node will be capable of providing (or may be able to provide) a coverage modification associated to a predicted CCO issue (e.g., an indication of an estimated reference start time for a predicted CCO issue resolution). Alternatively, an indication of a time before which the receiving network node will not be able to provide a coverage modification associated to a predicted CCO issue.

• an indication of a time in the future within which the receiving network node can provide (or may provide, or will be able to provide) a coverage modification associated to a predicted CCO issue (e.g., an indication of a reference end time for a predicted CCO issue resolution).

• a reference time in the future from which a cell served by the receiving network node may/can/will assume a certain coverage (e.g., a coverage state) corresponding to a predicted CCO issue. • a reference time in the future from which an SSB served by the receiving network node may/can/will assume a certain coverage (e.g., a coverage state) corresponding to a predicted CCO issue

• an indication of a reference time in the future from which a certain coverage (e.g., a coverage state) for a cell not served by the receiving network node is acceptable.

• an indication of a reference time in the future from which a certain coverage (e.g., a coverage state) for a SSB not served by the receiving network node is acceptable.

• an indication to the sending network node that further modification/coordination of actions related to a cell/SSB served by the neighbor receiving network node may be required.

• an indication to the sending network node that the chosen action or a candidate planned action in relation to a predicted CCO issue is either ideal given the current network conditions or can further be improved if the neighbor receiving network node serving the neighbor cell/SSB can initiate further modifications to its action to the predicted CCO issue.

• an indication to the sending network node in relation to a previously initiated CCO action that is affected by a new predicted CCO issue. The receiving network node may indicate that the time duration for which an earlier action remains active is either decreased or increased.

Indications or requests concerning the impact of a predicted CCO issue may include:

• the “sending network node” is the network node sending a predicted CCO issue.

When indications or requests concerning the impact of a predicted CCO issue are transmitted by the network node sending a predicted CCO issue (e.g., a gNB-CU, or a first RAN node), towards the network node receiving the predicted CCO issue (e.g., a gNB-DU, or a second RAN node) they can be one or more of the following:

• an indication of whether a predicted CCO issue is a refinement of a previously sent predicted CCO issue

• an indication that a previously indicated predicted CCO issue is not valid anymore

• a request to receive from the receiving network node an indication of cells predicted to be affected by a predicted CCO issue for which the receiving network node can provide a coverage modification.

• a request to receive from the receiving network node an indication of SSBs predicted to be affected by a predicted CCO issue for which the receiving network node can provide a coverage modification. • an indication of refined predicted CCO issue detection, i.e., an update to a previously communicated predicted CCO issue.

• an indication that a predicted CCO issue is a refinement of a previously predicted CCO issue.

• a certain suggested/recommended/preferred candidate coverage (e.g., a coverage state) for a cell served by the receiving network node, corresponding to a predicted CCO issue.

• a certain suggested/recommended/preferred candidate coverage (e.g., a coverage state) for an SSB served by the receiving network node corresponding to a predicted CCO issue.

• a certain expected coverage (e.g., a coverage state) for a cell not served by the receiving network node corresponding to a predicted CCO issue.

• a certain expected coverage (e.g., a coverage state) for an SSB not served by the receiving network node corresponding to a predicted CCO issue

• a request to receive from the receiving network node the cells/SSB beams predicted to be affected by the predicted CCO issue and the predicted times when all (or each) the predicted cells/SSB beam will be affected

• an indication of the suggested coverage for each affected cell as well as the duration for this

• an indication of different suggested coverage combinations for the affected cells and also indication of the order of preference for the different combinations

• an indication of other concurrent CCO predictions that may have an impact on the CCO problem in context, the different suggested/recommended/preferred candidate coverage for a cell or a SSB served by the receiving network node and indication of potentially conflicting CCO predictions.

• an indication of the extent of, or a prediction of the extent of / share of affected traffic in the cell causing the CCO problem. The extent of the CCO problem can be expressed by parameters characterizing the traffic in the cell/SSB beam, the percentage (or percentile) of affected users, the number of affected users, etc.

• a characterization of the traffic affected by the predicted CCO problem, in terms of DRB IDs, 5QI, user subscription, etc

• an indication to the receiving network node about actions to be performed after the CCO issue is considered invalid, e.g., revert actions, take new actions.

• an indication that a subsequent predicted CCO issue may conflict with an earlier CCO issue for which coverage modification actions may currently be underway or is expected to be underway during the subsequent prediction. • an indication associated with an earlier predicted CCO issue, which is currently on-going, where the sending network node may indicate the extent to which the CCO issue is resolved, and/or indicate the need for further actions.

• an indication together with the different possible coverage states (optionally together with the probability) that a certain coverage state will be chosen for a predicted CCO issue for a cell not served by the receiving network node which may be used to break ties, or avoid conflicts between two neighbor cells, e.g., in terms of different operation goals, i.e., energy saving, performance.

When indications or requests concerning the impact of a predicted CCO issue are transmitted by the network node receiving a predicted CCO issue (e.g., a gNB-DU, or a second RAN node), towards the network node sending the predicted CCO issue (e.g., a gNB-CU, or a first RAN node) they can be one or more of the following:

• a request to receive predicted CCO issue(s)

• a request to receive a refinement of a previously receive predicted CCO issue

• a request to receive a notification when a previously received predicted CCO issue become not valid anymore

• an indication, notifying the sending network node whether the receiving network node is able to resolve a certain predicted CCO issue

• an indication that a predicted CCO issue detection affecting cells and/or beams served by the receiving network node can be handled/cannot be handled

• an indication that a predicted CCO issue detection affecting cells and/or beams not served by the receiving network node is acceptable/not acceptable

• an indication of cells predicted to be affected by a predicted CCO issue for which the receiving network node can provide a coverage modification.

• an indication of SSBs predicted to be affected by a predicted CCO issue for which the receiving network node can provide a coverage modification.

• a request to receive refined predicted CCO issue detection if/when available.

• an indication of whether (or not) a certain coverage (e.g., a coverage state) for a cell served by the receiving network node (e.g., as suggested/recommended/preferred/expected by the sending network node) is accepted / acceptable.

• an indication of whether (or not) a certain coverage (e.g., a coverage state) for an SSB served by the receiving network node (e.g., as suggested/recommended/preferred/expected by the sending network node) is accepted / acceptable.

• an indication on whether (or not) a certain expected coverage (e.g., a coverage state) for a cell not served by the receiving network node is accepted I acceptable. • an indication on whether (or not) a certain expected coverage (e.g., a coverage state) for an SSB not served by the receiving network node is accepted / acceptable.

• an indication on whether a certain change in coverage state for an SSB or a cell served by the receiving network node may impact other previously performed CCO actions.

• an indication on the lifetime of a chosen coverage state and subsequent planned actions after the expiration of a coverage modification

• an indication if a coverage state chosen for a predicted CCO issue for a cell not served by the receiving network node is accepted or not.

• an indication to notify the sending network node that futher actions are possible for a previously detected CCO issue if the identified resolution is not effective.

• a request to provide an indication together with the different possible coverage states (optionally with the probability) that a certain coverage state will be chosen for a predicted CCO issue for a cell not served by the receiving network node which may be used to break ties, or avoid conflicts between two neighbor cells, e.g., in terms of different operation goals, i.e., energy saving, performance.

Indications or requests concerning conditions associated to a predicted CCO issue may include:

When indications or requests concerning conditions associated to a predicted CCO issue are transmitted by the network node sending a predicted CCO issue (e.g., a gNB-CU, or a first RAN node), towards the network node receiving the predicted CCO issue (e.g., a gNB-DU, or a second RAN node) they can be one or more of the following:

• a request to send an indication to the sending network node if/when the receiving network node is able (or not able) to resolve a certain predicted CCO issue

• an indication to inform the receiving network node that a predicted CCO issue is confirmed, or the predicted CCO issue should be discarded (is no longer valid)

• a request to receive from the receiving network node an indication of whether (or not) the receiving network node accepts or rejects a predicted CCO issue. This may optionally include whether (or not) the receiving network node accepts or rejects a specific predicted CCO issue (i.e., the acceptance or the reject is per predicted CCO issue).

• an indication of an estimated probability for a predicted CCO issue. This may optionally include an estimated probability to affect a certain cell/SSB.

• the cell/SSB served by the sending network node / receiving network node or another network node. • an indication of an accuracy for a predicted CCO issue. This may optionally be per affected cell and/or SSB.

• the cell/SSB served by the sending network node I receiving network node or another network node.

• a request to receive from the receiving network node an indication (e.g., a notification) if/when an action to be performed by (or being performed by) the receiving network node prevents to resolve a certain predicted CCO issue

• a request to receive from the receiving network node an indication (e.g., a notification) if/when the resolution of a certain predicted CCO issue cannot/will not be achieved due to a conflict (e.g., another action is ongoing)

• a request to receive an indication on whether (or not) the resolution of a predicted CCO issue will impact certain per-network slice available capacity. This may optionally include a degree of impact, or a likelihood of the impact

• an indication to the different simultaneously occurring/predicted CCO issues and their associated priorities.

• a request to receive from receiving network node the chosen CCO issue to tackle first in case of simultaneously occurring issues

• a request to receive from receiving network node the chosen coverage combination for the affected cells

• an indication of the impact of the predicted CCO issue, e.g., in relation to a number of impacted UEs, capacity or load impacts in relation to slices/per SSB/per cell impact.

• An indication of conditions that need to occur for a CCO issue prediction to be valid. As an example, the gNB-CU may signal to the gNB-DU a prediction that an issue of cell edge interference will occur between Cell A and Cell B, if the overall power detected over the frequency bands on which Cell A and/or Cell B operate reaches levels above a given threshold. Another example of such conditions could be that a given CCO issue prediction is valid if a certain number of UEs move to a specific cell of the gNB-DU (this includes UEs moving to the cell via RRC_Connected Handover procedures, or if a certain number of UEs move into RRC_Connected within a specific cell of the gNB-DU

When indications or requests concerning conditions associated to a predicted CCO issue are transmitted by the network node receiving a predicted CCO issue (e.g., a gNB-DU, or a second RAN node), towards the network node sending the predicted CCO issue (e.g., a gNB- CU, or a first RAN node) they can be one or more of the following:

• an indication of whether (or not) the receiving network node accepts or rejects a predicted CCO issue. This may optionally include whether (or not) the receiving network node accepts or rejects a specific predicted CCO issue (i.e., the acceptance or the reject is per predicted CCO issue).

• a request to be informed by the sending network node if/when a predicted CCO issue is confirmed, or the predicted CCO issue should be discarded (is no longer valid)

• an indication (e.g., a notification to the sending network node) that the receiving network node is able (or not able) to resolve a certain predicted CCO issue

• an indication of a threshold value indicating a level of uncertainty. With this the receiving network node indicates to the sending network node that it wants (or can accept) a predicted CCO issue if the associated uncertainty is higher than (or higher than or equal to) the threshold (or not lower than, or not lower than or equal to the threshold). This may optionally be per cell and/or per SSB and/or the cells/SSB being served by the sending network node / receiving network node or another network node

• a request of an accuracy for a predicted CCO issue, which may optionally be per cell and/or per SSB and/or the cells/SSB being served by the sending network node I receiving network node or another network node

• an indication that an action to be performed by (or being performed by) the receiving network node prevents to resolve a certain predicted CCO issue

• an indication that the resolution of a certain predicted CCO issue cannot/will not be achieved due to a conflict (e.g., with another action)

• an indication on whether (or not) the resolution of a predicted CCO issue will impact certain per-network slice available capacity. This may optionally include a degree of impact, or a likelihood of the impact

• a request to receive an impact of the predicted CCO issue, e.g., a number of impacted UEs, capacity or load impacts in relation to slices/SSB beams/cell.

Identities associated with a predicted CCO issue can be one or more of the following:

• an identifier of a predicted CCO issue

• an identifier, or a flag, indicating that a predicted CCO issue is refinement of a previously signaled predicted CCO issue

• identifiers of cells served by the receiving network node and predicted to be affected by the predicted CCO issue.

• identifiers of SSBs served by the receiving network node and predicted to be affected by the predicted CCO issue.

• identifiers of cells not served by the receiving network node and predicted to be affected by the predicted CCO issue.

• identifiers of SSBs not served by the receiving network node and predicted to be affected by the predicted CCO issue. • Identifier of priority to act upon simultaneously or nearly occurring CCO issues

• an identifier of a predicted CCO issue detection accepted or rejected by the receiving network node

• identifiers of cells served by the receiving network node and predicted to be affected by the predicted CCO issue for which the receiving network node will be able to provide a coverage modification (or for which the gNB-DU will not able to provide a coverage modification).

• identifiers of SSBs served by the receiving network node and predicted to be affected by the predicted CCO issue for which the receiving network node will be able to provide a coverage modification (or for which the receiving network node will not able to provide a coverage modification).

• an identifier associated with a coverage modification action that may be associated with one or more than one predicted CCO issue

A first network node sending a predicted CCO issue to a second network node can also be interested to receive feedback associated to such prediction. To guide the second network node on how to collect and report such feedback, the first network node can send in a FIRST MESSAGE a number of configuration parameters for proving feedback. These can be:

• a CCO feedback collection time duration, TCCO, during which the second network node is implicitly or explicitly requested to collect data (e.g., feedback), to evaluate one of the following situations:

• whether a predicted CCO issue has occurred, or has started to materialize, or did materialize and was solved by implementing the applied coverage modification, or the predicted CCO issue materialized and was alleviated by implementing the applied coverage modification, or the issue did not materialize and the coverage modification was implemented, or the issue did not materialize and no coverage modification was applied. For example: o the second network node can report a series of values indicating a number of UEs considered as cell-edge UEs (see below); o the second network node can report that the number of UEs at cell edge has increased or decreased after receiving the predicted CCO issue; o the second network node can report that the number of UEs at cell edge has increased or decreased after applying the coverage modification associated to the predicted CCO issue.

• a CCO feedback collection start time, TCCO_START, starting from which the second network node is implicitly or explicitly requested to collect data (e.g., feedback), to evaluate one of the situations indicated above. • a CCO feedback collection end time, TCCO_END, until when the second network node is implicitly or explicitly requested to collect data (e.g., feedback), to evaluate to evaluate one of the situations indicated above.

• an indication to provide a CCO feedback to evaluate one of the situations indicated above, until a further coverage modification for at least one of the cells or at least one of the SSB beams is made

• an indication to provide a CCO feedback to evaluate one of the situations indicated above, until a further predicted CCO configuration is received

Different criteria can be used for determining whether a UE is to be considered as a celledge UE. Non-limiting examples can be: a UE with large Timing Advance (higher than “X”), or a UE for which a measurement report indicates a low value of coverage, for which the Buffer Status Report indicates a large amount of data to be sent, or towards which the scheduled resources are high (e.g., the amount of scheduled PRB is higher than “Y”).

A RAN node 120 may be implemented as schematically illustrated in the example of FIG. 10. The RAN node 120 of FIG. 10 comprises processing circuitry 710, memory circuitry 720, and interface circuitry 730. The processing circuitry 710 is communicatively coupled to the memory circuitry 720 and the interface circuitry 730, e.g., via a bus 704. The processing circuitry 710 may comprise one or more microprocessors, microcontrollers, hardware circuits, discrete logic circuits, hardware registers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or a combination thereof. For example, the processing circuitry 710 may be programmable hardware capable of executing software instructions stored, e.g., as a machine-readable computer program 740 in the memory circuitry 720. The memory circuitry 720 of the various embodiments may comprise any non- transitory machine-readable media known in the art or that may be developed, whether volatile or non-volatile, including but not limited to solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, flash memory, solid state drive, etc.), removable storage devices (e.g., Secure Digital (SD) card, miniSD card, microSD card, memory stick, thumb-drive, USB flash drive, ROM cartridge, Universal Media Disc), fixed drive (e.g., magnetic hard disk drive), or the like, wholly or in any combination.

The interface circuitry 730 may be a controller hub configured to control the input and output (I/O) data paths of the RAN node 120. Such I/O data paths may include data paths for exchanging signals over a network. The interface circuitry 730 may be implemented as a unitary physical component, or as a plurality of physical components that are contiguously or separately arranged, any of which may be communicatively coupled to any other or may communicate with any other via the processing circuitry 710. For example, the interface circuitry 730 may comprise a transmitter 732 configured to send wireless communication signals and a receiver 734 configured to receive wireless communication signals. The RAN node 120 may be configured (e.g., by the processing circuitry 710) to perform the method 300 and/or the method 500 described above. It will be understood that each RAN node 120 of a network 100 may interact dynamically with other RAN nodes 120 in the network 100 to implement one or more improvements described herein.

Still other embodiments include a control program 740 comprising instructions that, when executed on processing circuitry 710 of a RAN node 120, cause the RAN node 120 to carry out the method 300 and/or method 500 described above.

Yet other embodiments include a carrier containing the control program 740. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

FIGS. 11 A-D illustrate a table of a first example of implementation (XnAP) in which a first gNB-CU 295a sends to a second gNB-CU 295b indications that a predicted CCO issue is detected by the first gNB-CU 295a for certain cells. The first gNB-CU 295a indicates an expected reference time in the future starting from which a predicted CCO issue is expected, and a corresponding estimated probability.

The table of FIGS. 11 A-D may correspond to an NG-RAN NODE CONFIGURATION UPDATE message. The message is sent by a NG-RAN node to a neighboring NG-RAN node to transfer updated information for an Xn-C interface instance.

FIGS. 12A-D illustrate a table of a second example of implementation (XnAP) in which a first NG-RAN node sends to a second NG-RAN node indications of predicted cell coverage state(s) and/or indication of predicted SSB coverage state(s) for cells/beams served by the first NG-RAN node. A predicted cell/beam coverage state pertains to the resolution of a predicted CCO issue detected by the first NG-RAN node. The first NG-RAN node can also send an indication indicating a reference point in time in the future to which the predicted cell/beam coverage state(s) refer to (i.e., when such predicted cell/beam coverage state(s) are inferred to be taken in use). The first NG-RAN node can also indicate the cause for a predicted coverage modification (e.g., predicted coverage issue, predicted cell edge capacity issue, etc.).

The tables of FIGS. 12A-D may correspond to a NG-RAN NODE CONFIGURATION UPDATE message. This message may be sent by a NG-RAN node to a neighboring NG-RAN node to transfer updated information for an Xn-C interface instance.

FIG. 13 illustrates a table relating to a third example of implementation (F1AP). According to this example, the implementation of this third example comprises a first step and a second step. In the first step, a gNB-CU indicates to the gNB-DU that a certain type of predicted CCO issue is detected and indicates certain predicted affected cells and/or beams. The gNB-CU can also indicate for how long the predicted CCO issue is expected to last and a reference point in time in the future from where the CCO issue is predicted to occur (i.e., from which time in the future the detection of the CCO issue is inferred).

In the second step, the gNB-DU replies to the gNB-CU with an indication, indicating to the gNB-CU a certain coverage modification corresponding to the predicted CCO issue. The gNB-DU can also inform the gNB-CU that no action was taken, e.g., if no coverage modification was executed by the gNB-DU to address the predicted CCO issue detected by the gNB-CU.

The first step is implemented in an extended CCO Assistance Information IE, as shown in the table of FIG 13. The IE may provide assistance information for the Capacity and Coverage (CCO) actions for specific CCO issues detected, and for network energy saving.

The second step may be implemented by extending the Coverage Modification Notification IE, as shown in FIGS. 14A-B. In particular, the gNB-DU sends to the gNB-CU an indication indicating to the gNB-CU that a certain coverage modification corresponds to a predicted CCO issue detected by the gNB-CU. If no coverage modification was executed by the gNB-DU to address the predicted CCO issue detected by the gNB-CU, the gNB-DU informs the gNB-CU that no action was taken. This IE includes a list of cells and/or SS/PBCH block indexes with the corresponding coverage configuration selected by the gNB-DU.

According to a fourth example of implementation (F1 AP), a gNB-CU informs a gNB-DU that a previously predicted CCO issue detected by the gNB-CU is no longer applicable. This is realized by extending the existing CCO Assistance Information IE, as shown in FIG. 15. The CCO Assistance Information IE may provide assistance information for the Capacity and Coverage (CCO) actions for specific CCO issues detected, and for network energy saving.

According to a fifth example of implementation (F1AP), a gNB-CU has previously informed a gNB-DU of a predicted CCO issue. The gNB-DU indicates to the gNB-CU whether a coverage modification corresponding to the predicted CCO issue detection cannot be performed, or it cannot be performed temporarily, and/or a reference time in the future (e.g., a time offset from the reception of a predicted CCO issue sent by the gNB-CU) starting from when the gNB-DU can apply a coverage modification that addresses the detected predicted CCO issue. The gNB-DU can also inform the gNB-CU that there is no available coverage modification that can be executed which would solve the predicted CCO issue detected by the gNB-CU.

Accordingly, a Coverage Modification Notification IE may include a list of cells and/or SS/PBCH block indexes with the corresponding coverage configuration selected by the gNB- DU, as shown in FIG. 16.

According to a sixth example of implementation (F1 AP and XnAP), it is assumed that a first gNB-CU has already sent to a controlled gNB-DU an indication that a certain predicted CCO issue is detected. The sixth implementation comprises a first step and a second step.

In the first step, the gNB-DU sends to the gNB-CU an indication that a corresponding coverage modification can be applied starting from certain time in the future (in particular the time in the future can be the prediction time from which the predicted CCO issue is detected, or an offset/shift from the time in the future to which the predicted CCO issue detection refers to).

In the second step, the first gNB-CU (seen as a first RAN node) sends to a second gNB- CU (seen as a second RAN node) indications that a predicted CCO issue detected by the first gNB-CU is expected to be addressed starting from a certain reference time in the future. In the first step, e.g., using additional Information Elements of a Coverage Modification Notification IE, the gNB-DU informs the gNB-CU of a time in the future starting from which the coverage modification associated to a predicted CCO issue detected by the gNB-CU may/can be applied.

Accordingly, a Coverage Modification Notification IE may include a list of cells and/or SS/PBCH block indexes with the corresponding coverage configuration selected by the gNB- DU, as illustrated in FIG. 17.

In the second step, e.g., using additional Information Elements of a Coverage Modification Item IE within the NG-RAN NODE CONFIGURATION UPDATE XnAP message, the first gNB-CU informs the second gNB-CU that a predicted CCO issue detected by the first gNB-CU is expected to be addressed starting from a certain reference time in the future (per cell and/or per SSB).

Accordingly, an NG-RAN NODE CONFIGURATION UPDATE message may be sent by a NG-RAN node to a neighbouring NG-RAN node to transfer updated information for an Xn-C interface instance in conformity with FIGS. 18A-C.

Although the various communication devices described herein may include the illustrated combination of hardware components, other embodiments may comprise computing and/or communication hardware with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions, and methods disclosed herein. Further, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, the devices described herein may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components.

Claims

CLAIMS What is claimed is:

1 . A method (300), implemented by a first Radio Access Network, RAN, node (120a), the method comprising: predicting (310) a Coverage and Capacity Optimization, CCO, issue impacting a coverage area (130) served by a second RAN node (120b); transmitting, to the second RAN node (120b), a notification message indicating the predicted CCO issue.

2. The method of claim 1 , wherein: the second RAN node (120b) is a Distributed Unit, DU (220); the first RAN node (120a) is a Centralized Unit, CU (250) controlling the DU (220).

3. The method of any one of the preceding claims, wherein the notification message further indicates a time when the predicted CCO issue will occur.

4. The method of any one the preceding claims, further comprising receiving, from the second RAN node (120b), an indication of a future time at which the second RAN node (120b) will provide a coverage modification associated with the predicted CCO issue.

5. The method of any one of the preceding claims, further comprising indicating, to a third RAN node, a time when one or more cells and/or Synchronization Signal Blocks, SSBs, served by the second RAN node will assume a certain coverage state corresponding to the predicted CCO issue.

6. The method of claim 5, wherein the third RAN node is a CU (250) not controlling the DU (220).

7. The method of any one of the preceding claims, wherein the notification message further indicates one or more cells and/or beams associated with the coverage area (130) and predicted to be affected by the predicted CCO issue.

8. The method of any one of the preceding claims, wherein the notification message further indicates an identifier of the CCO issue.

9. The method of any one of the preceding claims, wherein the notification message further indicates a metric for detecting the predicted CCO issue.

10. The method of any one of the preceding claims, wherein the notification message indicates a configuration parameter for providing feedback associated with the CCO issue.

1 1 . The method of any one of the preceding claims, further comprising receiving, from the second RAN node (120b), a response message indicating whether the second RAN node will address the predicted CCO issue.

12. The method of any one of the preceding claims, further comprising receiving, from the second RAN node (120b), a configuration modification message indicating a coverage modification that the second RAN node (120b) will apply to address the predicted CCO issue.

13. A first Radio Access Network, RAN, node (120a), configured to: predict a Coverage and Capacity Optimization, CCO, issue impacting a coverage area (130) served by a second RAN node (120b); transmit, to the second RAN node (120b), a notification message indicating the predicted CCO issue.

14. The first RAN node of the preceding claim, further configured to perform the method of any one of claims 2-12.

15. A first Radio Access Network, RAN, node (120a), comprising: interface circuitry (730) and processing circuitry (710) communicatively connected to the interface circuitry (730), wherein the processing circuitry (710) is configured to: predict a Coverage and Capacity Optimization, CCO, issue impacting a coverage area (130) served by a second RAN node (120b); transmit, to the second RAN node (120b), a notification message indicating the predicted CCO issue.

16. The first RAN node of the preceding claim, wherein the processing circuitry (710) is further configured to perform the method of any one of claims 2-12.

17. A computer program, comprising instructions which, when executed on processing circuitry (710) of a first Radio Access Network, RAN, node (120a), cause the processing circuitry (710) to carry out the method according to any one of claims 1-12.

18. A carrier containing the computer program of the preceding claim, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

19. A method (300), implemented by a second Radio Access Network, RAN, node (120b), the method comprising: receiving, from a first RAN node (120a), a notification message indicating a predicted Coverage and Capacity Optimization, CCO, issue impacting a coverage area (130) served by the second RAN node (120b).

20. The method of claim 19, wherein: the second RAN node (120b) is a Distributed Unit, DU (220); the first RAN node (120a) is a Centralized Unit, CU (250) controlling the DU (220).

21 . The method of any one of claims 19-20, wherein the notification message further indicates a time when the predicted CCO issue will occur.

22. The method of any one of claims 19-20, further comprising sending, to the first RAN node (120a), an indication of a future time at which the second RAN node (120b) will provide a coverage modification associated with the predicted CCO issue.

23. The method of any one of claims 19-22, wherein the notification message further indicates one or more cells and/or beams associated with the coverage area (130) and predicted to be affected by the predicted CCO issue.

24. The method of any one of claims 19-23, wherein the notification message further indicates an identifier of the predicted CCO issue.

25. The method of any one of claims 19-24, wherein the notification message further indicates a metric for detecting the predicted CCO issue.

26. The method of any one of claims 19-25, wherein the notification message indicates a configuration parameter for providing feedback associated with the predicted CCO issue.

27. The method of any one of claims 19-26, further comprising transmitting, to the first RAN node (120a), a configuration modification message indicating a coverage modification that the second RAN node (120b) will apply to address the predicted CCO issue.

28. The method of any one of claims 19-27, further comprising modifying coverage of the coverage area (130) to address the predicted CCO issue.

29. A second Radio Access Network, RAN, node (120b), configured to: receive, from a first RAN node (120a), a notification message indicating a predicted Coverage and Capacity Optimization, CCO, issue impacting a coverage area (130) served by the second RAN node (120b).

30. The second RAN node of the preceding claim, further configured to perform the method of any one of claims 20-28.

31 . A second Radio Access Network, RAN, node (120b), comprising: interface circuitry (730) and processing circuitry (710) communicatively connected to the interface circuitry (730), wherein the processing circuitry (710) is configured to: receive, from a first RAN node (120a), a notification message indicating a predicted Coverage and Capacity Optimization, CCO, issue impacting a coverage area (130) served by the second RAN node (120b).

32. The second RAN node of the preceding claim, wherein the processing circuitry (710) is further configured to perform the method of any one of claims 20-28.

33. A computer program, comprising instructions which, when executed on processing circuitry (710) of a second Radio Access Network, RAN, node (120b), cause the processing circuitry (710) to carry out the method according to any one of claims 20-28.

34. A carrier containing the computer program of the preceding claim, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.