Managing a communication network

Abstract

A method (100) for managing a communication network is disclosed. The method comprises a parameter change impact request (102a), and identifying at least one KPI of the communication network that will be impacted by the requested parameter change (104). The method further comprises obtaining a list of parameters that impact the at least one KPI (106), obtaining historical data observed for parameters in the obtained list (108), and using the obtained historical data to train a behavior model of a portion of the network (110). The method further comprises inputting a value from the parameter change impact request to the trained behavior model, which is operable to process the value according to trained values of its parameters, and to output a predicted value of the at least one KPI (112). Finally, the method comprises sending the predicted value of the at least one KPI (114) to the entity from which the request was received.

Description

[0001] Managing a Communication Network

[0002] Technical Field

[0003] The present disclosure relates to methods for managing a communication network, and particularly to methods for managing a communication network in the context of changes to parameters that may be implemented by logical entities within the communication network. The methods may be performed by a management node, and the present disclosure also relates to a management node, and to a computer program product configured, when run on a computer, to carry out methods for managing a communication network.

[0004] Background

[0005] In the context of communication network management, a Network Digital Twin (NDT) is a virtual, closely synchronized representation of a physical telecommunication network. NDTs can assist with Network Planning, Network Optimization, Network Management, Network testing and service provisioning, and are likely to be an important enabler for development of applications in future cognitive networks with 5G, 5G Advanced, and 6G technologies.

[0006] In a Service Provider’s Network, there are many management domains, including Radio Access Network (RAN) management, Core Management, Transport Management, End- to-End Slice Management etc. In the Open-RAN (O-RAN) architecture, Service Management and Orchestration (SMO) is responsible for RAN domain management.

[0007] The key capabilities of the SMO that provide RAN support in O-RAN are:

[0008] • Fault, Configuration, Accounting, Performance and Security (FCAPS) interface to O-RAN Network Functions

[0009] • Non-Real-Time RAN Intelligent Controller (Non-RT RIC) for RAN optimization

[0010] • O-Cloud Management, Orchestration and Workflow Management

[0011] One particular use of NDTs is as enablers in the Non-RT RIC framework, to support Non- RT RIC Applications (rApps) for evaluation and prediction. There currently exist certain challenges. T o provide effective support to the Non-RT RIC, among other applications, an NDT should be both dynamic and explainable, capturing the behavior of network components, and reflecting as closely as possible the reality of the network. Centralized and static NDTs in the SMO framework will consequently not be suitable for use by rApps.

[0012] Current technology for provision of NDTs relies upon either domain-based models, or data-based models to reflect the underlying behaviour of the network. NDT functional models that are implemented as domain-based models can be very specific, and consequently must be implemented extensively for every possible functionality and / or component that may need to be represented. This specificity makes such NDTs very difficult to scale across the whole network, as this would require deep knowledge of complex patterns, correlations, and behaviors across the network.

[0013] NDTs implemented via domain-based models therefore demonstrate the following disadvantages:

[0014] - Challenging to scale, with significant complex analysis required to maintain the models up the date;

[0015] Dynamic network behavior means domain-based models struggle to reflect real time behaviors, and to cover spatiotemporal aspects;

[0016] Lifecycle management (LCM) of domain-based models requires the same high levels of domain expertise as are necessary to generate the models;

[0017] Explainability is lacking outside of the domain expertise used in developing the models, and particularly for unknown network patterns and cross correlated behaviors.

[0018] In contrast to domain-based models, NDT functional models that are implemented as data-based models rely on historic data to capture the network's behaviors. This can address some of the issues noted above with respect to domain-based models. However, to capture all the possible behaviors of the network, a large volume of data is needed, with multiple possible scenarios captured in the data. An effective NDT representation requires a rich and varied selection of behaviors and events to be reflected in the data on which it is generated. Even with a rich dataset, data-based NDTs still suffer from the challenge that learning counterfactual scenarios from data is extremely difficult, and full coverage of network behaviors is almost impossible to achieve. It is an aim of the present disclosure to provide methods, a management node, and a computer program product which at least partially address one or more of the challenges mentioned above. It is a further aim of the present disclosure to provide methods, a management node, and a computer program product which cooperate to facilitate generation of an NDT which is dynamic, explainable and saleable.

[0019] According to a first aspect of the present disclosure, there is provided a computer implemented method for managing a communication network. The method, performed by a management node, comprises receiving, from a first logical entity within the communication network, a parameter change impact request. The parameter change impact request comprises an identification of a portion of the communication network to which the parameter change impact request applies, an identification of a network parameter, and a change value to be applied to the identified network parameter. The method further comprises obtaining an identification of at least one Key Performance Indicator (KPI) of the communication network that will be impacted by the requested parameter change, and obtaining a list of parameters that impact the at least one KPI. The method further comprises obtaining historical data observed in the identified portion of the network for the identified network parameter and parameters in the obtained list, and using the obtained historical data to train a behavior model of the identified portion of the network. The method further comprises inputting the change value of the identified network parameter to the trained behavior model, the behavior model being operable to process the change value according to trained values of its parameters, and to output a predicted value of the at least one KPI. Finally, the method comprises sending to the first logical entity the predicted value of the at least one KPI.

[0020] According to another aspect of the present disclosure, there is provided a computer program product comprising a computer readable non-transitory medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform a method according to any one of the aspects or examples of the present disclosure. According to another aspect of the present disclosure, there is provided a management node for managing a communication network. The management node comprises processing circuitry configured to cause the management node to receive, from a first logical entity within the communication network, a parameter change impact request. The parameter change impact request comprises an identification of a portion of the communication network to which the parameter change impact request applies, an identification of a network parameter, and a change value to be applied to the identified network parameter. The processing circuitry is further configured to cause the management node to obtain an identification of at least one KPI of the communication network that will be impacted by the requested parameter change, and to obtain a list of parameters that impact the at least one KPI. The processing circuitry is further configured to cause the management node to obtain historical data observed in the identified portion of the network for the identified network parameter and parameters in the obtained list, and to use the obtained historical data to train a behavior model of the identified portion of the network. The processing circuitry is further configured to cause the management node to input the change value of the identified network parameter to the trained behavior model, the behavior model being operable to process the change value according to trained values of its parameters, and to output a predicted value of the at least one KPI, and to send to the first logical entity the predicted value of the at least one KPI.

[0021] Aspects of the present disclosure thus provide methods and a management node that enable the generation of an NDT that addresses at least some of the above discussed challenges. The combination of domain knowledge, provided in the form of the list of parameters impacting a KPI of interest, together with data-based knowledge, provided in the form of historical data observed in the network, ensures that the behavior model that is trained and used according to the methods disclosed herein reflects the reality of the network, as well as being both scalable and explainable. The behavior models can be dynamically updated, and targeted to any part of the network, parameter change value, and KPI of interest. In this manner, the behavior of network components in a particular part of the network can be predicted with reference to a specific KPI of interest, and the particular configuration, policies, and environmental factors in the relevant part of the network that directly impact that KPI. Brief of the

