Distributed digital twin for a communication network

Abstract

Embodiments include methods performed by a remote node of a distributed digital twin (DT) for a communication network comprising a plurality of cells of which a subset is associated with the remote DT node. Such methods include receiving an indication of a configuration change for at least one cell of the subset and, based on the configuration change, executing an initial phase of a behavioral model representative of at least the subset of cells, thereby generating an initial result. Such methods also include performing at least one o f the following operations: sending the initial result to a central DT node or to one or more other remote DT nodes associated with respective one or more other subsets of the cells; and receiving, from the one or more other remote DT nodes, respective ini tial results generated by execution of behavioral models for the respective other subsets, based on the configuration change.

Description

[0001] DISTRIBUTED DIGITAL TWIN FOR A COMMUNICATION NETWORK

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to communication networks and more specifically to less complex architectures for a "digital twin” of a communication network, which may be used for optimization of the communication network.

[0004] BACKGROUND

[0005] The fifth generation (5G) of cellular systems was initially standardized 3GPP Rel-15 and continues to evolve in subsequent releases. 5G is developed for maximum flexibility to support a variety of different use cases including enhanced mobile broadband (eMBB), machine type communications (MTC), ultra-reliable low latency communications (URLLC), side-link device-to-device (D2D), and several other use cases. 5G technology shares many similarities with fourth-generation Long Term Evolution (LTE).

[0006] At a high level, the 5G System (5GS) consists of an Access Network (AN) and a Core Network (CN). The AN provides UEs connectivity to the CN, e.g., via base stations such as gNBs or ng -eNBs. The CN includes a variety of Network Functions (NF) that provide a range of functionality such as session and connection management, charging, authentication, etc.

[0007] The ever increasing complexity of communication networks, including 5G networks, drives the evolution of analytics systems that support operation, optimization, and planning of these networks. This includes detecting and addressing sudden, undesired changes in network operation and / or performance (e.g., failures). These analytics systems, in turn, require collecting and processing of enormous amounts of data, such as time series data.

[0008] In some cases, these analytics systems may utilize M achine learning (ML), which is a type of artificial intelligence (Al) that imitates human learning to gradually improve accuracy. ML algorithms build models based on sample (or "training”) data, with the models being used subsequently to make predictions or decisi ons. In addition to communication networks, ML can be used in a wide variety of applications (e.g., medicine, email filtering, speech recognition, etc.) in which it is difficult or unfeasible to develop conventional algorithms to perform the needed tasks.

[0009] One type of ML algorithm is "reinforcement learning” (RL), where the algorithm (or agent) is exposed to an environment in which it trains itself continually using trial and error. An RL agent accumulates knowledge about the dynamics of its environment (e.g., the communication network) through different interactions that may result in positive or negative outcomes. To train the system, the RL agent interacts with the environment by repeatedly observing its state and then - based on the knowledge available to the RL agent at each stage - taking actions intended to maximize a long-term reward based on defined criteria. In each iteration, the RL agent will learn from the outcome of the suggested actions and will become increasingly “wiser”. At the beginning of the process, the RL agent’s exploration of the environment may be erratic but will gradually become more focused and precise as the iterations proceed and the RL agent gains knowledge about the environment’s dynamics.

[0010] Even so, training ML models for operation in a complex communication network poses some challenges, For example, it can be risky to allow an RL agent to take actions to accumulate needed knowledge based on dynamics of its environment - a live communication network - when such actions can negatively impact the operation of the communication network. Negative outcomes that result in downtime of the communication network and user services are unacceptable in practice.

[0011] Accordingly, digital twins (DT) have been used to provide a simulated testing environment in which an ML model (e.g., RL agent) can be trained via initiating “what-if actions and observing reward (e.g., outcomes) due to these actions, without risk to the actual communication network. At a high level, a DT is a digital counterpart or model of an actual real-world physical product, system, or process (often referred to as “physical twin’), which is effectively indistinguishable for practical purposes such as simulation, integration, testing, monitoring, and maintenance. For example, a DT of a communication network is a software (e.g., cloud-based) representation of the assets, information, and processes present in the physical communication network (or portions thereof). As a more specific example, a network DT can be used to model “invisible” aspects of the communication network, such as radio signals, coverage, interference, traffic behavior, and user mobility.

[0012] Figure 1 shows a high-level view of an exemplary DT of a cellular network (e.g., 5G). The DT shown in Figure 1 includes a database (110) that can store measurements and configuration management (CM) parameters for each of the cells, The DT also includes various behavioral models (120) that compute relevant metrics - also known as key performance indicators (KPIs) - for each cell based on the measurements and CM parameters. These behavioral models are conventionally hosted in a centralized computing environment (130), such as in a private or public cloud computing environment,

[0013] SUMMARY

[0014] Even though DTs for cellular networks can facilitate network optimization based on RL, they also have various problems, issues, or drawbacks. For example, these DTs require significant centralized computational resources, which increase according to the size of the network being modeled. Thus, scaling the DT requires tradeoffs between increased execution time versus expense of installing (e.g., for private cloud) or leasing (e.g., for public cloud) extra computing resources. Centralized DTs also require significant communication resources for collecting measurements from all the network elements (e.g., base stations) and cen tralized storage resources for storing the collected measurements. All of these requirements add to the complexity and expense of conventional network DTs.

[0015] An object of embodiments of the present disclosure is to address these and other problems, issues, and / or drawbacks by providing efficient distributed (or decentralized) network DT architectures, thereby facilitating the otherwise advantage use of network DTs.

[0016] Some embodiments include methods {e.g., procedures) performed by a remote node of a distributed DT for a communication network comprising a plurality of cells of which a subset is associated with the remote DT node.

[0017] These exemplary methods include receiving an indication of a configuration change for at least one cell of the subset. These exemplary methods also include, based on the configuration change, executing an initial phase of a behavioral model representative of at least the subset of cells, thereby generating an initial result. These exemplary methods also include at least one of the following operations:

[0018] • sending the initial result to a central DT node or to one or more other remote DT nodes associated with respective one or more other subsets of the cells. • receiving, from the one or more other remote DT nodes, respective initial results generated by execution of behavioral models for the respective other subsets, based on the configuration change.

[0019] In some embodiments, the indication of the configuration change is received from the central DT node together with a request to execute the behavioral model based on the configuration change. In some of these embodiments, the initial result generated by execution of the initial phase includes one or more key performance indicator (KPI) components, with each KPI component being associated with one or more KPIs, and the one or more KPI components are sent to the central DT node.

[0020] In other of these embodiments, the initial result generated by execution of the initial phase includes predicted measurements for at least a portion of the subset of cells. Also, the predicted measurements are sent to the one or more other remote nodes together with an indication of the configuration change for at least one cell of the subset.

[0021] In other embodiments, the indication of the configuration change is received from an agent in the communication network together with a request for a performance metric associated with the configuration change. In some of these embodiments, the agent is a reinforcement learning (RL) agent and the performance metric comprises a reward metric and a state update.

[0022] In some of these embodiments, the initial result generated by execution of the initial phase includes one or more KPI components, with each KPI component being associated with one or more KPIs. Also, the respective initial results received from the one or more other remote DT nodes include respective other KPI components, with each other KPI component being associated with at least one of the one or more KPIs.

[0023] In other of these embodiments, the initial result generated by execution of the initial phase includes predicted measurements for at least a portion of the subset of cells. The predicted measurements are sent to the one or more other remote nodes together with an indication of the configuration change for at least one cell of the subset.

[0024] In some embodiments, the remote DT node is hosted or implemented by a RAN node that serves the subset of cells. In other embodiments, the remote DT node is hosted or implemented by a virtualized central unit (vCU) in a cloud RAN architecture. In other embodiments, the remote DT node is hosted or implemented by one of the following in an Open RAN architecture: a Near-Real Time RAN Intelligent Controller (RIG), or a service management and orchestration (SMO) function.

[0025] Other embodiments include methods (e.g., procedures) performed by a central node of a distributed DT for a communication network comprising a plurality of cells.

[0026] These exemplary methods include receiving, from an agent in the communication network, an indication of a configuration change for at least a portion of the cells and a request for a performance metric associated with the configuration change. These exemplary methods also include sending the indication of a configuration change to a plurality of remote DT nodes associated with respective subsets of the plurality of cells. These exemplary methods also include receiving, from the plurality of remote DT nodes, results from execution by the remote DT nodes of respective behavioral models representative of the respective subsets of the plurality of cells . These exemplary methods also include determining the performance metric associated with the configuration change based on the received results. In some embodiments, the results received from each remote DT node include one or more KPIs for the subset of cells associated with the remote DT node, and the performance metric is determined based on the received one or more KPIs.

[0027] In other embodiments, the results received from each remote DT node include one or more KPI components, with each KPI component being associated with one or more KPIs for the subset of cells associated with the remote DT node. Additionally, determining the performance metric includes the following operations:

[0028] • for each KPI of the one or more KPIs, executing a final phase of the behavioral model to generate the

[0029] KPI based on the received components of the KPI; and

[0030] • determining the performance metric based on the generated one or more KPIs.

[0031] In some embodiments, the communication network utilizes a cloud RAN architecture and each remote DT node is hosted or implemented by a virtualized central unit (vCU) of the cloud RAN. Also, the central DT node is hosted or implemented by a network management (NM) node or function.

[0032] In other embodiments, the communication network utilizes an Open RAN architecture and the central DT node is hosted or implemented in a service management and orchestration (SMO) function in the Open RAN. Also, each remote DT node is hosted or implemented by one of the following in the Open RAN: the SMO function, or a Near-Real Time RAN Intelligent Controller (RIO).

[0033] Other embodiments include remote DT nodes and central DT nodes (or network equipment configured to implement such nodes) that are configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments include non-transitory, computer-readable media storing program instructions that, when executed by processing circuitry, configure remote DT nodes or central DT nodes to perform operations corresponding to any of the exemplary methods described herein.

[0034] These and other embodiments described herein can provide various benefits and / or advantages, especially when compared to conventional centralized network DTs. For example, by distributing behavioral model calculations, embodiments may reduce the transmission resources and / or capacity needed for DT -related signaling in the communication network and / or the storage capacity needed at a central DT node. As another example, by utilizing existing processing and storage resources in RAN nodes, embodiments reduce and / or eliminate the need to deploy a private cloud or lease resources in a public cloud. All of these improvements may result in reduced cost of operation and improved scalability of network DTs.

[0035] These and other objects, features, and advantages of embodiments of the present disclosure will become apparent upon reading the following Detailed Description in view of the Drawings briefly described below.

[0036] BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 shows a high-level view of an exemplary DT of a cellular network.

[0038] Figures 2-3 show two high-level views of an exemplary 5G / NR network architecture.

[0039] Figure 4 shows a logical architecture for an NG-RAN node arranged in a split CU / DU architecture.

[0040] Figure 5 illustrates how an exemplary reinforcement learning (RL) agent interacts with its environment.

[0041] Figures 6-7 show block diagrams of network DTs according to various embodiments of the present disclosure. Figures 8-11 show signaling diagrams for various procedures according to different implementation options for embodiments of the present disclosure.

[0042] Figure 12 shows a high-level diagram of an Open RAN (O-RAN) architecture in which some embodiments of the present disclosure may be implemented.

[0043] Figure 13 shows an exemplary method (e.g, procedure) for a remote DT node, according to various embodiments of the present disclosure.

[0044] Figure 14 shows an exemplary method (e.g., procedure) for a central DT node, according to various embodiments of the present disclosure.

[0045] Figure 15 shows a communication system according to various embodiments of the present disclosure.

[0046] Figure 16 shows a network node according to various embodiments of the present disclosure.

[0047] Figure 17 shows host computing system according to various embodiments of the present disclosure.

[0048] Figure 18 is a block diagram of a virtualization environment in which functions implemented by some embodiments of the present disclosure may be virtualized.

[0049] DETAILED DESCRIPTION

[0050] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0051] In general, all terms used herein are to be interpreted according to their ordinary meaning to a person of ordinary skill in the relevant technical field, unless a different meaning is expressly defined and / or implied from the context of use. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise or clearly implied from the context of use. The operations of any methods and / or procedures disclosed herein do not have to be performed in the exact order disclosed, unless an operation is explicitly described as following or preceding another operation and / or where it is implicit that an operation must follow or precede another operation. Any feature of any embodiment disclosed herein can apply to any other disclosed embodiment, as appropriate. Likewise, any advantage of any embodiment described herein can apply to any other disclosed embodiment, as appropriate.