[0022] For a better understanding of the present disclosure, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:

[0023] Figure 1 is a flow chart illustrating process steps in a computer implemented method for managing a communication network;

[0024] Figures 2a to 2d show flow charts illustrating another example of a method for managing a communication network;

[0025] Figure 3 is a block diagram illustrating functional modules in an example management node;

[0026] Figure 4 illustrates an example implementation of the management node of Figure 3;

[0027] Figure 5 illustrates use of pairwise causal models;

[0028] Figure 6 illustrates use of a multi-treatment model;

[0029] Figure 7 shows a system overview for an O-RAN use case;

[0030] Figure 8 illustrates an extract of a sample causal graph; and

[0031] Figure 9 illustrates implementation of the method of Figures 2a to 2d.

[0032] Detailed Description

[0033] The functional models underlying an NDT are generally the most complex component to create, and it is these models that determine the efficiency and accuracy of the network digital twin. A functional model can be either domain-based (behavior programmed based on domain knowledge) or data-driven (learnt from data using statistical or machine learning algorithms). As discussed above, in order to fulfil requirements for complex network management tasks, an NDT should be able to consider the changing dynamics of network configurations, traffic, and external factors, and the NDT should consequently be able to provide a representation of the communication network that is as close as possible to the reality of the network, and is synchronised with the real network.

[0034] Examples of the present disclosure propose a method to create an on-demand, dynamic, explainable Network Digital Twin (NDT). The present disclosure also proposes an implementation of this method, in which examples of the method are carried out by a Digital Twin Enabler component in the RAN service management and orchestration (SMO) platform. According to this example implementation, any rApp is able to create and / or consume digital twin instances through the R1 interface from the proposed Digital Twin Enabler component in the SMO. The example methods proposed herein enable the generation of functional models for NDTs that are able to capture the foundational physics from the real network, but are also capable of generalizing behavior from observed data. The models are capable of learning behavior from limited available data, and capable of transferring behavior knowledge from other similar components wherever data is not available.

[0035] The Digital Twin Enabler component, as an implementation of the management node proposed herein, is causality driven, and the causal behavior models are created as an NDT instance. In the existing data-driven and domain-based NDT approaches, the network behavior is modelled for each functionality or component of the network. The approach proposed herein differs in that it is functionality and component agnostic, focusing instead on network Key Performance Indicators (KPIs). The generation of the functional models may make use of a causal graph, bringing domain expertise, and uses network data, for example through the 01 / 02 interfaces, for the estimation of causal impact. For any particular KPI of interest, a list of influencing configurations, policy variables and environments can be retrieved, for example from a causal graph, and the historic network data for these parameters and KPI can be obtained. The causal model or models can then be trained with this historic data to measure the impact of individual configuration and policy changes on the KPI, thus providing explainability in the digital twin. Examples of the present disclosure also enable NDTs to be created on-demand with dynamically varying scope in terms of the network nodes concerned.

[0036] Example methods disclosed herein consequently offer dynamicity, reactivity, and explainability in the generation of NDTs for network management. Dynamicity is provided through the possibility of generating an NDT instance for any selected topology of the network, with the ability to update the NDT to add or remove network nodes to / from the NDT scope. Reactivity is provided in that NDTs can be instantiated either on-demand following specific request, or automatically according to a schedule, rule or other planning. The causal inference used in generating the NDTs according to examples of the present disclosure ensures explainability by enabling the attribution of impact on the KPI to individual configurations or environment parameters.

[0037] Figure 1 is a flow chart illustrating process steps in a computer implemented method 100 for managing a communication network. The method is performed by a management node of the communication network. The management node may comprise a physical or virtual node, and may be implemented in a computer system, computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, an Open Radio Access Network, O-RAN, or fog deployment. Examples of a virtual node may include a piece of software or computer program, a code fragment operable to implement a computer program, a virtualised function, or any other logical entity. The communication network may comprise a 4th, 5thor other generation 3GPP network such as an LTE network, a New Radio (NR) network or any other existing or future communication network systems. The management node may in some examples be implemented within functionality for RAN management, Core Management, Transport Management, End-to-End Slice Management etc. In the O-RAN architecture, the management node may be implemented within SMO functionality. The management node may encompass multiple logical entities, as discussed in greater detail below, and may for example comprise a Virtualised Network Function (VNF).

[0038] Referring to Figure 1 , the method 100 comprises, in a first step 102, receiving, from a first logical entity within the communication network, a parameter change impact request. As illustrated at 102a, the parameter change impact request comprises an identification of a portion of the communication network to which the parameter change impact request applies, an identification of a network parameter, and a change value to be applied to the identified network parameter. In step 104, the method 100 comprises obtaining an identification of at least one Key Performance Indicator (KPI) of the communication network that will be impacted by the requested parameter change. The method 100 then comprises obtaining a list of parameters that impact the at least one KPI in step 106, and obtaining historical data observed in the identified portion of the network for the identified network parameter and parameters in the obtained list in step 108. The method 100 then comprises, in step 110, using the obtained historical data to train a behavior model of the identified portion of the network. In step 112, the method 100 comprises inputting the change value of the identified network parameter to the trained behavior model. As illustrated in step 112, the behavior model is operable to process the change value according to trained values of its parameters, and to output a predicted value of the at least one KPI. Finally, in step 114, the method 100 comprises sending to the first logical entity the predicted value of the at least one KPI.

[0039] It will be appreciated that, as a minimum, the management node receives from the first logical entity in the communication network an identification of a portion of the communication network to which the parameter change impact request applies (for example a network topology comprising a plurality of communication network nodes), and an identification of a network parameter, as well as a change value to be applied to the identified network parameter (for example a configuration or policy change). In some examples, as discussed in further detail below, the management node may also receive from the first logical entity a KPI of interest. The management node obtains a list of parameters that impact the KPI of interest, which parameters could be network parameters (configuration, policy etc.), other KPIs, or external environment parameters. A parameter that impacts the KPI of interest may comprise a parameter that fulfils a condition according to which a change or event occurring in respect of the parameter results directly in the occurrence of a change or event in respect of the KPI of interest. Having obtained the list of parameters, the management node then obtains historical data for the relevant parameters, trains a behavior model for the part of the network concerned by the request, and uses the trained model to provide a predicted impact on the KPI of the requested change. Examples of the method 100 thus provide a method that enables generation of an NDT that is restricted to a specific part of the network, and that combines domain knowledge (provided by the obtained list of parameters impacting the KPI) and historical knowledge (provided by the observed data for the relevant parameters) to provide a virtual representation of the specific part of the network (digital twin) that is modular, dynamic, scalable, and explainable.