[0052] The term "radio access network node” (shortened to "RAN node”) used herein may refer to any node in a radio access network (RAN) that wirelessly transmits and / or receives signals, and / or facilitates such transmission and / or reception. Some examples of a RAN node include, but are not limited to, a base station (e.g., high-power, low- power, macro, micro, femto, home, etc.), a gNB in a 5G / NR NG-RAN, an eNB in a 4G / LTE E-UTRAN, base station distributed components (e.g., CU and DU), an integrated access backhaul (IAB) node, a transmission point (TP), a transmission reception point (TRP), a remote radio unit (e.g., RRU, RRH), and a relay node.

[0053] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is generally used. However, the concepts disclosed herein are not limited to a 3GPP system, and can be applied in any system that can benefit from the concepts, principles, and / or embodiments described herein.

[0054] Figure 2 illustrates a high-level view of an exemplary 5G network architecture, which includes a Next Generation Radio Access Network (NG-RAN, 299) and a 5G Core (5GC, 298). The NG-RAN can include one or more gNodeB's (gNBs, e.g., 200, 250) connected to the 5GC via one or more NG interfaces (e.g., 202, 252). More specifically, the gNBs can be connected to one or more Access and Mobility Management Functions (AMFs) in the 5GC via respective NG-C interfaces and to one or more User Plane Functions (UPFs) in the 5GC via respective NG- U interfaces. Various other network functions (NFs) can be included in the 5GC, as described in more detail below.

[0055] In addition, the gNBs can be connected to each other via one or more Xn interfaces (e.g., 240 between gNBs 200, 250). The radio technology for the NG-RAN is often referred to as "New Radio” (NR). With respect to the NR interface to UEs, each of the gNBs can support frequency division duplexing (FDD), time division duplexing (TDD), or a combination thereof. Each of the gNBs can serve a geographic coverage area including one or more cells and, in some cases, can also use various directional beams to provide coverage in the respective cells.

[0056] NG RAN logical nodes shown in Figure 2 include a Centralized Unit (CU or gNB-CU) and one or more Distributed Units (DU or gNB-DU). CUs {e.g., 210) are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. In contrast, DUs {e.g., 220, 230) are decentralized logical nodes that host lower layer protocols and can include various subsets of gNB functions, depending on the functional split. A CU connects to one or more DUs over respective F1 logical interfaces (e.g., 222, 232 in Figure 2).

[0057] Figure 3 shows another high-level view of an exemplary 5G network architecture, including an NG-RAN (399) and a 5GC (398). As shown in the figure, the NG-RAN can include gNBs {e.g., 310a, b) and ng-eNBs {e.g., 320a, b) that are interconnected with each other via respective Xn interfaces. An ng-eNB is similar to a fourth generation (4G) Long-Term Evolution (LTE) eNB, except that it supports the Xn and NG interfaces rather than corresponding X2 and S1 interfaces.

[0058] The gNBs and ng-eNBs are also connected via the NG interfaces to the 5GC, more specifically to AMFs ( e.g., 330a, b) via respective NG-C interfaces and to UPFs {e.g., 340a, b) via respective NG-U interfaces. Moreover, the AMFs can communicate with one or more policy control functions (PCFs, e.g., 350a, b) and network exposure functions (NEFs, e.g., 360a, b).

[0059] Each of the gNBs can support the NR radio interface including frequency division duplexing (FDD), time division duplexing (TDD), or a combination thereof. Each of ng-eNBs can support the 4G / LTE radio interface. Each of the gNBs and ng-eNBs can serve a geographic coverage area including one or more cells (e.g., 311 a-b and 321 a-b). Depending on the cell in which it is located, UEs (e.g., 305) can communicate with the gNB or ng-eNB serving that cell via the NR or LTE radio interface, respectively. Although Figure 3 shows gNBs and ng-eNBs separately, it is also possible that a single NG-RAN node provides both LTE and NR functionality.

[0060] Figure 4 shows a logical architecture for an NG-RAN node (e.g., gNB or ng-eNB) arranged in the split CU / DU architecture, such as gNBs and ng-eNBs shown in Figures 2-3. This logical architecture separates the CU into CP and UP functionality, called CU-CP and CU-UP respectively. Furthermore, each of the NG, Xn, and F1 interfaces is split into a CP interface (e.g., NG-C) and a UP interface (e.g., NG-U). Moreover, CU-UP and CU-CP can communicate via an E1 interface. Each DU may be connected to only one CU-CP, and each CU-UP may be connected to only one CU- CP. However, a single DU may be connected to multiple CU-UPs under the control of the same CU-CP, or a single CU-UP may be connected to multiple DUs under the control of the same CU-CP. Note that the terms "Central Entity” and "Distributed Entity” in Figure 4 refer to physical network nodes.

[0061] As mentioned above, reinforcement learning (RL) can be used for operational optimization of communication networks, such as the exemplary 5G networks shown in Figures 2-3. An RL agent accumulates knowledge about the dynamics of its environment (e.g., the communication network) through different interactions that may result in positive or negative outcomes. For training, the RL agent interacts with the environment by repeatedly observing its state and then - based on the knowledge available to the RL agent at each stage - taking actions intended to maximize a long-term reward based on defined criteria. In each iteration, the RL agent will learn from the outcome of the suggested actions and will become increasingly "wiser”.

[0062] Figure 5 illustrates how an exemplary RL agent (504) interacts with its environment (502) in the context of a Markov Decision Process. The environment can be one or more cells that have a set of states (S) and that produce a reward r for the RL agent. The RL agent- via its learning module (506) - interacts with the environment at discrete time instances. At each time instance f, the RL agent receives an observation Of, which typically includes the reward rt. The RL agent then selects an action a? from a set of available actions A and applies the selected action to the environment. The probability of a transition from state s at time t to state s' at time f+1 under action atis given by:

[0063] P(s, a, s’) = Pr (SM = s' | Sf =s, a? = a) (1) and an immediate reward after a transition from s to s' under action at is given by: r (s, a, s’) . (2)

[0064] The environment moves to a new state st+i and the reward +1 associated with the transition (s?, at, Sf+i) is determined. The goal of the RL agent is to collect as much reward as possible. The selection of the action by the agent is modelled by a "policy map” given by:

[0065] The policy map gives the probability of the RL agent selecti ng action a when in state s. Given state s, action a, and policy TT, the action-value of the pair (s, a) under policy TT is defined by: where the random variable R denotes the return, and is defined as the sum of future discounted rewards: where rt is the reward at instance t and 0 < y < 1 is the discount rate.

[0066] The theory of Markov Decision Processes states that if TT* is an optimal policy, taking the optimal action is carried out by choosing the action from CT* with the highest value at each state s. The action-value function of such optimal policy (CT*) is also called the optimal action-value function and is commonly denoted Q*. In summary, the optimal action-value function Q* provides the RL agent sufficient knowledge for how to act optimally.

[0067] Training the RL agent involves learning the Q(s, a) function for all possible states and actions. For example, the set of actions A may be relatively small (e.g., maintain, increase, decrease), but the state is composed of N continuous features, giving an infinite number of possible states. A tabular function for Q may not be the most appropriate approach for this agent. Although a continuous / discrete converter might be included as a first layer, the usage of a deep neural network (DNN) may be more suitable for the RL agent's learning process, because DNNs handle continuous features directly.

[0068] Even so, training RL agents (or other types of ML models) for operation in a complex communication network poses some challenges, For example, it can be risky to allow an RL agent to take actions to accumulate needed knowledge based on dynamics of its environment - a live communication network - when such actions can negatively impact the operation of the communication network. Negative outcomes that result in downtime of the communication network and user services are unacceptable in practice.

[0069] As briefly mentioned above, a DT of a communication network is a software (e.g., cloud-based) representation of the assets, information, and processes present in the physical communication network (or portions thereof). As a more specific example, a DT can be used to model “invisible" aspects of the communication network, such as radio signals, coverage, interference, traffic behavior, and user mobility, in the context of ML, DTs have been used to provide a simulated testing environment in which an ML model (e.g., RL agent) can be trained via initiating “what-if’ actions and observing reward (e.g., outcomes) due to these actions, without risk to the actual communication network.

[0070] As illustrated in Figure 1 , a DT may include various behavioral models, each of which is a software representation of some portion of the assets, information, and processes of a physical communication network. For example, each behavioral model may compute relevant metrics - also known as KPIs - for one or more ceils based on measurements and configuration management (CM) parameters for the respective cells. These behavioral models are conventionally hosted in a centralized computing environment (130), such as in a private or public cloud computing environment. Implementation-wise, each behavioral model may be an ML model or a less complex set of rules / operations for calculating KPIs from the collected measurements and CM parameters. An RL agent's action can be a change in CM parameters used by the DT's behavioral model(s), with the RL agent maximizing a reward determined from the KPIs produced by the DT.

[0071] As a more specific example, a DT for a cellular network may include a behavioral model that computes a Geometry Factor (or G-Factor) KPI after a maximum transmit power change has been applied to several cells. This KPI is a function of UE reference signal received power (RSRP) measurements of the relevant cells (i.e., UE serving cell and its neighbor cells) and the old / new values of the maximum transmission power in the relevant cells. This behavioral model may compute a new G-Factor KPI for each UE measurement about the relevant cells after the transmit power change.

[0072] Even though DTs for cellular networks can facilitate network optimization based on RL, they also have various problems, issues, or drawbacks. For example, these DTs require significant centralized computational resources, which increase according to the size of the network being modeled. Thus, scaling the DT requires tradeoffs between increased execution time versus expense of installing (e.g., for private cloud) or leasing (e.g., for public cloud) extra computing resources.

[0073] Centralized DTs also require significant communication resources for collecting measurements and other raw data (referred to as “call trace records” or CTR) from all the RAN nodes (e.g., base stations) and centralized storage resources for storing the collected measurements. For example, CTR data is stored by each RAN node at a rate of approximately 10 megabytes (MB) every 15 minutes. For a network of 1000 RAN nodes and a busy period of 4 hours, 160 gigabytes (GB) of data must be transferred to the centralized DT. If the central DT has a normal 10 megabit-per-second (Mb / s) data connection, the transfer itself would require more than 35 hours as well as enough storage capacity to hold the collected data. Much like computing resources, scaling communication resources requires tradeoffs between latency and expense.

[0074] Embodiments of the present disclosure address these and other problems, issues, and / or difficulties by novel, flexible, and efficient distributed architectures for network DTs that reduce execution complexity at DT nodes as well as the transfer of data between DT nodes. In embodiments of the distributed architecture, a RAN node implements or hosts a remote (or distributed) DT node and manages its collected radio measurements (e.g., from served UEs). In many cases, the RAN node has all the data needed for its remote DT node so there is no need to transfer measurements. Nevertheless, a lightweight central DT node may be used to manage data transfer for cases in which parameters from different remote DT nodes change simultaneously. The central DT node may also include an application programming interface (API) that facilitates queries of the network DT by external entities (e.g., RL agent). Embodiments also include techniques for determining which of the remote DT nodes are affected by a parameter change in one or more other remote DT nodes.

[0075] In this manner, embodiments utilize RAN node (e.g., eNB, gNB, CU, DU) resources for most of the data storage and computation required by a network DT. In general, this represents a small added burden for each RAN node but collectively improves scalability by reducing the required transmission and processing resources needed external to the RAN nodes. Although some additional extra transmission bandwidth is needed for signaling among RAN nodes and with a central DT node, this extra bandwidth is very small required to bandwidth needed to transmit all the measurements to a central DT in conventional solutions.

[0076] Embodiments also include methods (e.g., procedures) for executing the behavioral models of the network DT in a distributed manner. Two different scenarios are considered: execution of behavioral models triggered locally at the nodes, or triggered centrally. Moreover, different embodiments are provided for generic DTs and for more specific DTs utilizing behavioral models that facilitate efficient distributed calculations of KPIs. For example, distributed KPI components can be calculated independently in different remote DT nodes, with the KPI components send to a central DT node to be aggregated for calculation of the KPI.

[0077] A more specific example of distributed KPI calculation is for dropped call rate, which is the ratio of the aggregated number of dropped calls to the aggregated number of ended calls. In embodiments of t he present disclosure, each remote DT node calculates its component of the numerator (number of dropped calls) and the denominator (number of ended calls) over a period of interest, and then sends these numerator and denominator components to the central DT node. The central DT node sums the received numerator and denominator components and calculates the final dropped call rate KPI based on the ratio of the numerator and denominator sums.

[0078] Embodiments also include methods (e.g., procedures) for exchanging information between remote DT nodes and with a central DT node. Such methods may utilize 3GPP-specified inter-node interfaces, such as X2 (for eNBs), Xn (for gNBs), E2 (for O-RAN), etc. Embodiments can provide various benefits and / or advantages, especially when compared to conventional centralized network DTs. For example, by distributing behavioral model calculations, embodiments may reduce the transmission resources and / or capacity needed for DT-related signaling in the communication network and / or the storage capacity needed at a central DT node. As another example, by utilizing existing processing and storage resources in RAN nodes, embodiments reduce and / or eliminate the need to deploy a private cloud or lease resources in a public cloud. All of these improvements may result in reduced cost of operation and improved scalability of network DTs.

[0079] Furthermore, embodiments may provide increased accuracy of calculated KPIs relative to centralized network DTs. For example, using an ML model as a centralized network DT necessitates some approximations and loss of information in the KPI calculations. In contrast, even when embodiments of the present disclosure utilize a central DT node, the KPIs (or their components) are calculated by the remote DT nodes in an exact manner based on the behavioral model(s) and the collected measurements.

[0080] As used herein, the term "remote DT node” and "central DT node” refer to portions of a distributed architecture of a network DT. Each remote DT node includes behavioral models that represent certain behavior of a subset or portion of the communication network, such as one or more cells. In contrast, a central DT node (if present) performs some amount of coordination of operations by multiple remote DT nodes, such as by triggering remote DT node operations and / or by collecting / receiving outputs of remote DT node behavioral models.

[0081] A remote DT node may be considered "remote” based on being physically or logically distinct from other remote DT nodes that represent behavior of other subsets or portions of the communication network, and from any central DT nodes. A central DT node may be considered "central” based on being physically or logically distinct from remote DT nodes and by its role in coordinating remote DT nodes.

[0082] Embodiments will now be described in more detail. In general, network DT efficiency and scalability is improved the most when each RAN node implements or hosts a remote DT node and manages the collection of radio measurements for the hosted remote DT node. In this arrangement, there is often no need to transfer radio measurements among RAN nodes / remote DTs. Even so, when transferring radio measurements is necessary, the minimum amount of needed information should be transferred as close in time as possible to when it is needed by the recipient(s).

[0083] In some embodiments, a central DT node may be used to manage data transfer for cases in which parameters from different remote DTs change simultaneously. The central DT node may also include an API that facilitates queries of the network DT by external entities (e.g., RL agent). Even so, when data transfer management is not required, it is possible to avoid the need for a central DT node by providing a comparable API in the remote DT nodes.

[0084] In general, a behavioral model associated with the network DT is executed after each change of input parameter(s) to the behavioral model. In some embodiments, execution of the behavioral model can be triggered by an agent located in the central DT node. This may occur, for example, in response to parameter changes in a single remote DT node or in multiple remote DT nodes. The initiator submits queries to remote DT nodes requesting parameter changes. In other embodiments, execution of the behavioral model can be triggered by an agent located in a remote DT node. This may occur, for example, in response to parameter changes in that remote DT node (i.e., changes limited to that node). In some embodiments, each remote DT node maintains a first list of other remote DT nodes whose parameter change may impact the remote DT node. This first list is also referred to as an "impacting list”. Each remote DT node builds the first list based on measurements collected from served UEs. In other words, if a UE sends its serving RAN node (which hosts a first remote DT) a measurement report that includes measurements of a neighbor cell served by a neighbor RAN node that hosts a second remote DT, the first remote DT adds the second remote DT to its impacting (or first) list. Note that all information required for a remote DT node to build its impacting list is entirely available at that remote DT node (or the hosting RAN node).

[0085] In some embodiments, each remote DT node maintains a second list of other remote DT nodes that may be impacted by the remote DT node's parameter changes. This second list is also referred to as an "impacted list”, and indicates all other remote DT nodes that have detected the remote DT node in their collected measurements. The impacted list of a remote DT is created based on the impacting lists of other remote DTs. In the example discussed above, the first remote DT node informs the second remote DT node that it has been included in its impacting list, causing the second remote DT node to add the first remote DT node to its impacted list. This notification will occur each time a remote DT node adds another remote DT node to its impacting list. Although some inter-node signaling is required, the aggregate amount will be relatively small.

[0086] As an alternative, the impacting list and the impacted list could be obtained from the neighbor lists provided by an automatic neighbor relations (ANR) function used by RAN nodes to discover (and configure interfaces to) neighboring RAN nodes.

[0087] Different embodiments of DT behavioral model execution can depend on the following aspects: 1) type of the behavioral model, and 2) whether the execution is triggered by a remote DT or by a central DT. Various examples are discussed below.