[0040] The method 100 trains and uses a behavior model, which may comprise a Machine Learning (ML) model. For the purposes of the present disclosure, the term “ML model” encompasses within its scope the following concepts: machine Learning algorithms, comprising processes or instructions through which data may be used in a training process to generate a model artefact for performing a given task, or for representing a real-world process or system; and the model artefact that is created by such a training process, and which comprises the computational architecture that performs the task.

[0041] Generally, an ML model, or a representation of an ML model, can be transmitted or transferred between nodes using any existing model format such as Open Neural Network Exchange, ONNX (https: / / onnx.ai), or formats used in commonly used toolboxes such as Keras or PyTorch.

[0042] Figures 2a to 2d show flow charts illustrating another example of a method 200 for managing a communication network. As for the method 100 discussed above, the method 200 is performed by a management node of the communication network. The management node may comprise a physical or virtual node, and may be implemented in a computer system, computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, an Open Radio Access Network, O- RAN, or fog deployment. Examples of a virtual node may include a piece of software or computer program, a code fragment operable to implement a computer program, a virtualised function, or any other logical entity. The communication network may comprise a 4th, 5thor other generation 3GPP network such as an LTE network, a New Radio (NR) network or any other existing or future communication network systems. The management node may in some examples be implemented within functionality for RAN management, Core Management, Transport Management, End-to-End Slice Management etc. In the O-RAN architecture, the management node may be implemented within SMO functionality. The management node may encompass multiple logical entities, as discussed in greater detail below, and may for example comprise a Virtualised Network Function (VNF). The method 200 illustrates examples of how the steps of the method 100 may be implemented and supplemented to provide the above discussed and additional functionality.

[0043] Referring initially to Figure 2a, in a first step 202, the management node receives, from a first logical entity within the communication network, a parameter change impact request. As illustrated at 202a, the parameter change impact request comprises an identification of a portion of the communication network to which the parameter change impact request applies, an identification of a network parameter, and a change value to be applied to the identified network parameter. The portion of the communication network to which the parameter change impact request applies may comprise for example a cell, a group of cells, a network slice, etc., and may be expressed as a network topology. The identified network parameter may comprise at least one of a configuration parameter and / or a policy parameter for the communication network. In some examples, as illustrated at 202b, the parameter change impact request may further comprise an identified KPI (that will be impacted by the parameter change that is the subject of the request). The first logical entity may comprise any logical entity within the communication network and operable to communicate with the management node. In examples in which the management node comprises a component of an O-RAN architecture, the first logical entity in the communication network may comprise an rApp.

[0044] On receipt of the parameter change impact request, the management node may check, in step 203, whether a behavior model operable to fulfil the received parameter change impact request is stored in a storage location. The storage location is accessible to the management node, and may be co-located with the management node, or may be in a separate physical or logical location. The storage location may be at least in part controlled by the management node, in that the management node is operable to store information in the storage location and to retrieve information from the storage location. It will be appreciated that a behavior model operable to fulfil the received parameter change impact request is a model that covers the same portion of the communication network, accepts values of the same network parameter as input (i.e. the subject of the change impact request), and provides a predicted value of the same KPI(s) (if specified) as those in the parameter change impact request.

[0045] If a behavior model operable to fulfil the received parameter change impact request is stored in the storage location (Yes at step 203), the management node proceeds to perform steps 230, 232, etc., as will be discussed in detail below. If, however, a behavior model operable to fulfil the received parameter change impact request is not stored in the storage location (no at step 203), the management node proceeds to obtain an identification of a KPI of the communication network that will be impacted by the requested parameter change. The management node first, in step 204, checks whether a KPI of interest was included in the parameter change impact request. If so, the management node extracts the at least one KPI from the received parameter change impact request in step 204b. If the parameter change impact request does not comprise an identified KPI, the management node requests, from a domain information entity, an identification of KPIs of the communication network that are impacted by the identified network parameter, and receives, from the domain information entity, the identification of at least one KPI of the communication network that will be impacted by the requested parameter change. The KPI(s) of interest (impacted by the identified network parameter) may be obtained from the same domain information entity as will provide the list of parameters. Consequently, as illustrated at step 204c, the requesting and receiving of the impacted KPI may be combined with the requesting and receiving of a list of parameters in steps 206a and 206b (Figure 2b). The domain information entity is discussed in greater detail below, and may be implemented in different ways according to the part of the communication network in which the management node is running. For example, if the management node is running in an O-RAN architecture, the domain information entity could comprise an rApp, an external application, or some other system accessible to the management node.

[0046] Referring now to Figure 2b, the management node then obtains a list of parameters that impact the at least one KPI in step 206. As illustrated at steps 206a to 206c, this obtaining may initially comprise requesting, from the domain information entity, information identifying parameters that impact the at least one KPI (step 206a), and then receiving, from the domain information entity, information identifying parameters that impact the at least one KPI. Finally, the management node may extract, from the received information, the list of parameters (step 206c). As discussed above, in situations in which the KPI of interest is not included with the parameter change impact request, the request for an identification of impacted KPIs and the request for impacting parameters may be sent in the same message.

[0047] According to examples of the present disclosure, the list of parameters that impact the at least one KPI comprises at least one of configuration parameters for the communication network, performance parameters for the communication network, policy parameters for the communication network, radio environment parameters for the communication network, and / or physical environment parameters of the physical environment encompassed in the coverage area of the communication network.

[0048] As illustrated at step 206c, the information identifying parameters that impact the at least one KPI may comprise at least one of a list of parameters and / or a portion of a causal graph for the communication network, the causal graph representing causal relationships between KPIs of the communication network, and parameters impacting the represented KPIs. For the purposes of the present disclosure, a causal graph comprises a graph of nodes and edges, the nodes representing, in the present context, parameters or KPIs of or affecting the network, and edges representing causal relationships between the parameters and KPIs. In the present context, a causal relationship comprises a cause- and-effect relationship according to which a change or event occurring in respect of one variable results directly in the occurrence of a change or event in respect of another variable. According to some examples, the portion of the causal graph received from the domain information entity may comprise all variables in the graph that have a directional link (casual relationship) leading to the at least one KPI.

[0049] Referring still to Figure 2b, the management node then obtains, in step 208, historical data observed in the identified portion of the network for the identified network parameter and for parameters in the obtained list. As illustrated in Figure 2b, obtaining observed historical data in step 208 may comprise requesting the historical data from network nodes within or having managerial responsibility for the identified portion of the communication network in step 208a, and receiving the requested historical data in step 208b. In some examples the historical data may also be requested from external sources, for example in the event of physical environment data that may not be recorded within the communication network.