[0088] For the case of any generic DT behavioral model, measurements are transferred between remote DTs as needed, which requires some non-negligible amount of signaling between remote DT nodes. In cases where execution is triggered at a remote DT (e.g., based on an agent demand or request for parameter update), the remote DT determines which measurements are needed by other remote DT nodes to execute the behavioral model, such as measurements that indicate UE serving cell change due to the parameter change. This determination requires running an initial phase of the behavioral model to update the measurements according to the parameter change.

[0089] The remote DT node then sends to all remote DT nodes on its impacted list the updated parameter value (e.g., provided by the requesting agent) and the updated measurements determined by the remote DT node during the initial phase. The remote DT node also requests these impacted remote DT nodes to execute the behavioral model accordingly. The remote DT node receives from these remote DT nodes the respective KPIs and measurements calculated using the behavioral model. The remote DT node then calculates its KPI applying the measurements received from the impacted remoted DT nodes to the remote DT node's behavioral model.

[0090] In cases where execution is triggered by a central DT node due to a parameter change, the central DT node sends all updated parameters to all involved remote DT nodes, which execute the behavioral model in a similar manner as described above. For example, this execution also involves each remote DT node sending impacted remote DT nodes the measurements needed by those remote DT nodes to execute their respective behavioral models based on the central DT node's indicated parameter change. Once the remote DT nodes have determined the relevant KPIs based on behavioral models, these KPIs are sent to the central DT node that triggered execution.

[0091] The number of involved remote DT nodes may vary depending on which parameters are changed and how the parameters are changed. In some cases, the behavioral model execution may need to be performed by only a few directly impacted remote DT nodes plus their indirectly impacted neighbors.