[0050] Referring now to Figure 2c, the management node then, in step 210, uses the obtained historical data to train a behavior model of the identified portion of the network. As illustrated at step 210a, this may comprise using the obtained historical data to train at least one Machine Learning (ML) model to predict a value of a KPI of the communication network according to values of parameters impacting the KPI. This training step could comprise training one ML model or a plurality of ML models. The predicted value of a KPI may be a Conditional Average Treatment Effect (CATE), or an Individual Treatment Effect (ITE).

[0051] In some examples of the present disclosure, using the obtained historical data to train a behavior model of the identified portion of the network may comprise at least one of training a plurality of pairwise behavior models in step 21 Oai, each pairwise behavior model representing an impact on the at least one KPI of a parameter from the obtained list of parameters, and / or training a multiparameter behavior model in step 21 Oaii, the multiparameter behavior model representing an impact on the at least one KPI of a plurality of parameters from the obtained list of parameters.

[0052] Having trained the behavior model or models in step 210, the management node then inputs the change value of the identified network parameter (from the parameter change impact request) to the trained behavior model in step 212. The behavior model is operable to process the change value according to trained values of its parameters, and to output a predicted value of the at least one KPI. Also input to the behavior model in order to predict the KPI value may be current values of the parameters from the obtained list, these values being extracted from the obtained historical data.

[0053] Referring again briefly to Figure 2a, in the event that a behavior model operable to fulfil the received parameter change impact request was found to be stored in the storage location in step 203, steps 204 to 212 discussed above may be omitted. In such circumstances, as illustrated in Figure 2a, the management node may initially obtain updated values for inputs to the stored behavior model in step 230. It will be appreciated that these inputs will be values for the parameters that impact the relevant KPI. In the event that the behavior model is trained immediately before use (for example in steps 210, 212), then up to date values for these parameters would be included in the historical data obtained at step 208. However, if the model is a stored model that was trained at some point in the past, then up to date values may be obtained directly from the relevant network nodes, management entities, or other sources of network or environmental data.

[0054] In some examples, it may be envisaged that separate models be used to predict values of input data that cannot be obtained directly from network nodes or another appropriate data source. The updating of step 230 ensures that the behavior model reflects near real time conditions in the network, regardless of whether the model is trained for a specific request, or retrieved from the storage location.

[0055] Following the updating of step 230, the management node may then, in step 232, input the change value from the received parameter change impact request to the stored behavior model. It will be appreciated that the path of steps 230, 232 then arrives at an equivalent state to the path of steps 204 to 212, in that up to date information has been input to a behavior model that is operable to process that information, and to generate a predicted value of an impacted KPI.

[0056] Referring again to Figure 2c, following step 212, or step 232, the management node then, in step 214, sends to the first logical entity the predicted value of the at least one KPI output by the trained or stored behavior model. As illustrated at 214a, in some examples, the management node may additionally send a representation of a received accuracy indication to the first logical entity with the predicted value of the at least one KPI. This accuracy indication is discussed in greater detail below, and may have been received following use of a stored behavior model in a previous iteration of the method 200.

[0057] In step 216, if the management node has followed the path of steps 204 to 214 to arrive at step 214, and consequently the behavior model used to predict a KPI value has been newly trained, then the management node may store the trained behavior model, together with metadata relating to the trained behavior model, in the storage location.

[0058] As illustrated at 216a, the metadata may comprise at least one of inputs to the model, outputs from the model, identification of the portion of the communication network represented by the model, time at which the model was created or updated, time at which the model was last accessed, and / or training statistics for the model. This metadata may subsequently be updated by the management node to reflect events relating to the model (use, re-training, accuracy feedback, etc.).

[0059] Referring now to Figure 2d, the management node may, in step 218, receive from the first logical entity an accuracy indication for the predicted value of the at least one KPI. The management node may then store the received accuracy indication with the metadata relating to the trained behavior model in step 220. In some examples, it may be envisaged that a running average of received accuracy statistics is stored by the management node and provided, together with the predicted KPI value, to the first logical entity (in step 214a). It will be appreciated that in some examples, multiple logical entities may use the trained behavior model (via sending appropriate requests to the management node), some or all of which may provide accuracy feedback for updating the stored average or other representation of this information. In some examples, other metadata may also be included with the predicted value sent to the first logical entity, including for example a freshness indication relating to when the model used to generate the predicted value was last re-trained, or any of the metadata mentioned above.

[0060] In step 222, the management node checks for occurrence of a lifecycle trigger condition with respect to a stored behavior model. The lifecycle trigger condition may comprise at least one of a data drift condition fortraining data used to train the stored behavior model, a data drift condition for inference data with which the stored behavior model is used, an accuracy condition with respect to predicted values output by the stored behavior model, and / or an access frequency condition with respect to the stored behavior model. It will be appreciated that each of the above conditions reflects a slightly different aspect of the freshness of the model. For example, data drift may occur between inference and training data, as the time elapsed between training and use of the model increases. In other situations, for example if the network is evolving quickly, data drift may additionally occur between inference data over time. Even without data drift, performance degradation of the model may occur and be reflected in accuracy statistics received as feedback from entities providing parameter change impact requests. In still further conditions, network evolution may mean that a particular stored model becomes obsolete, for example no longer covering a reasonable part of the network for evaluation, or omitting new nodes that have been added to the network.

[0061] If no lifecycle trigger condition is fulfilled, the management node may simply return to step 202 and await the arrival of a new parameter change impact request from a logical entity in the network.

[0062] If a lifecycle trigger condition is fulfilled, the management node may perform a lifecycle management action on the stored behavior model in step 224. The lifecycle management action may comprise at least one of obtaining an updated list of parameters that impact the at least one KPI, obtaining updated historical data observed in the identified portion of the network for the identified network parameter and parameters in the obtained list, retraining the stored behavior model, archiving the stored behavior model, and / or purging the stored behavior model. Following execution of the lifecycle management action, the management node may then return to step 202 and await the arrival of a new parameter change impact request from a logical entity in the network.

[0063] As discussed above, the methods 100 and 200 may be performed by a management node, and the present disclosure provides a management node that is adapted to perform any or all of the steps of the above discussed methods. The management node may comprise a physical or virtual node, and may be implemented in a computer system, computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, an Open Radio Access Network, O-RAN, or fog deployment. Examples of a virtual node may include a piece of software or computer program, a code fragment operable to implement a computer program, a virtualised function, or any other logical entity. The communication network may comprise a 4th, 5thor other generation 3GPP network such as an LTE network, a New Radio (NR) network or any other existing or future communication network systems. The management node may in some examples be implemented within functionality for RAN management, Core Management, Transport Management, End-to-End Slice Management etc. In the O-RAN architecture, the management node may be implemented within SMO functionality. The management node may encompass multiple logical entities, as discussed in greater detail below, and may for example comprise a Virtualised Network Function (VNF).