[0092] Figure 6 shows a block diagram of a network DT (600) according to some embodiments of the present disclosure, in which a central DT node triggers execution of a generic DT behavioral model (also referred to as "option 1”) based on a parameter change. The network DT includes a plurality of remote DT nodes (620, e.g., 620-1 through 620-n) and a "lightweight” central DT node (610). The central DT node has a repository (611) arranged to store cell KPIs calculated by the respective remote DT nodes, as well as a remote DT identifier function (612) arranged to trigger execution of the DT behavioral model by the remote DT nodes.

[0093] The network DT may include or be coupled to an agent (630), which may be an RL agent. The agent obtains the DT state and its reward by reading the cell KPIs from the central DT node repository. The agent sends its designated action to the central DT node, which causes the remote DT identifier to select remote DT nodes relevant to the action and trigger execution in those remote DT nodes.

[0094] For the specific type of DT behavioral models that facilitate efficient distributed calculations (also referred to as "option 2”), respective KPI components are calculated by the remote DT nodes (first phase) and then aggregated by the central DT node to obtain the KPIs (second phase). For these models, the signaling between remote DT nodes and with the central DT node is minimal.

[0095] In cases where execution of a behavioral model of this type is triggered at a remote DT (e.g., based on an agent demand or request for parameter update), the remote DT node executes the first phase of the behavioral model using its own available measurements, which produces the remote DT node's KPI component(s). The remote DT node then sends to all remote DT nodes on its impacted list a request to execute the first phase of the behavioral model based on their own available measurements. The remote DT node receives from the impacted remoted DT nodes the respective KPI components produced by this execution. The remote DT node then executes the second phase of the behavioral model by aggregating the distributed KPI components belonging to the same cell to compute the KPIs per cell.

[0096] In cases where execution of a behavioral model of this type is triggered by a central DT node due to a parameter change, the central DT node receives impacted lists from all remote DT nodes, which may occur during initialization or after list update due to new measurements. To trigger execution in response to a parameter change for one or more cells, the central DT node sends the updated parameter(s) to all remote DT nodes in the impacted lists, along with a request to execute the first phase of the behavioral model using the updated parameter(s) and their available measurements. The central DT node receives from the remote DT nodes the respective KPI components produced by this execution, and then executes the second phase of the behavioral model by aggregating the distributed KPI components to compute the KPIs.

[0097] Alternatively, each remote DT node can send the distributed KPI components it calculated in the first phase to other remote DT nodes in its impacted list. In this alternative, the second phase of the behavioral model is executed by the remote DT nodes, which provide respective KPIs (e.g., per cell) to the central DT node. Figure 7 shows a block diagram of a network DT (700) according to some embodiments of the present disclosure, in which a central DT node triggers execution of the specific type of DT behavioral model (also referred to as "option 2”) based on a parameter change. The network DT includes a plurality of remote DT nodes (720, e.g., 720- 1 through 720-n) and a central DT node (710). The central DT node includes a repository (711) arranged to store KPI components calculated by the respective remote DT nodes, as well as a remote DT identifier function (712) arranged to trigger execution of the DT behavioral model by the remote DT nodes. The central DT node also includes a processing function (713) arranged to calculate the cell KPIs based on the stored KPI components.

[0098] The network DT may include or be coupled to an agent (730), which may be an RL agent. The agent obtains the DT state and its reward by reading the cell KPIs provided by the central DT node's processing function. The agent sends its designated action to the central DT node, which causes the remote DT identifier to select remote DT nodes relevant to the action and trigger execution in those remote DT nodes.

[0099] Figure 8 shows a signaling diagram for a procedure in which execution of an option-1 behavioral model is triggered locally by a remote DT. This procedure involves three RAN nodes (840) hosting respective remote DTs (820): eNB_1 (840-1) hosting remote DT-1 (820-1) and an RL agent (830), eNB_2 (840-2) hosting remote DT-2 (820-2), and eNB_3 (840-3) hosting remote DT-3 (820-3). Optionally, remote DT-1 and the RL agent could be hosted by different nodes or functions within a network.

[0100] The RL agent sends a request to remote DT-1 indicating a parameter change, e.g., as an action or part of an action. Remote DT-1 determines the measurements that are needed by remote DT-2 to execute the behavioral model, and runs an initial phase of the behavioral model to update the measurements according to the parameter change. Remote DT-1 sends the changed parameter and the updated measurements (as necessary) to remote DT-2 but only the changed parameter to remote DT-3. If a parameter change occurs before a DT refresh involving a new collection of measurements, then it is not necessary to send the same measurements to the same remote DT again. The remote DTs may store the received information for subsequent use. Remote DT-1 then requests both other remote DTs to execute the behavioral model.

[0101] The other remote DTs execute the behavioral model according to the request, and remote DT-2 also determines the measurements that are needed by remote DT-1 to execute the behavioral model. Remote DT-2 and remote DT-3 send remote DT-1 the KPIs calculated by executing the behavioral model, and remote DT-2 also sends the measurements needed by remote DT-1. Upon receiving this information, remote DT-1 executes the final phase of the behavioral model to generate its KPIs (e.g., for served cells). Remote DT-1 then performs state and reward calculations based on the calculated and received KPIs, and sends the state and reward to the RL agent.

[0102] Figure 9 shows a signaling diagram for a procedure in which execution of an option-1 behavioral model is triggered by a central DT. This procedure involves two RAN nodes (940) hosting respective remote DTs (920): eNB_1 (940-1) hosting remote DT-1 (920-1) and eNB_2 (940-2) hosting remote DT-2 (920-2). The central DT (910) and an RL agent (930) are hosted by a central node (950), although the central DT and RL agent could also be hosted by different nodes or functions within a network.

[0103] The RL agent sends a request to the central DT including a vector of one or more parameter changes, e.g., as an action or part of an action. The central DT requests both remote DTs to execute the behavioral model and includes the changed parameter(s) provided by the RL agent. Remote DT-1 determines that measurements are needed by remote DT-2 to execute the behavioral model, and runs an initial phase of the behavioral model to update the measurements according to the parameter change. Remote DT-1 sends the changed parameter and the updated measurements (as necessary) to remote DT-2. If a parameter change occurs before a DT refresh involving a new collection of measurements, then it is not necessary to send the same measurements to the same remote DT again.

[0104] Likewise, remote DT-2 determines that measurements are needed by remote DT-1 to execute the behavioral model, and runs an initial phase of the behavioral model to update the measurements according to the parameter change. Remote DT-2 sends the changed parameter and the updated measurements to remote DT-1. Both remote DTs execute the final phase of the behavioral model based on the received measurements, and send KPIs produced by the execution to the central DT. The central DT then performs state and reward calculations based on the received KPIs, and sends the state and reward to the RL agent.

[0105] Figure 10 shows a signaling diagram for a procedure in which execution of an option-2 behavioral model is triggered locally by a remote DT. This procedure involves three RAN nodes (1040) hosting respective remote DTs (1020): eNB_1 (1040-1) hosting remote DT-1 (1020-1) and an RL agent (1030), eNB_2 (1040-2) hosting remote DT- 2 (1020-2), and eNB_3 (1040-3) hosting remote DT-3 (1020-3). Optionally, remote DT-1 and the RL agent could be hosted by different nodes or functions within a network.

[0106] The RL agent sends a request to remote DT-1 indicating a parameter change, e.g., as an action or part of an action. Remote DT-1 sends the changed parameter to remote DT-2 and remote DT-3, and requests both other remote DTs to execute the behavioral model. All remote DTs execute an initial phase of the behavioral model according to the request, with remote DT-2 and remote DT-3 sending remote DT-1 the KPI components calculated by executing the behavioral model. Upon receiving this information, remote DT-1 executes the second phase of the behavioral model to generate the KPIs (e.g., for served cells) based on the generated and received KPI components. Remote DT-1 then performs state and reward calculations based on the calculated KPIs and sends the state and reward to the RL agent.

[0107] Figure 11 shows a signaling diagram for a procedure in which execution of an option-2 behavioral model is triggered by a central DT. This procedure involves two RAN nodes (1140) hosting respective remote DTs (1120): eNB_1 (1140-1) hosting remote DT-1 (1120-1) and eNB_2 (1140-2) hosting remote DT-2 (1120-2). The central DT (1110) and an RL agent (1130) are hosted by a central node (1150), although the central DT and RL agent could also be hosted by different nodes or functions within a network.

[0108] The RL agent sends a request to the central DT including a vector of one or more parameter changes, e.g., as an action or part of an action. The central DT requests both remote DTs to execute the behavioral model and includes the changed parameter(s) provided by the RL agent. All remote DTs execute an initial phase of the behavioral model according to the requests, and send the central DT the KPI components calculated by executing the behavioral model. Upon receiving this information, the central DT executes the second phase of the behavioral model to generate the KPIs (e.g., for served cells) based on the received KPI components. The central DT then performs state and reward calculations based on the calculated KPIs and sends the state and reward to the RL agent.

[0109] Some embodiments of the present disclosure can be implemented in a cloud RAN, e.g., for a 5G network. In a 5G cloud RAN, a virtualized CU (vCU) can support up to 360 virtualized DUs (vDUs), each of which can serve up to 1024 logical cells. In some embodiments, each remote DT node can be hosted by and / or associated with a single vCU, such that each remote DT node is responsible for measurements and KPIs associated with all logical cells served by all vDUs supported by the single vCU. In other words, the vDUs supported by a vCU are physically collocated (I ,e. , hosted by same computing equipment), so that information shared between vDUs and vCU does not need to be sent via transmission resources.

[0110] In this arrangement, a remote DT hosted by a vCU will encounter few cells associated with other remote DT nodes in measurements it receives, relative to the number of cells associated with the remote DT node. Rather, a large portion of the needed measurements are from vDUs supported by the hosting vCU. This arrangement may be particularly suitable for option 1 behavioral models, which require sharing of measurements for cells associated with the impacted list.

[0111] For example, periodic measurements of radio bearer (RB) traffic per UE could be collected by each vDU and provided to the remote DT at the vCU via a network management (NM) function in the operation support system (OSS)Zbusiness support system (BSS). An example NM function is Ericsson Network Manager (ENM). As an alternative, the remote DT can be implemented as a function within the vCU. In this arrangement, the vDU can provide the measurements to the vCU via the standard F1 interface without involving the NM function, thereby eliminating extra traffic. As another alternative, the central DT can be hosted by a server external to the communication network.

[0112] In some embodiments, each remote RT node may determine partial state and reward information for an RL agent and share that partial state / reward with a central DT node, which determines the complete state / reward for the RL agent. The partial state / reward information can be compressed using an autoencoder, which is a type of artificial neural network (NN) that learns efficient coding for unlabeled data. In a variant, partial state / reward information can be shared among remote DT nodes for use in their respective state / reward calculations.

[0113] In general, embodiments can be implemented using standardized measurements and interfaces between nodes and functions in a communication network (e.g., 5G). In this manner, embodiments are suitable for multi-vendor network deployments, particularly when an included central DT node is also based on standardized measurements and interfaces.

[0114] Open RAN (O-RAN) ALLIANCE is a community of mobile operators and RAN vendors working towards an open, intelligent, virtualized, operationally efficient, and fully interoperable RANs. To achieve these goals, the community has defined an O-RAN architecture with key functions and interfaces. Various specifications published by O-RAN work groups (WGs). For example, O-RAN WG1 is concerned with use cases and overall architecture. One general principle is that O-RAN architecture and interface specifications shall be consistent with 3GPP architecture and interface specifications, to the extent possible.

[0115] Figure 12 shows an exemplary O-RAN architecture in which various embodiments can be implemented. The A1 , 01 , and 02 interfaces connect the Service Management and Orchestration function (SMO, 1210) to 0- RAN network functions (NFs) and cloud infrastructure management (O-Cloud, 1260). These O-RAN NFs include Near-Real Time RAN Intelligent Controller (RIO, 1220), Open Centralized Units (O-CUs, 1230), Open Distributed Units (O-DUs, 1250), and Open Radio Units (O-RUs, 1250). Additionally, there is an interface between SMO and external information sources.

[0116] The O-RAN Architecture also includes the following three control loops with respective latencies:

[0117] • Real Time (RT) Control Loop (<10 ms), typically in O-RU / O-DU; • Near-RT RIC Control Loop (10-1000 ms), in Near-RT RIC; and

[0118] • Non-RT RIC Control Loop (>1000 ms), shown as sub-block 1012 in SMC.

[0119] Use cases for Non-RT RIC and Near-RT RIC control loops are fully defined by O-RAN, but O-RAN only defines relevant interactions with other O-RAN nodes or functions for the RT control loop (which performs radio scheduling, HARQ, beamforming, etc.).

[0120] The Non-RT RIC provides the A1 interface to the Near-RT RIC. One task of Non-RT RIC is to provide policybased guidance, ML model management, and enrichment information to support intelligent RAN optimization by the Near-RT RIC (e.g., for radio resource management, RRM). The Non-RT RIC can also perform intelligent RRM in longer, non-RT intervals (e.g., greater than 1 second).

[0121] The Non-RT RIC can use data analytics and ML model training / inference to determine RAN optimizations, for which it can leverage SMC services such as data collection from and provisioning to the O-RAN nodes. These actions are performed by Non-RT RIC RAN Applications (rApps, e.g., 1211), which are exposed to Non-RT RIC functionality and services via the R1 interface in SMC.

[0122] In embodiments of the present disclosure, a central DT can be implemented as an rApp (e.g., 1211) in the SMC while a remote DT can be implemented within the Near-RT RIC (e.g., as a block, function, or xApp 1221) or within the O-CU (e.g., in O-CU-CP). This arrangement enables the remote DT to collect measurements from O-DUs via the F1 interface (e.g., F1 -c) and to provide measurements to the central DT via the E2 interface. Note that an RL agent may also be implemented as an rApp in the SMC, thereby facilitating communication with the central DT. Alternately, one or more remote DTs can be implemented as rApps in the SMC.

[0123] Various features of the embodiments described above correspond to various operations illustrated in Figures 13-14, which show exemplary methods {e.g., procedures) for a remote DT node and a central DT node, respectively. In other words, various features of the operations described below correspond to various embodiments described above. Furthermore, the exemplary methods shown in Figures 13-14 can be used cooperatively to provide various benefits, advantages, and / or solutions to problems described herein. Although Figures 13-14 show specific blocks in particular orders, the operations of the exemplary methods can be performed in different orders than shown and can be combined and / or divided into blocks having different functionality than shown. Optional blocks or operations are indicated by dashed lines.

[0124] In particular, Figure 13 shows an exemplary method (e.g., procedure) performed by a remote node of a distributed digital twin (DT) for a communication network comprising a plurality of cells of which a subset is associated with the remote DT node, according to various embodiments of the present disclosure. The exemplary method can be performed by a remote DT node (or network equipment configured to implement a remote DT node) such as described elsewhere herein.

[0125] The exemplary method includes the operations of block 1310, where the remote DT node receives an indication of a configuration change for at least one cell of the subset. The exemplary method can also include the operations of block 1330, where based on the configuration change, the remote DT node executes an initial phase of a behavioral model representative of at least the subset of cells, thereby generating an initial result. The exemplary method also includes at least one of the following operations, labelled with corresponding block numbers: • (1360) send the initial result to a central DT node or to one or more other remote DT nodes associated with respective one or more other subsets of the cells.

[0126] • (1370) receive, from the one or more other remote DT nodes, respective initial results generated by execution of behavioral models for the respective other subsets, based on the configuration change.

[0127] In some embodiments, the indication of the configuration change is received from the central DT node together with a request to execute the behavioral model based on the configuration change. The centrally-triggered arrangements discussed above are examples of these embodiments. In some of these embodiments, the initial result generated by execution of the initial phase includes one or more key performance indicator (KPI) components, with each KPI component being associated with one or more KPIs, and the one or more KPI components are sent to the central DT node. An example of these embodiments is the centrally-triggered option-2 arrangement discussed above.

[0128] In other of these embodiments, the initial result generated by execution of the initial phase includes predicted measurements for at least a portion of the subset of cells. Also, the predicted measurements are sent to the one or more other remote nodes together with an indication of the configuration change for at least one cell of the subset. An example of these embodiments is the centrally-triggered option-1 arrangement discussed above.

[0129] In other embodiments, the indication of the configuration change is received from an agent in the communication network together with a request for a performance metric associated with the configuration change. The locally-triggered arrangements discussed above are examples of these embodiments. In some of these embodiments, the agent is a reinforcement learning (RL) agent and the performance metric comprises a reward metric and a state update.

[0130] In some of these embodiments, the initial result generated by execution of the initial phase includes one or more KPI components, with each KPI component being associated with one or more KPIs. Also, the respective initial results received from the one or more other remote DT nodes include respective other KPI components, with each other KPI component being associated with at least one of the one or more KPIs. An example of these embodiments is the locally-triggered option-2 arrangement discussed above.

[0131] In some variants of these embodiments, the exemplary method also includes the operations of block 1380, where based on the generated KPI components and the received other KPI components, the remote DT node execute a final phase of the behavioral model to generate the one or more KPIs. In some further variants, for each KPI of the one or more KPIs, the generated KPI components include a numerator component and a denominator component, and the respective initial result received from the one or more other remote DT nodes include respective other numerator components and respective other denominator components (i.e., associated with the KPI). Furthermore, for each KPI, executing the final phase of the behavioral model in block 1380 includes the following operations, labelled with corresponding sub-block numbers:

[0132] • (1381) combining the generated numerator components and received other numerator components, associated with the KPI, to obtain a KPI numerator;

[0133] • (1382) combining the generated denominator components and the received other denominator components, associated with the KPI, to obtain a KPI denominator; and

[0134] • (1383) dividing the KPI numerator by the KPI denominator to generate the KPI. In some further variants, the exemplary method can also include the following operations, labelled with corresponding block numbers:

[0135] • (1390) based on the one or more KPIs, generating the performance metric associated with the configuration change; and

[0136] • (1395) sending the performance metric to the agent in response to the request.

[0137] In other of these embodiments, the initial result generated by execution of the initial phase includes predicted measurements for at least a portion of the subset of cells, and the predicted measurements are sent to the one or more other remote nodes together with an indication of the configuration change for at least one cell of the subset. An example of these embodiments is the locally-triggered option-2 arrangement discussed above.

[0138] In some embodiments, the exemplary method also includes the operations of block 1350, where the remote DT node sends, to the one or more other remote DT nodes, respective requests to execute the initial phase of the behavioral models for the respective other subsets. Examples of these embodiments include the locally-triggered arrangements discussed above.

[0139] In some embodiments, the exemplary method also includes the operations of block 1340, where based on an impacted list, the remote DT node determines the one or more other remote DT nodes, associated with the respective other subsets of the cells, which are affected by the configuration change for the at least one cell . Examples of these embodiments are the option-1 arrangements discussed above.

[0140] In some of these embodiments, the initial results received from the one or more other remote DT nodes include predicted measurements for cells of the respective other subsets. The exemplary method also includes the operations of block 1380, where based on the received predicted measurements, the remote DT node executes a final phase of the behavioral model to generate one or more key performance indicators (KPIs) for the subset of cells.

[0141] In some variants of these embodiments, the exemplary method also includes the operations of block 1385, where the remote DT node sends the one or more KPIs to the central DT node. In other variants of these embodiments, the exemplary method also includes the following operations, labelled with corresponding block numbers:

[0142] • (1390) based on the one or more KPIs, generating a performance metric associated with the configuration change; and

[0143] • (1395) sending the performance metric to an agent in the communication network.

[0144] In some further variants, the agent is a reinforcement learning (RL) agent and the performance metric comprises a reward metric and a state update. In some further variants, the predicted measurements are received from the one or more other remote DT nodes together with KPIs for the respective other subsets, and generating the performance metric in block 1390 is further based on the KPIs for the respective other subsets.

[0145] In some embodiments, the exemplary method can also include the operations of block 1320, where the remote DT node can obtain measurements for the subset of cells. In such case, executing the initial phase of the behavioral model in block 1330 is further based on the obtained measurements.

[0146] In some embodiments, the remote DT node is hosted or implemented by a RAN node that serves the subset of cells. In other embodiments, the remote DT node is hosted or implemented by a virtualized central unit (vCU) in a cloud RAN architecture. In other embodiments, the remote DT node is hosted or implemented by one of the following in an Open RAN architecture: a Near-Real Time RAN Intelligent Controller (RIG), or a service management and orchestration (SMO) function.

[0147] In addition, Figure 14 shows an exemplary method (e.g., procedure) performed by a central node of a distributed DT for a communication network comprising a plurality of cells, according to various embodiments of the present disclosure. The exemplary method can be performed by a central DT node (or network equipment configured to implement a central DT node) such as described elsewhere herein.

[0148] The exemplary method includes the operations of block 1410, where the central DT node receives, from an agent in the communication network, an indication of a configuration change for at least a portion of the cells and a request for a performance metric associated with the configuration change. The exemplary method also includes the operations of block 1420, where the central DT node sends the indication of a configuration change to a plurality of remote DT nodes associated with respective subsets of the plurality of cells. The exemplary method also includes the operations of block 1430, where the central DT node receives, from the plurality of remote DT nodes, results from execution by the remote DT nodes of respective behavioral models representative of the respective subsets of the plurality of cells The exemplary method also includes the operations of block 1440, where the central DT node determines the performance metric associated with the configuration change based on the received results.

[0149] In some embodiments, the results received from each remote DT node include one or more KPIs for the subset of cells associated with the remote DT node, and the performance metric is determined based on the received one or more KPIs. An example of these embodiments is the centrally-triggered option-1 arrangement discussed above.

[0150] In other embodiments, the results received from each remote DT node include one or more KPI components, with each KPI component being associated with one or more KPIs for the subset of cells associated with the remote DT node. Additionally, determining the performance metric in block 1440 includes the following operations, labelled with corresponding sub-block numbers:

[0151] • (1441) for each KPI of the one or more KPIs, executing a final phase of the behavioral model to generate the KPI based on the received components of the KPI; and

[0152] • (1442) determining the performance metric based on the generated one or more KPIs.

[0153] An example of these embodiments is the centrally-triggered option-2 arrangement discussed above. In some of these embodiments, for each KPI of the one or more KPIs, the results received from each remote DT node include a numerator component and a denominator component. Also, for each KPI of the one or more KPIs, executing the final phase of the behavioral model in sub-block 1441 includes the following operations:

[0154] • combining the received numerator components to obtain a KPI numerator;

[0155] • combining the received denominator components to obtain a KPI denominator; and

[0156] • dividing the KPI numerator by the KPI denominator to generate the KPI.

[0157] In some embodiments, the exemplary method also includes the operations of block 1450, where the central DT node sends the determined performance metric to the agent. In some embodiments, the agent is a RL agent and the performance metric comprises a reward metric and a state update. In some embodiments, each remote DT node is hosted or implemented by a radio access network (RAN) node that serves the associated subset of cells.

[0158] In some embodiments, the communication network utilizes a cloud RAN architecture and each remote DT node is hosted or implemented by a virtualized central unit (vCU) of the cloud RAN . Also, the central DT node is hosted or implemented by a network management (NM) node or function .

[0159] In other embodiments, the communication network utilizes an Open RAN architecture and the central DT node is hosted or implemented in a service management and orchestration (SMO) function in the Open RAN . Also, each remote DT node is hosted or implemented by one of the following in the Open RAN: the SMO function, or a Near-Real Time RAN Intelligent Controller (RIO).

[0160] Although various embodiments are described herein above in terms of methods, apparatus, devices, computer-readable medium and receivers, the person of ordinary skill will readily comprehend that such methods can be embodied by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, etc.

[0161] Figure 15 shows an example of a communication system 1500 in accordance with some embodiments. In this example, communication system 1500 includes a telecommunication network 1502 that includes an access network 1504 (e.g., RAN) and a core network 1506, which includes one or more core network nodes 1508. Access network 1504 includes one or more access network nodes, such as network nodes 151 Oa-b (one or more of which may be generally referred to as network nodes 1510), or any other similar 3GPP access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, telecommunication network 1502 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in telecommunication network 1502 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in telecommunication network 1502, including one or more network nodes 1510 and / or core network nodes 1508.

[0162] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective "open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1 , W1, E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. Network nodes 1510 facilitate direct or indirect connection of UEs, such as by connecting UEs 1512a-d (one or more of which may be generally referred to as UEs 1512) to core network 1506 over one or more wireless connections.

[0163] In some embodiments, telecommunication network 1502 can also include one or more Network Management (NM) nodes 1518, which can be part of an operation support system (OSS), a business support system (BSS), and / or an operation / administration / maintenance (OAM) system. The NM nodes can monitor and / or control operations of other nodes in access network 1504 and core network 1506. Although not shown in Figure 15, NM node 1518 is configured to communicate with other nodes in access network 1504 and core network 1506 for these purposes.

[0164] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, communication system 1500 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. Communication system 1500 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0165] UEs 1512 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with network nodes 1510 and other communication devices. Similarly, network nodes 1510 are arranged, capable, configured, and / or operable to communicate directly or indirectly with UEs 1512 and / or with other network nodes or equipment in telecommunication network 1502 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in telecommunication network 1502.

[0166] In the depicted example, core network 1506 connects network nodes 1510 to one or more hosts, such as host 1516. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1506 includes one or more core network nodes (e.g., 1508) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of core network node 1508. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0167] Host 1516 may be under the ownership or control of a service provider other than an operator or provider of access network 1504 and / or telecommunication network 1502, and may be operated by the service provider or on behalf of the service provider. Host 1516 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. In some embodiments, access network 1504 can include a service management and orchestration (SMO) system or node 1520, which can monitor and / or control operations of the access network nodes 1510. This arrangement can be used, for example, when access network 1504 utilizes an O-RAN architecture. SMO system 1520 can be configured to communicate with core network 1506 and / or host 1516, as shown in Figure 15.

[0168] In some embodiments, one or more of core network node 1508, host 1516, NM node 1518, and SMO system 1520 can be configured to perform various operations of exemplary methods (e.g., procedures) performed by a remote DT node or by a central DT node, such as described above in relation to other figures.

[0169] As a whole, communication system 1500 of Figure 15 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0170] In some examples, telecommunication network 1502 is a cellular network that implements 3GPP standardized features. Accordingly, telecommunication network 1502 may support network slicing to provide different logical networks to different devices that are connected to telecommunication network 1502. For example, telecommunication network 1502 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC)ZMassive loT services to yet further UEs.