[0064] Figure 3 is a block diagram illustrating an example management node 300 which may implement the method 100 and / or 200, as illustrated in Figures 1 and 2a to 2d, according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 350. Referring to Figure 3 the management node 300 comprises a processor or processing circuitry 302, and may comprise a memory 304 and interfaces 306. The processing circuitry 302 is operable to perform some or all of the steps of the method 100 and / or 200 as discussed above with reference to Figures 1 and 2a to 2d. The memory 304 may contain instructions executable by the processing circuitry 302 such that the management node 300 is operable to perform some or all of the steps of the method 100 and / or 200, as illustrated in Figures 1 and 2a to 2d. The instructions may also include instructions for executing one or more telecommunications and / or data communications protocols. The instructions may be stored in the form of the computer program 350. In some examples, the processor or processing circuitry 302 may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry 302 may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) etc. The memory 304 may include one or several types of memory suitable for the processor, such as read-only memory (ROM), randomaccess memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive, etc.

[0065] Figures 1 to 2d discussed above provide an overview of methods which may be performed according to different examples of the present disclosure. These methods may be performed by a management node, as illustrated in Figure 3. The methods enable the generation of a Network Digital Twin (NDT) that is modular, dynamic, scalable, and explainable. There now follows a detailed discussion of how different process steps illustrated in Figures 1 to 2d and discussed above may be implemented. The functionality and implementation detail described below is discussed with reference to the modules of Figure 3 performing examples of the methods 100 and / or 200, substantially as described above.

[0066] As set out above, an NDT created using methods according to the present disclosure may comprise multiple KPI causal behavior models, which represent the holistic behavior of KPIs irrespective of functionalities of the network nodes involved. To build these causal KPI behavior models, a hybrid approach is used combining domain knowledge (provided by a domain information entity, for example based upon or in the form of a Causal Graph) and observational data (historic data) from the network. This hybrid approach enables generation of causal inference models for all the influencing parameters for a given KPI.

[0067] According to examples of the present disclosure, an NDT can be requested on-demand for any dynamic scope (that is any part of communication network, parameter change, and KPI of interest) and the data is fetched only for the relevant parameters of the selected scope. Fora given KPI, the NDT instance may be trained based on data fetched from network nodes, for example through 01 / 02 interfaces. Additionally, the NDT instance may be trained using environment data such as weather, events, traffic etc., from external applications.

[0068] The management node creates NDT instances using causal behaviour models, which capture the behaviour of the network specific to the given scope. The scope may be defined by Network Cluster (Group of cells / sectors / sites, etc.), Network KPI (if included in the parameter change request) and Network Configurations (including the parameter to be changed). For example, if User Throughput is selected as KPI, cell sleep is selected as configuration and a particular set of sub-urban cells are selected as topology (network portion to which the request applies), the causal behaviour model (NDT instance) captures the behaviour of the cell sleep functionality and User Throughput for that sub-urban area. The usage of causal behavior models enables the complete explainability of the created NDT instances.

[0069] Figure 4 illustrates an example implementation of the management node discussed herein. In the illustrated implementation, the management node is instantiated in the SMO framework of the O-RAN architecture. The management node is implemented as a “Digital Twin Enabler” component, and comprises a plurality of different logical-sub entities, each of which may implement specific parts of the functionality of the management node described above.

[0070] Referring to Figure 4, the Digital Twin Enabler component (management node) comprises a DT Training client, a DT inference client, and a DT registry. The Digital Twin Enabler component is in communication with rApps over R1 interfaces, and is also in communication with mother network nodes over 01 / 02 interfaces. The Digital Twin Enabler component also communicates with a domain information entity in the form of External Data Enablement Applications / Enabler rApps, and with one or more sources of environment data.

[0071] On receipt of a parameter change impact request from an rApp (steps 102 / 202 of methods 100 / 200), the DT training client of the Digital Twin Enabler component fetches the relevant list of parameters (for example extracted from a portion of a causal graph provided to the DT training client), and fetches relevant observational data from the network nodes (steps 106, 108 / 206, 208 of methods 100 / 200). The DT training client then creates one or more causal behavior models (steps 110 / 210 of method 100 / 200)

[0072] Each trained causal behavior model is registered in the Digital Twin Registry (DTR) as a new NDT instance (step 216 of method 200). Each NDT instance can be uniquely identified with DT Identifier which is a combination of cluster(topology), KPI and configurations. For each instance of NDT, the instance metadata such as DT identifier, created / Update time, last accessed time, training statistics etc. may be recorded and updated over time (steps 216, 216a of method 200). The DT registry enables the instances to be shared across the rApps irrespective of the creator / owner of the instance (steps 203, 230, 232 of method 200). The lifecycle of the instances is owned by Digital Twin Enabler component, which detects drift / accuracy and retraining the instance accordingly. The Digital Twin Enabler component also takes care of archiving / purging an NDT instance when it is not used for inference for a given period (steps 222, 224 of method 200).

[0073] As illustrated in Figure 4, the example management node in the form of the Digital Twin Enabler component is a component part of the SMO framework, and rApps can subscribe to the DT instances as-a-service and get inference on-demand from the Digital Twin Enabler component. This enables the possibility of DT-as-a-service for internal and / or third-party rApps. rApps in the SMO framework interact with the Digital Twin Enabler component through the R1 interface to evaluate configuration proposals, or for counterfactual analysis for any given KPI and network cluster. A request may contain the KPI name, and will include an identifier of a part of the network (network cluster identifier) and a list of configurations and their values.

[0074] Based on the received cluster, KPI and configuration, the inference client of the Digital Twin Enabler component checks if a pretrained instance is available in the registry (step 203 of method 200) and performs either of the below actions:

[0075] If the DT instance is already available, the inference client returns the value of KPI at t0(Current), impact of each of the configuration change on KPI and value of KPI at ^(Future) (steps 230, 232, 214 of method 200).

[0076] If the DT instance is not already available, the inference client triggers the training client to dynamically create the DT instance for the given scope. The training client trains the causal behavior model given KPI, cluster and configurations and registers in DT registry (steps 204 to 210 and 216 of method 200). A notification is sent to rApp that the DT instance is available for inference and / or the inference client performs interference and returns the value of KPI at t0(Current), impact of each of the configuration change on KPI and value of KPI at (Future) (steps 212 and 214 of method 200).

[0077] The created digital twin instance for a given scope can be regularly updated based on change in the data or based on a schedule. Also, the instances can continuously improve the system to stay relevant to network changes, traffic and improve accuracy over time in an automated way via any of the actions set out below.

[0078] 1. By updating the input causal graph periodically to capture new KPIs and newly identified relations to improve the accuracy of causal models. An updated causal graph can be used as source of parameter list in subsequent iterations of the methods to update or generate new NDT instances.