[0171] In some examples, UEs 1512 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to access network 1504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from access network 1504. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0172] In the example, hub 1514 communicates with access network 1504 to facilitate indirect communication between one or more UEs (e.g., 1512c and / or 1512d) and network nodes (e.g., network node 1510b). In some examples, hub 1514 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, hub 1514 may be a broadband router enabling access to core network 1506 for the UEs. As another example, hub 1514 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1510, or by executable code, script, process, or other instructions in hub 1514. As another example, hub 1514 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, hub 1514 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, hub 1514 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which hub 1514 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, hub 1514 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0173] Figure 16 shows a network node 1600 in accordance with some embodiments. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (e.g., radio base stations, Node Bs, eNBs, gNBs), and O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0174] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0175] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multistandard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi- cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, and positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs))).

[0176] In some embodiments, network node 1600 can be configured to perform various operations of exemplary methods {e.g., procedures) performed by a remote DT node or by a central DT node, such as described above in relation to other figures.

[0177] Network node 1600 includes processing circuitry 1602, memory 1604, communication interface 1606, and power source 1608. Network node 1600 may be composed of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which network node 1600 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, network node 1600 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1604 for different RATs) and some components may be reused (e.g., a same antenna 1610 may be shared by different RATs). Network node 1600 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1600, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1600.

[0178] Processing circuitry 1602 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1600 components, such as memory 1604, to provide network node 1600 functionality.

[0179] In some embodiments, processing circuitry 1602 includes a system on a chip (SOC). In some embodiments, processing circuitry 1602 includes radio frequency (RF) transceiver circuitry 1612 and / or baseband processing circuitry 1614. In some embodiments, RF transceiver circuitry 1612 and baseband processing circuitry 1614 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1612 and / or baseband processing circuitry 1614 may be on the same chip or set of chips, boards, or units.

[0180] Memory 1604 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by processing circuitry 1602. Memory 1604 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions (collected denoted computer program 1604a, which may be in the form of a computer program product) capable of being executed by processing circuitry 1602 and utilized by network node 1600. Memory 1604 may be used to store any calculations made by processing circuitry 1602 and / or any data received via communication interface 1606. In some embodiments, processing circuitry 1602 and memory 1604 is integrated.

[0181] Communication interface 1606 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, communication interface 1606 comprises port(s) / terminal (s) 1616 to send and receive data, for example to and from a network over a wired connection. Communication interface 1606 also includes radio front-end circuitry 1618 that may be coupled to, or in certain embodiments a part of, antenna 1610. Radio front-end circuitry 1618 comprises filters 1620 and amplifiers 1622. Radio front-end circuitry 1618 may be connected to an antenna 1610 and processing circuitry 1602. The radio front-end circuitry may be configured to condition signals communicated between antenna 1610 and processing circuitry 1602. Radio front-end circuitry 1618 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. Radio frontend circuitry 1618 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1620 and / or amplifiers 1622. The radio signal may then be transmitted via antenna 1610. Similarly, when receiving data, antenna 1610 may collect radio signals which are then converted into digital data by radio front-end circuitry 1618. The digital data may be passed to processing circuitry 1602. In other embodiments, the communication interface may comprise different components and / or different combinations of components. In certain alternative embodiments, network node 1600 does not include separate radio front-end circuitry 1618, instead, processing circuitry 1602 includes radio front-end circuitry and is connected to antenna 1610. Similarly, in some embodiments, all or some of RF transceiver circuitry 1612 is part of communication interface 1606. In still other embodiments, communication interface 1606 includes one or more ports or terminals 1616, radio front-end circuitry 1618, and RF transceiver circuitry 1612, as part of a radio unit (not shown), and communication interface 1606 communicates with baseband processing circuitry 1614, which is part of a digital unit (not shown).

[0182] Antenna 1610 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. Antenna 1610 may be coupled to radio front-end circuitry 1618 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, antenna 1610 is separate from network node 1600 and connectable to network node 1600 through an interface or port.

[0183] Antenna 1610, communication interface 1606, and / or processing circuitry 1602 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a U E, another network node and / or any other network equipment. Similarly, antenna 1610, communication interface 1606, and / or processing circuitry 1602 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0184] Power source 1608 provides power to the various components of network node 1600 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 1608 may further comprise, or be coupled to, power management circuitry to supply the components of network node 1600 with power for performing the functionality described herein. For example, network node 1600 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of power source 1608. As a further example, power source 1608 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0185] Embodiments of network node 1600 may include additional components beyond those shown in Figure 16 for providing certain aspects of the network node's functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1600 may include user interface equipment to allow input of information into network node 1600 and to allow output of information from network node 1600. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 1600.

[0186] Figure 17 is a block diagram of a host 1700, which may be an embodiment of host 1516 of Figure 15, in accordance with various aspects described herein. Host 1700 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm.

[0187] Host 1700 includes processing circuitry 1702 that is operatively coupled via a bus 1704 to an input / output interface 1706, a network interface 1708, a power source 1710, and a memory 1712. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figure 18, such that the descriptions thereof are generally applicable to the corresponding components of host 1700.

[0188] Memory 1712 may include one or more computer programs including one or more host application programs 1714 and data 1716, which may include user data, e.g., data generated by a UE for host 1700 or data generated by host 1700 for a UE. Embodiments of host 1700 may utilize only a subset or all of the components shown. Host application programs 1714 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (WC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAG, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). Host application programs 1714 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, host 1700 may select and / or indicate a different host for over-the-top services for a UE. Host application programs 1714 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0189] In some embodiments, host 1700 can be configured to perform various operations of exemplary methods {e.g., procedures) performed by a remote DT node or by a central DT node, such as described above in relation to other figures.

[0190] Figure 18 is a block diagram illustrating a virtualization environment 1800 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1800 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1800 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0191] Applications 1802 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1800 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. In some embodiments, one or more applications 1802 can be configured to perform various operations of exemplary methods {e. , procedures) performed by a remote DT node or by a central DT node, such as described above in relation to other figures. Hardware 1804 includes processing circuitry, memory that stores software and / or instructions (collected denoted computer program 1804a, which may be in the form of a computer program product) executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1806 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1808a-b (one or more of which may be generally referred to as VMs 1808), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. Virtualization layer 1806 may present a virtual operating platform that appears like networking hardware to VMs 1808.

[0192] VMs 1808 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1806. Different embodiments of the instance of a virtual appliance 1802 may be implemented on one or more of VMs 1808, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0193] In the context of NFV, each VM 1808 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each VM 1808, and that part of hardware 1804 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1808 on top of hardware 1804 and corresponds to application 1802.

[0194] Hardware 1804 may be implemented in a standalone network node with generic or specific components. Hardware 1804 may implement some functions via virtualization. Alternatively, hardware 1804 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration function 1810, which, among others, oversees lifecycle management of applications 1802. In some embodiments, hardware 1804 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1812 which may alternatively be used for communication between hardware nodes and radio units.

[0195] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

[0196] The term unit, as used herein, can have conventional meaning in the field of electronics, electrical devices and / or electronic devices and can include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

[0197] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0198] As described herein, device and / or apparatus can be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device or apparatus, instead of being hardware implemented, be implemented as a software module such as a computer program or a computer program product comprising executable software code portions for execution or being run on a processor. Furthermore, functionality of a device or apparatus can be implemented by any combination of hardware and software. A device or apparatus can also be regarded as an assembly of multiple devices and / or apparatuses, whether functionally in cooperation with or independently of each other. Moreover, devices and apparatuses can be implemented in a distributed fashion throughout a system, so long as the functionality of the device or apparatus is preserved. Such and similar principles are considered as known to a skilled person.

[0199] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0200] In addition, certain terms used in the present disclosure, including the specification and drawings, can be used synonymously in certain instances (e.g, "data” and "information”). It should be understood, that although these terms (and / or other terms that can be synonymous to one another) can be used synonymously herein, there can be instances when such words can be intended to not be used synonymously.

Claims

CLAIMS1 . A method performed by a remote node of a distributed digital twin, DT, for a communication network comprising a plurality of cells of which a subset is associated with the remote DT node, the method comprising: receiving (1310) an indication of a configuration change for at least one cell of the subset; based on the configuration change, executing (1330) an initial phase of a behavioral model representative of at least the subset of cells, thereby generating an initial result; and performing at least one of the following operations: sending (1360) the initial result to a central DT node or to one or more other remote DT nodes associated with respective one or more other subsets of the cells; and receiving (1370), from the one or more other remote DT nodes, respective initial results generated by execution of behavioral models for the respective other subsets, based on the configuration change.

2. The method of claim 1 , wherein the indication of the configuration change is received from the central DT node together with a request to execute the behavioral model based on the configuration change.

3. The method of any of claims 1-2, wherein: the initial result generated by execution of the initial phase includes one or more key performance indicator, KPI, components, with each KPI component being associated with one or more KPIs; and the one or more KPI components are sent to the central DT node.

4. The method of any of claims 1-2, wherein: the initial result generated by execution of the initial phase includes predicted measurements for at least a portion of the subset of cells; and the predicted measurements are sent to the one or more other remote nodes together with an indication of the configuration change for at least one cell of the subset.

5. The method of claim 1 , wherein the indication of the configuration change is received from an agent in the communication network together with a request for a performance metric associated with the configuration change.

6. The method of claim 5, wherein the agent is a reinforcement learning, RL, agent and the performance metric comprises a reward metric and a state update.

7. The method of any of claims 5-6, wherein:the initial result generated by execution of the initial phase includes one or more key performance indicator, KPI, components, with each KPI component being associated with one or more KPIs; and the respective initial results received from the one or more other remote DT nodes include respective other KPI components, with each other KPI component being associated with at least one of the one or more KPIs.

8. The method of claim 7, further comprising, based on the generated KPI components and the received other KPI components, executing (1380) a final phase of the behavioral model to generate the one or more KPIs .

9. The method of claim 8, wherein for each KPI of the one or more KPIs: the generated KPI components include a numerator component and a denominator component; the respective initial result received from the one or more other remote DT nodes include respective other numerator components and respective other denominator components; and executing (1380) the final phase of the behavioral model comprises: combining (1381) the generated numerator components and received other numerator components, associated with the KPI, to obtain a KPI numerator; combining (1382) the generated denominator components and the received other denominator components, associated with the KPI, to obtain a KPI denominator; and dividing (1383) the KPI numerator by the KPI denominator to generate the KPI.

10. The method of any of claims 8-9 further comprising: based on the one or more KPIs, generating (1390) the performance metric associated with the configuration change; and sending (1395) the performance metric to the agent in response to the request.11 . The method of any of claims 5-6, wherein the initial result generated by execution of the initial phase includes predicted measurements for at least a portion of the subset of cells; and the predicted measurements are sent to the one or more other remote nodes together with an indication of the configuration change for at least one cell of the subset.

12. The method of any of claims 5 and 11 , further comprising sending (1350), to the one or more other remote DT nodes, respective requests to execute the initial phase of the behavioral models for the respective other subsets.