[0079] 2. The impact of a change estimated from NDTs can be compared with actual impact by the rApps, and feedback can be sent back to the Digital Twin Enabler component, which can trigger the re-training of causal models on latest training data (steps 218, 222, 224 of method 200). 3. The drift in distribution of training data can be periodically compared with data used for inference of NDTs to trigger re-training of causal models on latest training data (steps 222, 224 of method 200).

[0080] 4. The drift in distribution of data used for inference of NDTs at different points in time can be compared at frequent intervals to trigger re-training of pairwise or other models on latest training data (steps 222, 224 of method 200).

[0081] The following description addresses in greater detail the behavior models that are trained to provide predictions of impact on KPIs of a given parameter change in a given part of the network. As discussed above, the inputs to the behavior models are based on a list of parameters that impact a KPI of interest. This list may be extracted from a (part of a) causal graph which may represent all the configurations, policies and environmental factors related to each KPI. Causal discovery (which may be performed for example by the domain information entity discussed above) is covered in greater detail later in this description.

[0082] The behavior models use causal inference algorithm models to estimate the conditional average treatment effect (CATE) or individual treatment effect (ITE) for the given treatment (configuration / policy / environment) on the outcome (KPI) variable. For each causal behavior model, the CATE T for the binary treatment (configuration / policy / environment) T can be given as

[0083] T = E[y(T = 1) - y(T = 0)|X = x] where, y is a KPI (outcome variable),

[0084] T is a configuration / policy / Other Environment parameter (Treatment), and

[0085] X are other parameters / variables (Covariates) from the causal graph.

[0086] A parameter of interest is considered as treatment variable(T) (that is a parameter to which a change may be applied), the KPI is considered as outcome variable(Y) and all other parameters and variables are considered as covariates(X).

[0087] If the treatment parameter T of a causal model is continuous variable, then CATE T can be given as:

[0088] The causal model can use any causal inference algorithms capable of estimating CATE for both discrete and continuous treatments.

[0089] The causal inference algorithms can be applied to the given problem of Network Digital twin though use of one or more pairwise causal models, and / or through use of multitreatment causal models.

[0090] Using pairwise causal Models (step 210ai of method 200)

[0091] Use of pairwise causal models is illustrated in Figure 5. For the KPI and parameters in scope, all the possible KPI-parameter pairs are identified from the causal graph. For each pair, pairwise causal models are built using ML-based causal inference algorithms, which estimate the delta impact on KPI for each of the configurations, policies, or environment.

[0092] As an example, a particular Network KPI ‘A’ may be impacted by both increase in network traffic as well as configuration change in the RAN. The Pairwise model for ‘KPI A-Traffic’ estimates the delta impact on KPI A from traffic increase. The Pairwise model for ‘KPI A-Configuration x’ estimates the delta impact on KPI A from the configuration x. A pairwise causal model can use any causal inference algorithms capable of estimating CATE or ITE for both discrete and continuous treatments.

[0093] All Pairwise Models for a given list of parameters impacting a KPI can be combined to create the KPI behavior model. The KPI behavior model can then be used to estimate the overall impact on the KPI. The overall impact of the KPI will be sum of the individual impacts from each of the pairwise models for the given KPI.

[0094] The total impact on the KPI can be given as the summation of conditional average treatment (CATE) from the individual pairwise models forthat KPI. Say, if TPis the CATE of a given pairwise model, then the total impact on the KPI can be given as Where TPis a CATE estimation from pairwise model p and p1,p2, ,pnre pairwise models available for the given KPI.

[0095] The rApps can infer the impact on KPI based on one or more configurations from the KPI behavior models to evaluate multiple proposals at the same time.

[0096] Using multi-treatment causal Models (step 21 Oaii of method 200)

[0097] While pairwise models for each treatment parameter are useful and suitable for most scenarios, there might be scenarios in which it is desirable for a single model to handle multiple treatments. For example, in scenarios in which treatments are related and dependent, a more accurate representation of this interdependency, and its impact upon the output KPI, can be provided by a single multi-treatment model. Use of a multitreatment model is illustrated in Figure 6.

[0098] In the KPI causal behavior model illustrated in Figure 6, the delta KPI is estimated from a single causal inference model. This approach is useful in scenarios involving multiple network elements (say Core and RAN) and when multiple configurations or policies are always applied together in these elements.

[0099] Example Use Cases

[0100] Any Autonomous network operation requires understanding of the impact on the network that would be caused by a proposed change, be it change in configuration, in policy, in traffic pattern, etc. NDTs play a critical role in not only understanding the current state of network but also predicting a future state of network in the event of application of proposed changes in configuration, traffic, policies, and other environment variables. This enables evaluation of closed loop automations in many management scenarios in the RAN, Core, and Transport networks of a communication network. As discussed above, the O-RAN architecture is one particular domain in which examples of the present disclosure may find application. One current research area for O-RAN specifies the use case of a Network Digital Twin that is architecturally present within the non-RT RIC framework (an implementation illustrated with respect to the resent disclosure in Figure 4). Figure 7 provides a system overview for an O-RAN use case for the methods disclosed herein involving multiple rApps for network optimization. The use case is illustrated with the management node implementation of Figure 4, that is a Network Digital Twin Enabler component having the previously explained functionalities.

[0101] Referring to Figure 7, the Network Digital Twin Enabler component takes a casual graph and historical data as input, and estimates a pairwise or multi-treatment causal inference model to isolate the delta impact of each influencing configuration, policy, performance counter and other environment factors. rApps can subscribe to the Network Digital Twin Enabler component so as to create a digital twin instance and consume predictions, for example to support other downstream activities.

[0102] In the following example use case, Cell Downlink throughput is the target KPI for which the behavior model is created in digital twin. Figure 8 illustrates an extract of a sample causal graph for this KPI. This causal graph may be generated and maintained by a domain information element, and an extract provided on demand to the Network Digital Twin Enabler component. Figure 9 illustrates full implementation of the method 200 on the illustrated system architecture.

[0103] Referring in particular to Figures 8 and 9, in this example use case, the following inputs are taken by Network Digital Twin Enabler component to build the Digital twin instance:

[0104] I. Target KPI - Cell Downlink Throughput

[0105] II. Topology of interest - Cell level

[0106] III. Interested configuration - Maximum Transmission power

[0107] IV. Interested Environment - Downlink Traffic

[0108] The Network Digital Twin Enabler component first checks if models are already available in the DT registry to fulfill the request (step 203 of method 200). If a suitable model is available, then this is used by the Network Digital Twin Enabler component inference client to generate the requested prediction (steps 230, 232, 214 of method 200). If a suitable model is not available, then the Network Digital Twin Enabler component proceeds with subsequent steps.

[0109] The Network Digital Twin Enabler component fetches the relevant sub graph of a causal graph for the target KPI (step 206 of method 200). This provides the list of parameters impacting the subject KPI, expressing the domain level information that enables accurate prediction of the impact of one parameter change value on the KPI of interest. In order to quantify the relations expressed in the subgraph, and to build the behavior model(s), recent historic or observed data for the Maximum Transmission power (configuration) and Performance Management (PM) Active UE DL Sum is pulled from a network database (step 208 of method 200).

[0110] A pair-wise model is then trained with Maximum Transmission power as input and cell downlink throughput as target. Similarly, a pair-wise model is trained for PM Active UE DL Sum as input & cell downlink throughput as target (steps 210, 210a, 21 Oai of method 200). As Active UE DL Sum is a performance counter it is forecasted for future timelines to be used for inference. The pairwise causal models can use any causal inference algorithms capable of estimating CATE for both discrete and continuous treatments. One such algorithm used in the example implementation is the Double Machine Learning (Double ML) causal inference algorithm, which performs two level regression to arrive at the average treatment effect. In the first level, outcome(y) is regressed with the covariates(X) and the treatment(T) is regressed with covariates(X). In the second level, the residuals from first level regressions y* and T* are regressed to obtain the treatment effect on outcome.

[0111] Each pair wise model isolates the delta impact of the identified parameter on target KPI Cell Downlink Throughput. The outcomes of the pairwise models are then combined in the digital twin to predict future values of Cell Downlink Throughput. Using the current state and proposed change of parameters, the future state of Cell Downlink Throughput is predicted by the digital twin (steps 212, 214 etc. of method 200).

[0112] Digital Twins for ORAN rApp conflict management

[0113] Another example use case for methods according to the present disclosure is in managing conflict between multiple rApps by studying the impact of individual rApps when the one or more other rApps are running simultaneously.

[0114] One example would be to use the methods disclosed herein for conflict management for two rApps, one might be concerned with Traffic Management for example, and another with coverage. Recommendations for parameter (configuration, policy etc.) changes may be received from both rApps and provided as an input to a digital twin instance for validation of any possible conflicts that might arise upon activation of the recommendations via the Configuration Management (CM) updates on the network. The NDT instance can measure the impact of the KPIs based on the recommendations as part of its validation criteria and flag any conflicts that might arise for both the traffic management and coverage use cases. Through this method, using the DT in O-RAN Non-RT RIC Framework, conflicting decisions by an rApp may be mitigated.

[0115] Another example use case for methods according to the present disclosure is as an evaluation agent for an Intent Management Function. A key goal of Intent Management networks is to minimize human intervention and facilitate autonomous network operations. An Intent Management loop generates and evaluates multiple proposals to identify the most favourable one based on its impact across intents. A management node such as a Network Digital Twin Enabler component as described herein can be used as an evaluation agent in an Intent Management loop to validate multiple proposals. The dynamic scope and on-demand instantiation (based on schedule or request) enables the servicing of multiple intents of different scope. Additionally, the explainability offered by the methods disclosed herein provides additional explainable support to Intent Management and closed loop automation.

[0116] Causal Discovery

[0117] It will be appreciated that while the methods disclosed herein do not encompass generating a causal graph, they may take as input an extract of a causal graph, or a list of parameters generated from a causal graph. A causal graph is generated through a causal discovery process, and there now follows, for completeness, a brief discussion of this subject.

[0118] Causal Discovery involves learning a graphical representation (causal graph) between variables, either from observed data or from prior knowledge (expert opinion, documentation / Large Language Models (LLMs), etc.). There exist multiple algorithms and methodologies to derive a causal graph according to the particular problem to be addressed.

[0119] Causal Graphs from Data For creating causal graphs from data, there exist many widely used algorithms, and they may be grouped broadly into constraint-based algorithms, score-based algorithms and Hybrid algorithms. Peter-Clark (PC) and Fast Causal Inference (FCI) are the most used constraint-based algorithms. Greedy Equivalent Search (GES) is the most well known score-based algorithm. Linear Non-Gaussian Acyclic (LiNGAM) is an example of a hybrid algorithm. A detailed survey of the causal discovery from can be found in Alessio Zanga and Fabio Stella: “A Survey on Causal Discovery: Theory and Practice”, 18thMay 2023, https: / / arxiv.orq / pdf / 2305.10032.

[0120] To create a causal graph for a telecommunications network KPIs and configurations, in experimental validation, the authors of the present disclosure used Linear Non-Gaussian Acyclic Models (LiNGAM) which uses independent component analysis (ICA) to arrive at the causal graph. The algorithm also provides an option to provide prior knowledge (known relationships) as either hard or soft knowledge.

[0121] Causal Graphs from Documents

[0122] With the advent of Large Language Models (LLMs), there is lot of emerging literature on using LLM’s for causal discovery, an example of which is Thomas Jiralerspong et al., Efficient Causal Graph Discovery Using Large Language Models, 20thJuly 2024, https: / / arxiv.orq / pdf / 2402.01207.

[0123] Causal Graphs using Expert input

[0124] A causal graph is essentially a model of a data generation process. In some examples a domain expert may be able to provide relationships as input, which can be assembled into a causal graph. However, this approach is highly constrained, and is very difficult to scale for large numbers of variables.

[0125] Examples of the present disclosure thus provide methods and a management node that enable generation of a digital representation (NDT) of a part of a communication network. The methods and node offer explainability, robustness, scalability, adaptability and a dynamic behaviour that remains close to the underlying network reality.

[0126] Explainability is afforded through the use of causal behaviour models, enabling the attribution of impact on a KPI to individual configurations or environment parameters. This ensures that with evolution to 6G networks, the required explainability in autonomous network operations and evaluation of autonomous actions are supported. The methods provided herein allow for NDTs that are modular and distributed instead of a single monolithic instance of network behaviors all packed into one system. This ensures robustness in the system. The distributed lean architecture also ensures scalability, and the methods can be applied to any selected topology and scope. The methods can be used across a wide range of use cases and KPIs to evaluate cross impacts and behaviors, and also allow for continuously learning and consequent improvement sin accuracy over time.

[0127] The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

[0128] It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims or numbered embodiments. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim or embodiment, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims or numbered embodiments. Any reference signs in the claims or numbered embodiments shall not be construed so as to limit their scope.

Claims