13. The method of any of claims 1-2, 4, and 11-12, further comprising, based on an impacted list, determining (1340) the one or more other remote DT nodes, associated with the respective other subsets of the cells, which are affected by the configuration change for the at least one cell.

14. The method of any of claims 1-2, 4, and 11-13, wherein: the initial results received from the one or more other remote DT nodes include predicted measurements for cells of the respective other subsets; and the method further comprises, based on the received predicted measurements, executing a final phase of the behavioral model to generate one or more key performance indicators, KPIs, for the subset of cells.

15. The method of claim 14, further comprising sending (1385) the one or more KPIs to the central DT node.

16. The method of claim 14, further comprising: based on the one or more KPIs, generating (1390) a performance metric associated with the configuration change; and sending (1395) the performance metric to an agent in the communication network.

17. The method of claim 16, wherein the agent is a reinforcement learning, RL, agent and the performance metric comprises a reward metric and a state update.

18. The method of any of claims 16-17, wherein: the predicted measurements are received from the one or more other remote DT nodes together with KPIs for the respective other subsets; and generating (1390) the performance metric is further based on the KPIs for the respective othe r subsets.

19. The method of any of claims 1 -18, further comprising obtaining (1320) measurements for the subset of cells, wherein executing (1330) the initial phase of the behavioral model is further based on the obtained measurements.

20. The method of any of claims 1-19, wherein the remote DT node is hosted or implemented by one of the following: a radio access network, RAN, node that serves the subset of cells; a virtualized central unit, vCU, in a cloud RAN architecture; and one of the following in an Open RAN architecture: a Near-Real Time RAN Intelligent Controller, RIG; or a service management and orchestration, SMO, function.21 . A method performed by a central node of a distributed digital twin, DT, for a communication network comprising a plurality of cells, the method comprising: receiving (1410), from an agent in the communication network, an indication of a configuration change for at least a portion of the cells and a request for a performance metric associated with the configuration change; sending (1420) the indication of a configuration change to a plurality of remote DT nodes associated with respective subsets of the plurality of cells; receiving (1430), from the plurality of remote DT nodes, results from execution by the remote DT nodes of respective behavioral models representative of the respective subsets of the plurality of cells; and determining (1440) the performance metric associated with the configuration change based on the received results.

22. The method of claim 21, wherein: the results received from each remote DT node include one or more key performance indicators, KPI, for the subset of cells associated with the remote DT node; and the performance metric is determined based on the received one or more KPIs.

23. The method of claim 21, wherein: the results received from each remote DT node include one or more key performance indicator, KPI, components, with each KPI component being associated with one or more KPIs for the subset of cells associated with the remote DT node; and determining (1440) the performance metric comprises: for each KPI of the one or more KPIs, executing (1441) a final phase of the behavioral model to generate the KPI based on the received components of the KPI; and determining (1442) the performance metric based on the generated one or more KPIs.

24. The method of claim 23, wherein for each KPI of the one or more KPIs: the results received from each remote DT node include a numerator component and a denominator component; and executing (1441) the final phase of the behavioral model comprises: combining the received numerator components to obtain a KPI numerator; combining the received denominator components to obtain a KPI denominator; and dividing the KPI numerator by the KPI denominator to generate the KPI.

25. The method of any of claims 21 -24, further comprising sending (1450) the determined performance metric to the agent.

26. The method of any of claims 21 -25, wherein the agent is a reinforcement learning, RL, agent and the performance metric comprises a reward metric and a state update.

27. The method of any of claims 21 -26, wherein each remote DT node is hosted or implemented by a radio access network, RAN, node that serves the associated subset of cells.

28. The method of any of claims 21 -27, wherein: the communication network utilizes a cloud radio access network, RAN, architecture; each remote DT node is hosted or implemented by a virtualized central unit, vCU, of the cloud RAN; and the central DT node is hosted or implemented by a network management, NM, node or function.

29. The method of any of claims 21 -27, wherein: the communication network utilizes an Open Radio Access Network, RAN, architecture; the central DT node is hosted or implemented in a service management and orchestration, SMO, function in the Open RAN; and each remote DT node is hosted or implemented by one of the following in the Open RAN: the SMO function; or a Near-Real Time RAN Intelligent Controller, RIO.

30. Network equipment (200, 250, 310, 320, 840, 940, 1040, 1140, 1220, 1510, 1600, 1800) configured to implement a remote node (620, 720, 820, 920, 1020, 1120, 1221) of a distributed digital twin, DT, for a communication network (299, 399, 1502) comprising a plurality of cells of which a subset is associated with the remote DT node, the network equipment comprising: communication interface circuitry (1606, 1804) configured to communicate with one or more other remote DT nodes associated with other subsets of the plurality of cells; and processing circuitry (1602, 1804) that is operably coupled to the communication interface circuitry, whereby the processing circuitry and the communication interface circuitry are configured to: receive an indication of a configuration change for at least one cell of the subset ; based on the configuration change, execute an initial phase of a behavioral model representative of at least the subset of cells, thereby generating an initial result; and perform at least one of the following operations: send the initial result to a central DT node or to one or more other remote DT nodes associated with respective one or more other subsets of the cells; and receive, from the one or more other remote DT nodes, respective initial results generated by execution of behavioral models for the respective other subsets, based on the configuration change.31 . The network equipment of claim 30, wherein the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to any of claims 2-20.

32. Network equipment (200, 250, 310, 320, 840, 940, 1040, 1140, 1220, 1510, 1600, 1800) configured to implement a remote node (620, 720, 820, 920, 1020, 1120, 1221) of a distributed digital twin, DT, for a communication network (299, 399, 1502) comprising a plurality of cells of which a subset is associated with the remote DT node, the network equipment being further configured to: receive an indication of a configuration change for at least one cell of the subset ; based on the configuration change, execute an initial phase of a behavioral model representative of at least the subset of cells, thereby generating an initial result; and perform at least one of the following operations: send the initial result to a central DT node or to one or more other remote DT nodes associated with respective one or more other subsets of the cells; and receive, from the one or more other remote DT nodes, respective initial results generated by execution of behavioral models for the respective other subsets, based on the configuration change.

33. The network equipment of claim 32, being further configured to perform operations corresponding to any of claims 2-20.

34. A non-transitory, computer-readable medium (1604, 1804) storing computer-executable instructions that, when executed by processing circuitry (1602, 1804) associated with a remote node (620, 720, 820, 920, 1020, 1120, 1221) of a distributed digital twin, DT, for a communication network (299, 399, 1502) comprising a plurality of cells of which a subset is associated with the remote DT node, configure the remote DT node to perform operations corresponding to any of the methods of claims 1-20.

35. A computer program product (1604a, 1804a) comprising computer-executable instructions that, when executed by processing circuitry (1602, 1804) associated with a remote node (620, 720, 820, 920, 1020, 1120, 1221) of a distributed digital twin, DT, for a communication network (299, 399, 1502) comprising a plurality of cells of which a subset is associated with the remote DT node, configure the remote DT node to perform operations corresponding to any of the methods of claims 1-20.

36. Network equipment (200, 250, 310, 320, 950, 1150, 1210, 1510, 1516, 1518, 1520, 1600, 1700, 1800) configured to implement a central node (610, 710, 910, 1110, 1211) of a distributed digital twin, DT, for a communication network (299, 399, 1502) comprising a plurality of cells, the network equipment comprising: communication interface circuitry (1606, 1708, 1804) configured to communicate with one or more other remote DT nodes associated with other subsets of the plurality of cells; and processing circuitry (1602, 1702, 1804) that is operably coupled to the communication interface circuitry, whereby the processing circuitry and the communication interface circuitry are configured to:receive, from an agent (504, 730, 930, 1130) in the communication network, an indication of a configuration change for at least a portion of the cells and a request for a performance metric associated with the configuration change; send the indication of a configuration change to a plurality of remote DT nodes (720, 920, 1120, 1221) associated with respective subsets of the plurality of cells; receive, from the plurality of remote DT nodes, results from execution by the remote DT nodes of respective behavioral models representative of the respective subsets of the plurality of cells; and determine the performance metric associated with the configuration change based on the received results.

37. The network equipment of claim 36, wherein the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to any of claims 22-29.

38. Network equipment (200, 250, 310, 320, 950, 1150, 1210, 1510, 1516, 1518, 1520, 1600, 1700, 1800) configured to implement a central node (610, 710, 910, 1110, 1211) of a distributed digital twin, DT, for a communication network (299, 399, 1502) comprising a plurality of cells, the network equipment being further configured to: receive, from an agent (504, 730, 930, 1130) in the communication network, an indication of a configuration change for at least a portion of the cells and a request for a performance metric associated with the configuration change; send the indication of a configuration change to a plurality of remote DT nodes (720, 920, 1120, 1221) associated with respective subsets of the plurality of cells; receive, from the plurality of remote DT nodes, results from execution by the remote DT nodes of respective behavioral models representative of the respective subsets of the plurality of cells; and determine the performance metric associated with the configuration change based on the received results.

39. The network equipment of claim 38, being further configured to perform operations corresponding to any of claims 22-29.

40. A non-transitory, computer-readable medium (1604, 1702, 1804) storing computer-executable instructions that, when executed by processing circuitry (1602, 1702, 1804) associated with a central node (610, 710, 910, 1110, 1211) of a distributed digital twin, DT, for a communication network (299, 399, 1502) comprising a plurality of cells, configure the remote DT node to perform operations corresponding to any of the methods of claims 21-29.

41. A computer program product (1604a, 1714, 1804a) comprising computer-executable instructions that, when executed by processing circuitry (1602, 1702, 1804) associated with a central node (610, 710, 910, 1110, 1211) of a distributed digital twin, DT, for a communication network (299, 399, 1502) comprising a plurality of cells, configure the remote DT node to perform operations corresponding to any of the methods of claims 21-29.

Images