28CLAIMS1 . A computer implemented method (100) for managing a communication network, the method, performed by a management node, comprising: receiving, from a first logical entity within the communication network, a parameter change impact request (102), the parameter change impact request comprising an identification of a portion of the communication network to which the parameter change impact request applies, an identification of a network parameter, and a change value to be applied to the identified network parameter (102a); obtaining an identification of at least one Key Performance Indicator, KPI, of the communication network that will be impacted by the requested parameter change (104); obtaining a list of parameters that impact the at least one KPI (106); obtaining historical data observed in the identified portion of the network for the identified network parameter and parameters in the obtained list (108); using the obtained historical data to train a behavior model of the identified portion of the network (110); inputting the change value of the identified network parameter to the trained behavior model, wherein the behavior model is operable to process the change value according to trained values of its parameters, and to output a predicted value of the at least one KPI (112); and sending to the first logical entity the predicted value of the at least one KPI (114).

2. A method as claimed in claim 1 , wherein, if the parameter change impact request further comprises an identified KPI (202b), obtaining an identification of at least one KPI of the communication network that will be impacted by the requested parameter change comprises extracting the at least one KPI from the received parameter change impact request (204b).

3. A method as claimed in claim 1 or 2, wherein, if the parameter change impact request does not comprise an identified KPI, obtaining an identification of at least one KPI of the communication network that will be impacted by the requested parameter change comprises (204c): requesting, from a domain information entity, an identification of KPIs of the communication network that are impacted by the identified network parameter; andreceiving, from the domain information entity, the identification of at least one KPI of the communication network that will be impacted by the requested parameter change.

4. A method as claimed in any one of the preceding claims, wherein obtaining a list of parameters that impact the at least one KPI comprises: requesting, from a domain information entity, information identifying parameters that impact the at least one KPI (206a); receiving, from the domain information entity, information identifying parameters that impact the at least one KPI (206b); and extracting, from the received information, the list of parameters (206c).

5. A method as claimed in claim 4, wherein the information identifying parameters that impact the at least one KPI comprises at least one of (206b): the list of parameters; a portion of a causal graph for the communication network, the causal graph representing causal relationships between KPIs of the communication network, and parameters impacting the represented KPIs.

6. A method as claimed in any one of the preceding claims, wherein obtaining historical data observed in the identified portion of the network for the identified network parameter and parameters in the obtained list comprises: requesting the historical data from network nodes within or having managerial responsibility for the identified portion of the communication network (208a); and receiving the requested historical data (208b).

7. A method as claimed in any one of the preceding claims, wherein using the obtained historical data to train a behavior model of the identified portion of the network comprises using the obtained historical data to train at least one Machine Learning, ML model to predict a value of a KPI of the communication network according to values of parameters impacting the KPI (210a).

8. A method as claimed in any one of the preceding claims, wherein using the obtained historical data to train a behavior model of the identified portion of the network comprises at least one of:training a plurality of pairwise behavior models, each pairwise behavior model representing an impact on the at least one KPI of a parameter from the obtained list of parameters (21 Oai): training a multiparameter behavior model, the multiparameter behavior model representing an impact on the at least one KPI of a plurality of parameters from the obtained list of parameters (21 Oaii).

9. A method as claimed in any one of the preceding claims, further comprising storing the trained behavior model, together with metadata relating to the trained behavior model, in a storage location (216).

10. A method as claimed in claim 9, wherein the metadata comprises at least one of (216a): inputs to the model; outputs from the model; identification of the portion of the communication network represented by the model; time at which the model was created or updated; time at which the model was last accessed; training statistics for the model.

11. A method as claimed in claim 9 or 10, further comprising: receiving from the first logical entity an accuracy indication for the predicted value of the at least one KPI (218); and storing the received accuracy indication with the metadata relating to the trained behavior model (220).

12. A method as claimed in claim 11 , further comprising sending a representation of the received accuracy indication to the first logical entity with the predicted value of the at least one KPI (214a).

13. A method as claimed in any one of claims 9 to 12, further comprising: on receipt of the parameter change impact request, checking whether a behavior model operable to fulfil the received parameter change impact request is stored in the storage location (203); andif a behavior model operable to fulfil the received parameter change impact request is stored in the storage location, inputting the change value from the received parameter change impact request to the stored behavior model (232); and sending to the first logical entity the predicted value of the at least one KPI output by the stored behavior model (214).

14. A method as claimed in claim 13, further comprising: if a behavior model operable to fulfil the received parameter change impact request is stored in the storage location, obtaining updated values for inputs to the stored behavior model (230).

15. A method as claimed in any one of claims 9 to 14, further comprising: checking for occurrence of a lifecycle trigger condition with respect to a stored behavior model (222); and on occurrence of a lifecycle trigger condition, performing a lifecycle management action on the stored behavior model (224).

16. A method as claimed in claim 15, wherein the lifecycle trigger condition comprises at least one of: a data drift condition for training data used to train the stored behavior model; a data drift condition for inference data with which the stored behavior model is used; an accuracy condition with respect to predicted values output by the stored behavior model; an access frequency condition with respect to the stored behavior model.

17. A method as claimed in claim 15 or 16, wherein the lifecycle management action performed on the stored behavior model comprises at least one of: obtaining an updated list of parameters that impact the at least one KPI; obtaining updated historical data observed in the identified portion of the network for the identified network parameter and parameters in the obtained list; retraining the stored behavior model; archiving the stored behavior model purging the stored behavior model.3218. A method as claimed in any one of the preceding claims, wherein the identified network parameter comprises at least one of a configuration parameter or a policy parameter for the communication network.

19. A method as claimed in any one of the preceding claims, wherein the list of parameters that impact the at least one KPI comprises at least one of: configuration parameters for the communication network; performance parameters for the communication network; policy parameters for the communication network; radio environment parameters for the communication network; physical environment parameters of the physical environment encompassed in the coverage area of the communication network.

20. A method as claimed in any one of the preceding claims, wherein the management node comprises a component of an Open Radio Access Network, O- RAN, architecture, and wherein the first logical entity in the communication network comprises an rApp.

21. A computer program product comprising a computer readable medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform a method as claimed in any one of claims 1 to 20.

22. A management node (300) for managing a communication network, the management node comprising processing circuitry (302) configured to cause the management node to: receive, from a first logical entity within the communication network, a parameter change impact request, the parameter change impact request comprising an identification of a portion of the communication network to which the parameter change impact request applies, an identification of a network parameter, and a change value to be applied to the identified network parameter; obtain an identification of at least one Key Performance Indicator, KPI, of the communication network that will be impacted by the requested parameter change; obtain a list of parameters that impact the at least one KPI;obtain historical data observed in the identified portion of the network for the identified network parameter and parameters in the obtained list; use the obtained historical data to train a behavior model of the identified portion of the network; input the change value of the identified network parameter to the trained behavior model, wherein the behavior model is operable to process the change value according to trained values of its parameters, and to output a predicted value of the at least one KPI; and send to the first logical entity the predicted value of the at least one KPI.

23. A management node as claimed in claim 22, wherein the processing circuitry is further configured to cause the management node to carry out a method according to any one of claims 2 to 20.

Images