Method and apparatus for fault injection analysis based on network digital twinning

Abstract

A network node, a network system, a computer readable medium, and a method for supporting detection and / or diagnosis of network anomalies in a target communication network are described herein. The network nodes are configured to support detection and / or diagnosis of network anomalies in a network digital twin (NDT)-based target communication network, the NDT emulating at least a portion of the target communication network, where the first network node comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first network node to at least: provide at least one anomalous injection case generated based on the simulated configuration to a second network node at which the NDT is provided, and / or configure the at least one anomalous injection case in an NDT; receiving, from the second network node, a simulation signature and / or an anomaly diagnosis of a simulation of an anomaly injection case on the NDT; and deploying diagnostic knowledge generated based on the received analog signature and / or anomaly diagnosis for the target communication network in a network anomaly detection function (NADF), and / or providing anomaly diagnosis to the target communication network.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for network digital fault injection analysis, in particular, fault injection analysis based on network digital twins. Background Art

[0002] Any discussion of the background art throughout the specification should not be considered as an admission that such art is widely known or forms part of the common general knowledge in the field.

[0003] Network anomaly detection and diagnosis can be a powerful tool, but common approaches present significant challenges. First, anomalies are by definition rare events, and therefore building a comprehensive diagnostic knowledge base is time-consuming and requires network experts to participate in the classification and analysis of newly discovered anomaly events. Second, anomalies are not necessarily failures, nor are they necessarily any other relevant events in the network. Many detected anomalies can be unrelated to network operation or management, but are simply unusual. For example, a football game may cause an abnormal peak load, but if it does not cause congestion, there is no need to notify operators. Analysis of irrelevant anomalies is costly and reduces the value of anomaly detection. Third, an ideal network anomaly detection system is also able to detect unforeseen anomalies. Building network anomaly detection systems by leveraging supervised techniques, i.e., involving labeled anomaly detection training datasets, runs counter to this goal because it requires many known and different anomaly samples.

[0004] One way to analyze a network is to use fault injection. Fault injection is the act of intentionally interfering with the functionality of a network component by introducing misconfigurations, simulated failures, or other changes in expected behavior. Knowing the root cause of the injection, the network behavior can be monitored and measured, and based on these measurements, faults can be fingerprinted for later detection and diagnosis. However, it also has disadvantages that limit its usability in mobile networks:

[0005] In particular, common fault injection is usually not feasible on operational (live) networks where network QoS cannot be compromised. In addition, fault injection in isolated test cases (such as a single network element in a lab) does not produce the widespread impact of network element failures in real large-scale network deployments. These isolated injections may also not produce patterns that can be used for anomaly detection and diagnosis in real-time deployments. Network simulators can be used to simulate the effects of injected faults. However, since faults are usually very specific to a certain network deployment and its environment, simulated anomaly patterns usually cannot be transferred to real network anomaly detection.

[0006] To alleviate the above problems in network anomaly detection, many solutions have been proposed. The network diagnostic cloud concept proposes to use transfer learning to transfer network anomaly event diagnostic knowledge between networks or deployments to speed up the collection of diagnostic knowledge base. However, such transfer is not simple, because each network deployment is different, and the same anomaly pattern and diagnosis may not be applicable to different networks. Transfer between networks is by no means easy and has limited the data available for diagnosis.

[0007] Another alternative is to use active learning to reduce the workload of manual diagnosis. In this solution, the diagnosed and undiagnosed anomaly patterns in the diagnostic knowledge base are clustered to find samples of undiagnosed anomaly patterns that operators want to diagnose and that are most beneficial for future automatic diagnosis. However, it cannot determine whether the proposed anomaly patterns are actually relevant to network operations. In addition, this approach has the risk of incorrectly clustering anomalies with different root causes together, which may lead to diagnostic errors.

[0008] In summary, anomalies in communication networks are rare events, and traditional anomaly detection is time-consuming, requires the participation of network experts, and is not 100% accurate. Therefore, it is necessary to develop an accurate and efficient anomaly detection and diagnosis method. Summary of the invention

[0009] The independent claims define the scope of protection sought by various example embodiments of the present disclosure. Example embodiments and features described in this specification that do not fall within the scope of the independent claims, if any, are to be construed as examples that aid in understanding the various example embodiments of the present disclosure.

[0010] The network nodes mentioned in the present disclosure may be network elements. A network element (such as a communication element) may be a terminal device, a control element or a function, such as an access network element, such as a base station / BS, a gNB, a radio network controller, a core network control element or function (such as a gateway element), or other network elements or functions described herein, UE, and any other element, function, or application may be implemented by software (e.g., by a computer program product of a computer) and / or hardware. In order to perform its corresponding processing, the correspondingly used equipment, node, function or network element may include several components, modules, units, components, etc. (not shown) required for control, processing and / or communication / signaling functions.

[0011] According to the present disclosure, a first network node may be provided, the first network node being configured to support detection and / or diagnosis of network anomalies in a target communication network based on a network digital twin NDT, the NDT simulating at least a portion of the target communication network, wherein the first network node comprises:

[0012] at least one processor; and

[0013] At least one memory storing instructions, which when executed by the at least one processor, cause the first network node to at least:

[0014] providing at least one anomaly injection case generated based on the simulation configuration to the second network node, and / or configuring at least one anomaly injection case in the NDT, the NDT being provided at the second network node;

[0015] receiving a simulation signature and / or anomaly diagnosis of a simulation of an anomaly injection case on the NDT from a second network node; and

[0016] The diagnostic knowledge generated based on the received simulation signature and / or anomaly diagnosis is deployed for the target communication network in the network anomaly detection function NADF, and / or anomaly diagnosis is provided to the target communication network.

[0017] In some examples, the anomaly injection case is a fault injection case indicating a network fault condition, and wherein providing the anomaly injection case to the second network node includes injecting a fault in the set of fault injection cases into the NDT to simulate an impact of the fault.

[0018] In some examples, the first network node is initialized by an operations, administration, and maintenance (OAM) entity to enhance detection and diagnostic capabilities of the NADF, and the first network node is further caused to:

[0019] injecting one or more diagnosed root causes of the anomaly into the NDT to simulate the impact of the root cause, wherein the root cause is the most appropriate cause of the anomaly signature that caused the selected event; and

[0020] The diagnostic anomaly signature of the NADF is compared to the received simulation signature to calibrate the received simulation signature provided by the second network node.

[0021] In some examples, the anomaly injection case is a fault injection case indicating a network fault condition, and wherein providing at least one anomaly injection case comprises: injecting a fault in a set of fault injection cases into the NDT to simulate the impact of the fault, and the first network node is further caused to:

[0022] obtaining a first simulation signature for each anomaly injection case in at least one anomaly injection case;

[0023] obtaining a first signature of the root cause for each of at least one diagnosed root cause of an anomaly in the target communication network;

[0024] injecting at least one diagnostic root cause of the anomaly into the NDT to simulate an impact of the root cause, and obtaining a second simulation signature for each of the at least one diagnostic root cause of the anomaly;

[0025] The first signature of the root cause and the second simulated signature are compared to calibrate the first simulated signature provided by the second network node.

[0026] In some examples, the anomaly injection case is a fault injection case indicating a network fault condition, and wherein after configuring at least one anomaly injection case in the NDT provided at the second network node, the first network node is further caused to:

[0027] obtaining a first simulation signature for each anomaly injection case in at least one anomaly injection case;

[0028] obtaining a first signature of the root cause for each of at least one diagnosed root cause of an anomaly in the target communication network;

[0029] injecting at least one diagnostic root cause of the anomaly into the NDT to simulate an impact of the root cause, and obtaining a second simulation signature for each of the at least one diagnostic root cause of the anomaly;

[0030] A third simulated signature is obtained for each of the at least one diagnostic root cause of the anomaly in the target communication network.

[0031] The first signature of the root cause and the second simulated signature are compared to calibrate the first simulated signature provided by the second network node.

[0032] In some examples, deploying the diagnostic knowledge includes deploying the received simulation signature for each of the at least one anomaly injection case in the NADF for use in the target communication network.

[0033] In some examples, deploying diagnostic knowledge in the NADF and / or providing abnormal diagnosis to the target communication network to trigger one or more self-healing actions of the target communication network includes:

[0034] training a supervised classification machine learning model in the first network node based on the received simulated signature, and providing the trained classification machine learning model to the NADF for anomaly detection in the target communication network; or

[0035] The received simulated signature is reported to the NADF for use in training the NADF's supervised classification machine learning model based on the received simulated signature.

[0036] In some examples, the first network node is further caused to read a simulation configuration from the second network node and generate one or more fault injection cases based on the simulation configuration.

[0037] In some examples, the first network node is further caused to configure fault injection in the second network node, wherein at the first network node, the faults are pre-selected to recreate a particular anomalous set or pattern of measurements; and

[0038] wherein the first network node is further caused to request a fault diagnosis, the fault diagnosis comprising a report from the second network node for the fault diagnosis;

[0039] receiving a requested report from the second network node, the requested report comprising at least one of: a performed fault diagnosis, a list of measurements, and a simulated signature of at least one of the injected anomalies; and

[0040] The diagnostic anomaly signature of the NADF is compared to the received fault diagnostic and / or simulation signature to calibrate the diagnostics provided by the second network node.

[0041] In some examples, the first network node is further configured to provide, in particular directly provide, fault diagnosis to the target communication network to trigger self-healing actions of the real communication network, wherein the first network node is further configured to store the fault diagnosis in a diagnostic knowledge base for abnormal event diagnosis.

[0042] In some examples, the anomaly includes at least one of: a communication network failure, a communication network parameter deviation, a dysfunction of one or more network components, a list of predetermined failure scenarios, a heuristic and / or random exploration of the network, and a simulation configuration of an NDT simulation.

[0043] In some examples, the first network node is an operations, administration and maintenance (OAM) entity and the second network node is a base station or a core network entity or a network management entity; and / or

[0044] The first network node is the network anomaly detection function network digital twin management service consumer NADF NDTMnS consumer, and the second network node is the network digital twin management service producer NADF NDT MnS consumer.

[0045] In some examples, the received simulated signature is simulated in the NDT at the second network node.

[0046] In some examples, the NDT is a representation of at least a portion of a target network, which is a real-world network including one or more of: a subnet, a geographic area, a single cell, a group of cells, selected features synchronized between the target communication network and the NDT, a simulation model of the communication network and its operating environment and / or the application services it carries.

[0047] According to a second aspect of the present disclosure, there is provided a second network node configured to support detection and / or diagnosis of network anomalies in a target communication network based on a network digital twin NDT, the NDT simulating at least a portion of the target communication network, wherein the second network node comprises:

[0048] at least one processor; and

[0049] At least one memory storing instructions, which when executed by the at least one processor, cause the first network node to at least:

[0050] providing a configuration for generating an anomaly injection case to the first network node, and / or receiving at least one anomaly injection case generated based on the simulation configuration from the first network node; and

[0051] Simulate the impact of injection anomalies on NDT in a set of abnormal injection cases; and

[0052] A simulation signature and / or anomaly diagnosis of the simulation of the anomaly injection case on the NDT is reported to the first network node.

[0053] In some examples, the anomaly injection cases are fault injection cases indicating a network fault condition, and wherein the first network node and / or the second network node is caused to inject faults in a set of fault injection cases into the NDT to simulate the impact of the faults, the NDT being provided at the second network node.

[0054] In some examples, the second network node is further caused to:

[0055] receiving one or more diagnosed root causes of the anomaly, and simulating the impact of the one or more root causes on the NDT, wherein the root cause is the most appropriate cause of the anomaly signature that caused the selected event; and

[0056] A simulation signature indicating at least the impact of the root cause is reported to the first network node for calibration.

[0057] In some examples, the anomaly injection case is a fault injection case indicative of a network fault condition, and the second network node is further caused to:

[0058] Based on a fault of at least one abnormal injection case injected by the first network node or the second network node, simulating an impact of the fault on the NDT to obtain a first simulation signature;

[0059] Based on the diagnosed root cause of the at least one anomaly, simulating an effect of the at least one root cause on the NDT to obtain a second simulated signature; and

[0060] The first simulated signature and the second simulated signature are reported to the first network node for calibration.

[0061] In some examples, the second network node is further configured to simulate injected faults and provide diagnosis of potential root causes to perform fault diagnosis, wherein fault diagnosis is provided for past faults or ongoing faults, wherein the second network node is further configured to trigger data collection from the target network to support ongoing diagnosis.

[0062] In some examples, the second network node is further caused to provide the simulation configuration to the first network node, the first network node generating the set of fault injection cases based on the simulation configuration.

[0063] In some examples, the second network node is further caused to receive a simulation configuration of at least one anomaly injection case from the first network node, and to generate the at least one anomaly injection case.

[0064] In some examples, the second network node is also caused to trigger receipt of data from the target communication network to further support diagnostics.

[0065] According to a third aspect of the present disclosure, a network system is provided, which has a management and maintenance OAM entity, a network digital twin NDT, a first network node and a second network node, wherein the first network node complies with the first aspect of the present disclosure, and the second network node is configured according to the second aspect of the present disclosure, and the NADF is deployed using data received by the OAM, and the OAM is configured to initialize the first network node or the second network node.

[0066] According to a fourth aspect of the present disclosure, there is provided a method for supporting detection and / or diagnosis of network anomalies in a target communication network based on a network digital twin NDT, the NDT simulating at least a portion of the target communication network, wherein the method comprises:

[0067] providing at least one anomaly injection case generated based on the simulation configuration to the second network node, and / or configuring at least one anomaly injection case in the NDT, the NDT being provided at the second network node;

[0068] receiving a simulation signature and / or anomaly diagnosis of a simulation of an anomaly injection case on the NDT from a second network node; and

[0069] In the network anomaly detection function NADF, diagnostic knowledge generated based on the received simulation signature and / or anomaly diagnosis is deployed for the target communication network, and / or anomaly diagnosis is provided to the target communication network to trigger one or more self-healing actions of the target communication network.

[0070] According to a fifth aspect of the present disclosure, there is provided a method for supporting detection and / or diagnosis of network anomalies in a target communication network based on a network digital twin NDT, the NDT simulating at least a portion of the target communication network, wherein the method comprises:

[0071] providing a configuration for generating an anomaly injection case to the first network node, and / or receiving at least one anomaly injection case generated based on the simulation configuration from the first network node; and

[0072] Simulate the impact of injection anomalies on NDT in a set of abnormal injection cases; and

[0073] A simulation signature and / or anomaly diagnosis of the simulation of the anomaly injection case on the NDT is reported to the first network node.

[0074] According to a sixth aspect of the present disclosure, there is provided a computer-readable medium having instructions stored thereon, which, when executed by at least one processing unit of a machine, causes the machine to execute the method according to the fourth aspect or the fifth aspect of the present disclosure.

[0075] In addition, according to some other example embodiments, for example, a computer program product for a wireless communication device is provided, the product comprising at least one processor, the at least one processor comprising a software code portion, the software code portion being used to perform the corresponding steps disclosed in the present disclosure when the product is run on the device. The computer program product may include a computer-readable medium having the above-mentioned software code portion stored thereon. In addition, the computer program product may be directly loaded into the internal memory of the computer, and / or sent via a network by means of at least one process in the upload, download and push processes.

[0076] Although some example embodiments will be described herein with particular reference to the above-mentioned applications, it will be appreciated that the present disclosure is not limited to such fields of use and is applicable in a wider context.

[0077] It is worth noting that it should be understood that the method according to the present disclosure relates to a method of operating a device according to the above-mentioned example embodiment and its variations, and the corresponding statements made about the device are also applicable to the corresponding method, and vice versa, so similar descriptions can be omitted for the sake of brevity. In addition, even if not explicitly disclosed, the above aspects can be combined in various ways. Those skilled in the art will understand that the combination of these aspects and features / steps is possible unless it produces a contradiction that is explicitly excluded.

[0078] Implementation of the disclosed apparatus may include the use of, but is not limited to, one or more processors, one or more application specific integrated circuits (ASICs), and / or one or more field programmable gate arrays (FPGAs). Implementation of the apparatus may also include the use of other conventional and / or custom hardware, such as a software programmable processor, such as a graphics processing unit (GPU) processor.

[0079] Other and further example embodiments of the present disclosure will become apparent during the following discussion and by reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] Example embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0081] Figure 1 An overview of a typical network anomaly detection and diagnosis solution is schematically illustrated;

[0082] Figure 2 Schematically illustrates the anomaly level calculation and anomaly pattern;

[0083] Figure 3 Schematically illustrates enhanced abnormality diagnosis based on active learning;

[0084] Figure 4 Schematically illustrates an overview of an example implementation of the network digital twin-based fault injection analysis of the present disclosure;

[0085] Figure 5 Schematically illustrates a first example implementation of the network digital twin-based fault injection analysis of the present disclosure;

[0086] Figure 6 schematically illustrates a second example implementation of the network digital twin-based fault injection analysis of the present disclosure; and

[0087] Figure 7 A third example implementation of the network digital twin-based fault injection analysis of the present disclosure is schematically illustrated. DETAILED DESCRIPTION

[0088] In the following, different exemplary embodiments will be described using a communication network architecture based on 3GPP standards (such as 5G / NR) as an example of a communication network to which the embodiments can be applied, without limiting the embodiments to such an architecture. It is clear to those skilled in the art that the embodiments can also be applied to other types of communication networks in which the mobile communication principles are integrated with D2D (device to device) or V2X (vehicle to everything) configurations, such as SL (side link), e.g. Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), Personal Communications Service (PCS), Wideband Code Division Multiple Access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad hoc networks (MANET), wired access, etc. In addition, without loss of generality, the description of some examples of the embodiments is related to mobile communication networks, but the principles of the present disclosure can be extended and applied to any other type, such as wired communication networks.

[0089] The following examples and embodiments should be understood as illustrative examples only. Although the specification may refer to "one", "an" or "some" examples or embodiments in multiple places, this does not necessarily mean that each such reference is related to the same (multiple) examples or (multiple) embodiments, nor does it necessarily mean that the feature applies only to a single example or embodiment. Individual features of different embodiments may also be combined to provide other embodiments. In addition, terms such as "including" and "comprising" should be understood as not limiting the described embodiments to consisting only of those features that have been mentioned; such examples and embodiments may also include features, structures, units, modules, etc. that are not specifically mentioned.

[0090] The basic system architecture of a (tele)communication network including a mobile communication system (some examples of embodiments are applicable) may include the architecture of one or more communication networks, including (multiple) radio access network subsystems and (multiple) core networks. Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways or base transceiver stations, such as base stations (BS), access points (AP), NodeBs (NBs), eNBs or gNBs, distributed units (DUs) or centralized / central units (CUs), which control the corresponding coverage area or (multiple) cells, and one or more communication stations are able to communicate with them via one or more channels via one or more communication beams to send several types of data in multiple access domains, such as communication elements or functions, such as user equipment or terminal equipment, such as user equipment (UE), or another device with similar functionality, such as a modem chipset, chip, module, etc., which may also be part of a station, element, function or application capable of communication, such as a UE, an element or function that can be used for a machine-to-machine communication architecture, or as a separate element attached to such an element, function or application capable of communication, etc. Furthermore, core network elements or network functions may be included, such as gateway network elements / functions, mobility management entities, mobile switching centers, servers, databases, etc.

[0091] The following description may provide further details of alternatives, modifications and variations: The gNB includes, for example, a node that provides NR user plane and control plane protocol termination towards the UE and is connected to the 5GC via an NG interface, for example, in accordance with Section 3.2 of 3GPP TS 38.300 V16.6.0 (2021-06) incorporated by reference.

[0092] The gNB Central Unit (gNB-CU) includes logical nodes that host, for example, the RRC, SDAP and PDCP protocols of the gNB, or the RRC and PDCP protocols of the en-gNB that control the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface with the gNB-DU.

[0093] The gNB distributed unit (gNB-DU) includes logical nodes such as hosting the RLC, MAC and PHY layers of a gNB or en-gNB, and its operation is partially controlled by the gNB-CU. One gNB-DU supports one or more cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface with the gNB-CU.

[0094] The gNB-CU control plane (gNB-CU-CP) includes, for example, logical nodes that host the control plane part of protocols such as RRC and PDCP for an en-gNB or gNB-CU of a gNB. The gNB-CU-CP terminates the E1 interface with the gNB-CU-UP and the F1-C interface with the gNB-DU.

[0095] The gNB-CU user plane (gNB-CU-UP) includes, for example, a logical node hosting, for example, the user plane part of the PDCP protocol for the gNB-CU of the en-gNB, and the user plane parts of the PDCP protocol and the SDAP protocol for the gNB-CU of the gNB. The gNB-CU-UP terminates the E1 interface connected to the gNB-CU-CP and the F1-U interface connected to the gNB-DU, for example, according to Section 3.1 of 3GPP TS 38.401 V16.6.0 (2021-07) incorporated by reference.

[0096] There can be different functional splits between the central unit and the distributed units, called options for example:

[0097] Option 1 (Class 1A Split):

[0098] The functional split in this option is similar to the 1A architecture in DC. RRC is in the central unit. PDCP, RLC, MAC, physical layer, and RF are in the distributed unit.

[0099] Option 2 (Class 3C Split):

[0100] The functional split in this option is similar to the 3C architecture in DC. RRC and PDCP are in the central unit. RLC, MAC, physical layer and RF are in the distributed unit.

[0101] Option 3 (split within RLC):

[0102] Low RLC (part of the RLC function), MAC, physical layer and RF are in the distributed unit. PDCP and high RLC (another part of the RLC function) are in the central unit.

[0103] Option 4 (RLC-MAC Split):

[0104] MAC, physical layer and RF are in the distributed unit. PDCP and RLC are in the central unit.

[0105] Otherwise, for example, according to 3GPP TR 38.801 V14.0.0 incorporated by reference

[0106] (2017-03) Section 11.

[0107] gNB supports different protocol layers, such as Layer 1 (L1), which is the physical layer.

[0108] NR's Layer 2 (L2) is split into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptation Protocol (SDAP), where for example:

[0109] The physical layer provides transport channels to the MAC sublayer;

[0110] The MAC sublayer provides logical channels to the RLC sublayer;

[0111] The RLC sublayer provides RLC channels to the PDCP sublayer;

[0112] The PDCP sublayer provides radio bearers to the SDAP sublayer;

[0113] The SDAP sublayer provides 5GC QoS flows;

[0114] Comp. refers to header compression, and Segm. refers to segmentation;

[0115] Control channels include (BCCH, PCCH).

[0116] Layer 3 (L3) includes, for example, Radio Resource Control (RRC), for example according to Section 6 of 3GPP TS 38.300 V16.6.0 (2021-06), incorporated by reference.

[0117] A RAN (Radio Access Network) node or network node (such as a gNB, base station, gNB CU or gNB DU or part thereof) may be implemented using, for example, a device having at least one processor and / or at least one memory having computer-readable instructions (computer program) configured to support and / or provide and / or process CU and / or DU related functions and / or features, and / or at least one protocol (sub) layer of a RAN (Radio Access Network), such as Layer 2 and / or Layer 3.

[0118] The gNB CU and gNB DU parts may, for example, be collocated or physically separated. The gNB DU may be even further split into two parts, for example, one part including a processing device and the other part including an antenna. The central unit (CU) may also be referred to as BBU / REC / RCC / C-RAN / V-RAN, O-RAN, or a part thereof. The distributed unit (DU) may also be referred to as RRH / RRU / RE / RU or a part thereof. Hereinafter, in various example embodiments of the present disclosure, the CU-CP (or more generally, the CU) may also be referred to as a (first) network node supporting at least one of the central unit control plane functions or the layer 3 protocols of the radio access network; and similarly, the DU may be referred to as a (second) network node supporting at least one of the distributed unit functions or the layer 2 protocols of the radio access network.

[0119] The gNB-DU supports one or more cells and can thus serve as, for example, a serving cell for a user equipment (UE).

[0120] User equipment (UE) may include a wireless or mobile device, a device having a radio interface that interacts with a RAN (Radio Access Network), a smartphone, an in-vehicle device, an IoT device, an M2M device, etc. Such a UE or device may include: at least one processor; and at least one memory including a computer program code; wherein the at least one memory and the computer program code are configured to, together with the at least one processor, enable the device to at least perform certain operations, such as an RRC connection with the RAN. The UE is, for example, configured to generate a message (e.g., including a cell ID) to be sent to the RAN via radio (e.g., to reach a serving cell and communicate with it). The UE can generate, send and receive RRC messages containing one or more RRC PDUs (packet data units).

[0121] The UE may have different states (e.g., according to sections 42.1 and 4.4 of 3GPP TS 38.331 V16.5.0 (2021-06), incorporated herein by reference).

[0122] When the RRC connection has been established, the UE is in, for example, an RRC_CONNECTED state or an RRC_INACTIVE state.

[0123] In the RRC_CONNECTED state, the UE can:

[0124] Store AS context;

[0125] Transmit unicast data to and from UE;

[0126] Monitor the control channel associated with the shared data channel to determine if it is data

[0127] Channel scheduling data;

[0128] Provide channel quality and feedback information;

[0129] Perform neighbor cell measurements and measurement reporting.

[0130] The RRC protocol includes the following main functions:

[0131] RRC connection control;

[0132] Measurement configuration and reporting;

[0133] Establishment / modification / release of measurement configurations (e.g., intra-frequency, inter-frequency and inter-RAT measurements);

[0134] ·Measure the establishment and release of the gap;

[0135] Measurement report.

[0136] The general functionality and interconnection of the described elements and functions (also depending on the actual network type) are known to those skilled in the art and are described in the corresponding specifications, so for the sake of brevity, a detailed description thereof may be omitted here. However, it should be noted that in addition to those described in detail below, several additional network elements and signaling links may be employed to communicate with elements, functions or applications (such as communication endpoints), communication network control elements (such as servers, gateways, radio network controllers), and other elements of the same or other communication networks.

[0137] The communication network architecture considered in the examples of embodiments may also be able to communicate with other networks such as a public switched telephone network or the Internet. The communication network may also support the use of cloud services for virtual network elements or their functions, wherein it should be noted that the virtual network portion of the telecommunications network may also be provided by non-cloud resources, such as an internal network, etc. It should be understood that the network elements and / or corresponding functions of the access system, core network, etc. may be implemented by using any node, host, server, access node or entity, etc. suitable for such use. In general, the network functions may be implemented as network elements on dedicated hardware, software instances running on dedicated hardware, or virtualized functions instantiated on an appropriate platform (e.g., a cloud infrastructure).

[0138] In addition, network elements (such as communication elements, such as UE, terminal equipment, control elements or functions, such as access network elements, such as base stations / BS, gNB, radio network controllers, core network control elements or functions, such as gateway elements, or other network elements or functions described herein), and any other elements, functions or applications may be implemented by software, such as a computer program product of a computer; and / or by hardware. In order to perform its corresponding processing, the correspondingly used devices, nodes, functions or network elements may include several components, modules, units, components, etc. (not shown) required for control, processing and / or communication / signaling functions. For example, such components, modules, units and components may include one or more processors or processor units, including one or more processing parts for executing instructions and / or programs and / or for processing data, storage or memory units or components (e.g., ROM, RAM, EEPROM, etc.) for storing instructions, programs, and / or data as a work area for the processor or processing part, etc., input or interface components for inputting data and instructions by software (e.g., floppy disk, CD-ROM, EEPROM, etc.), user interfaces for providing monitoring and manipulation possibilities to the user (e.g., screen, keyboard, etc.), other interfaces or components for establishing links and / or connections under the control of the processor unit or part (e.g., wired and wireless interface components, radio interface components including, for example, antenna units, etc., components for forming a radio communication part, etc.), etc., wherein the corresponding components forming the interface (such as the radio communication part) may also be located at a remote site (e.g., a radio head or a radio station, etc.). It should be noted that in this specification, a processing part should not be regarded as representing only a physical part of one or more processors, but may also be regarded as a logical division of the indicated processing tasks performed by one or more processors. It should be understood that according to some examples, a so-called "liquid" or flexible network concept may be employed, wherein the operations and functions of a network element, a network function, or another entity of the network may be performed in a flexible manner in different entities or functions, such as in a node, a host, or a server. In other words, the "division of labor" between the network elements, functions, or entities involved may vary from case to case.

[0139] Now, before introducing example embodiments of the present disclosure in detail, it is still worth briefly introducing some exemplary general aspects of machine learning, and more specifically, AI (artificial intelligence) and / or ML (machine learning) related techniques / processes that may be considered useful for understanding the present disclosure.

[0140] ML frameworks and techniques are increasingly being deployed in 5G networks (including, for example, RAN, core network, and management systems / functions), and are expected to scale up as the technology further develops, such as to 5G advanced networks, 6G networks, etc. In addition, there is a general interest in the telecommunications community in different standards forums to study and standardize different machine learning frameworks and functions, and to leverage the capabilities of ML to improve use cases in the respective standards bodies and their different working groups. For example, 3GPP is also actively involved in studying different aspects of ML capabilities and their applicability in different working groups. To give a few examples:

[0141] SA (Service and System Aspects) 5 WIs (Work Items) related to PM (Performance Management) and KPI (Key Performance Indicators) enhancements for 5G and advanced systems, typically focusing on specifying the PMs and KPIs needed to measure the performance of different network entities.

[0142] SA5 research generally focuses on the management aspects of training, retraining, testing, and inference.

[0143] 3GPP SA2 deals with some advanced topics of ML in general, such as enhancing the sharing of trained ML models, supporting FL (Federated Learning) in the 5C core.

[0144] In addition, the RAN3 study item on enhancing data collection for NR and EN-DC describes a functional framework for RAN intelligence. Since the functional framework is considered easy to understand by a person skilled in the art, its detailed description is omitted for the sake of brevity. Broadly speaking, the framework generally proposes two options for the training and deployment of ML models. The first option is to train the ML model at the RAN and deploy the same model in the RAN itself for reasoning. The second option is to train the ML model at the OAM and deploy the model at the RAN for reasoning. In both options, reasoning occurs at the RAN. Thereafter, SA5 conducted a study to understand the impact of the above RAN3 study on SA5.

[0145] The network entities of RAN and core are also adopting AI / ML frameworks in the standards. Generally speaking, each network entity can train, retrain, and / or deploy multiple ML models for inference. It is also important to analyze the feasibility of the framework by providing appropriate auxiliary information to understand and improve the efficiency of AI / ML usage in different AI / ML-enabled network entities.

[0146] Towards advanced 5G and 6G, it is expected that many RAN, core, and management use cases may be driven by AI / ML-based analytics. Thus, a large number of AI / ML models may be trained and / or deployed to perform inference directly in network entities such as UEs, base stations (e.g., gNodeBs), core network functions, and / or management functions.

[0147] As noted above, the present disclosure generally seeks to provide an accurate and efficient anomaly detection and diagnosis method.

[0148] Classic network anomaly detection and diagnosis solutions such as Figure 1 As shown in . It can include three main stages: first, analyze the typical network status in a predefined context, mainly using clustering and unsupervised learning techniques; second, detect abnormal events by comparing the network status with the profile; third, diagnose the abnormal events to gain more insights about the type of anomaly (describing the detected abnormal events as abnormal patterns), the root causes, and finally how to react. The root cause can be defined as the most appropriate set of causes that lead to the anomaly or abnormal pattern. Status profile analysis can be performed based on selected network key performance indicators (KPIs) in each context. For example, the context can include different times of the day to capture diurnal patterns, daily fluctuations, or possibly distinguish between weekdays and holidays.

[0149] The diagnosis can be automated by using case-based reasoning and comparing the detected abnormal event patterns with an anomaly diagnosis knowledge base to find the most similar diagnosed anomaly. If no close match is obtained, manual diagnosis is required.

[0150] More specifically, Figure 1 An overview of the anomaly detection and diagnostics functionality of the Radio Access Network (RAN) is shown. Profile analysis, detection, and diagnosis are performed based on the selected context, such as per cell, and differentiate between weekdays and weekends. The expected deployment resides at the NM level and analyzes the performance management (PM) data collected from the Network Management System (NMS). The collected key performance indicators (KPIs) are typically aggregated at a granularity of per minute or per hour. Note that the concept also allows other deployment options.

[0151] After the profile is created, an abnormality level is calculated for each KPI in each cell against the profile of the collected time series samples. Based on the abnormality level, different abnormal events are detected. An abnormal event only indicates that an abnormal situation has occurred, but not necessarily a degradation in network performance, or other events that require corrective action. Therefore, the detected abnormal events are analyzed by a diagnostic function, which links the detected fault to the most similar root cause(s). Once the cause of the abnormality is known, it can be linked to a corrective workflow.

[0152] Describe detected abnormal events with anomaly patterns for diagnosis, where anomaly patterns can also be called anomaly signatures. Anomaly patterns can consist of features (KPIs) used in the detection phase, but usually it is an extension of these features. As a medical analogy, a fever is a good indicator of a disease, but more information is needed to diagnose which disease it is. Use the average abnormal level of a set of extended network KPIs. Anomaly patterns should capture as many aspects of abnormal events as possible.

[0153] The observed anomaly pattern is compared with the analyzed and labeled anomalies stored in the diagnostic knowledge base. The best matching labeled anomaly pattern in terms of similarity is found and taken as the most likely automatic diagnosis.

[0154] Examples of abnormal event detection and abnormal pattern diagnosis are Figure 2 as shown in . Figure 2 The two anomaly modes are illustrated in the form of a radar chart. Each segment of the chart corresponds to a diagnostic feature. The outer area is the observed anomaly events, and the inner area is the closest matching labeled anomaly in the knowledge base. The darker innermost circle is the expected value for each feature, and the actual observation can of course be higher or lower than it.

[0155] Network anomaly detection can be a powerful tool, but it has its own challenges. First, anomalies are by definition rare events, and therefore building a comprehensive diagnostic knowledge base is time-consuming and requires the involvement of network experts to classify and analyze newly discovered anomaly events. Second, anomalies are not necessarily failures, nor are they necessarily any other relevant events in the network. Many detected anomalies may have nothing to do with network operation or management, but are just unusual things. For example, a football game may cause an abnormal peak load, but if it does not cause congestion, there is no need to notify the operator. The analysis of irrelevant anomalies is costly and reduces the value of anomaly detection. Third, an ideal network anomaly detection system is also able to detect unforeseen anomalies. Building a network anomaly detection system by utilizing supervised techniques, i.e., involving labeled anomaly detection training datasets, runs counter to this goal because it requires many known and different anomaly samples.

[0156] Fault injection (also known as anomaly injection or error injection) is the act of intentionally interfering with the functionality of network components by introducing misconfigurations, simulated failures, or other changes to expected behavior. Knowing the root cause of the injection, network behavior can be monitored and measured, and based on these measurements, faults can be fingerprinted for later detection and diagnosis. Fault injection is an attractive concept because it enables robust supervised learning methods to be used for anomaly detection and diagnosis. However, it has significant drawbacks that limit its usability in mobile networks:

[0157] • Fault injection is usually not feasible on operational (live) networks because network QoS cannot be compromised.

[0158] Fault injections in isolated test cases (such as a single network element in a lab) will not produce the widespread impact of a network element failure in a real large-scale network deployment. These isolated injections may also not produce patterns that can be used for anomaly detection and diagnosis in live deployments.

[0159] Network simulators can be used to simulate the effects of injected faults. However, since faults are often very specific to a certain network deployment and its environment, simulated anomaly patterns are often not transferable to real network anomaly detection.

[0160] Many solutions have been proposed to alleviate the above problems in network anomaly detection. The network diagnostic cloud concept proposes the use of transfer learning to transfer network anomaly event diagnostic knowledge between networks or deployments to speed up the collection of diagnostic knowledge base. However, such transfer is not simple because each network deployment is different and the same anomaly patterns and diagnoses may not be applicable to different networks. To this end, the network diagnostic cloud introduces the Gateway Diagnostic Agent (GDA), which converts network-specific diagnostic knowledge from the local diagnostic agent (LDA) to a general model in the central diagnostic agent (CDA) and vice versa. Such conversion is not easy to implement and is not always possible. Transferring between more similar networks is usually easier, but it is still trivial and has limited the data available for diagnosis.

[0161] Another alternative is to use active learning to reduce the workload of manual diagnosis. In this solution, the diagnosed and undiagnosed abnormal patterns in the diagnostic knowledge base are clustered to find undiagnosed abnormal pattern samples that the operator wants to diagnose and that are most beneficial for future automatic diagnosis. This solution can reduce the workload of manual diagnosis by reducing the number of abnormal pattern samples that need to be manually diagnosed. However, in some cases, it cannot determine whether the proposed abnormal pattern is actually related to network operations. In addition, this approach may run the risk of incorrectly clustering abnormalities with different root causes together, which may lead to diagnostic errors.

[0162] In summary, anomalies in communication networks are rare events, and traditional anomaly detection is time-consuming, requires the participation of network experts, and is not 100% accurate. Therefore, it is necessary to develop an accurate and efficient anomaly detection and diagnosis method.

[0163] The present disclosure, in its embodiments, generally proposes to exploit the novel capabilities provided by a network digital twin NDT to enable accurate fault injection experiments. Network anomaly detection is one of the key use cases that can benefit from such experiments.

[0164] Reference is now made to the embodiments of the present disclosure as shown in the drawings. In particular, it should be noted that unless otherwise specified, the same or similar reference numerals used in the drawings of the present disclosure may represent the same or similar elements, so that repeated descriptions thereof may be omitted for the sake of brevity.

[0165] In order to achieve appropriate network anomaly analysis, the use of network digital twins is proposed in this disclosure. A network digital twin is a digital representation of the hardware and software features, characteristics, and configurations of a communication network and its associated environment. It combines network aspects in software and hardware with physical world aspects such as propagation channels, physical distances, and mobility. It is able to mimic some or all of the properties, variables, configurations, and behaviors of a network and its environment, both static and dynamic. It also has simulation capabilities ("what if" analysis). NDT can be used to simulate network behavior in specific situations. Using NDT, operators can monitor the network, detect, and troubleshoot problems in real time without interfering with the operation of the real network. NDT is not necessarily a representation of the entire network, as its scope can be smaller: it can be a representation of a network, subnet, geographic area, single cell, cell group, and / or selected features synchronized between the real network and NDT.

[0166] A network digital twin may be interested in maintaining a copy of the physical environment in digital form so that actions in the physical environment can be better controlled. A digital twin may include a digital copy of a living or non-living physical entity. A digital twin may refer to a digital copy of a physical asset (physical twin), process, personnel, location, system, and equipment that can be used for various purposes. A network digital twin may have a connection between a physical model and a corresponding virtual model or virtual counterpart. The connection may be established by generating real-time data using a sensor or receiving real-time data from a sensor. In one example, a network digital twin is analyzed, and an alarm message may be generated if some data is missing. A network digital twin may learn and update itself from multiple physical asset sources to represent its near real-time status, working condition, or location. In addition, the connection may be arranged between the tracked object and the digital twin.

[0167] A network digital twin can be created and maintained through software-based tools. In one respect, for example, spatial computing relies on spatial awareness; in order for a system to adapt to its surroundings, the system needs to understand those surroundings and be able to interpret them. In particular, spatial computing can be linked to the concept of a “digital twin,” which is a virtual representation of a physical object (or environment) that serves as a real-world digital counterpart to that physical object (or environment). In other words, a network digital twin of a real-world network is a computational model that stores important features of the network or space at a certain level of abstraction. The digital representation of these features can then be used for computational processing by spatially aware algorithms.

[0168] Figure 4 An overview of an example implementation of the network digital twin-based fault injection analysis of the present disclosure is schematically illustrated. In this implementation, a network anomaly detection function network digital twin management service consumer NADF NDTMnS consumer is introduced, which can leverage the simulation capabilities of the network digital twin management service provider NDT MnS provider to safely conduct fault injection experiments without jeopardizing the QoS (quality of service) of the twin real network. The impact of each injected fault can be monitored in the NDT simulation to build a training dataset for direct detection and diagnosis of injected faults using supervised machine learning (AI / ML) methods.

[0169] like Figure 4 As shown in FIG, in step S410, once the NDT simulation scenario is determined based on the deployment of the network anomaly detection solution in the real twin network (the target network, i.e., the network in the real world), the next step is to determine the fault configuration or state to be injected into it. This can include a list of predetermined fault scenarios, or it can include heuristic or random exploration of the network and simulation configuration space of the NDT simulation.

[0170] Next, in step S420, a fault condition is simulated in the NDT simulation, and its simulated impact on network behavior and indicators is monitored. Thus, a training data set can be created for training a classification model based on supervised machine learning to detect and determine the root cause of the injection from the observed simulated network impact. For each injected fault, the simulation can be restarted from the same initial state. In addition, since NDT simulates mobile network behavior associated with a specific environment, context-based fault signatures can be explored and collected: for example, an abnormal event that is the same as network congestion may be caused by high demand or reduced capacity. The machine learning-based classification model can be an AI / ML model that can be trained and / or deployed for reasoning directly in a network entity, such as a base station (e.g., gNodeB), a core network function, a management function, and / or a UE (user equipment). For example, a base station can have many different AI / ML models trained and / or deployed for reasoning. As a result of the simulation, an abnormal signature is generated.

[0171] In step S430, since the NDT simulation is still a simulation and can never be 100% accurate to the twin real network, an additional transfer learning step can be implemented to calibrate the results. However, since the NDT is simulating the network in which the network anomaly detection solution is deployed, it is very similar to the target network and the required transformation is also easier. The calibration can include comparing the anomaly signature of the known diagnosis case in the real network and comparing it with the anomaly pattern / signature of the same root cause injected in the NDT simulation.

[0172] Finally, in step S440, the converted training dataset or anomaly detection and diagnosis classification machine learning model can be incorporated into the network anomaly detection solution in the twin real network. This can be done offline, and the same dataset can be used to train the AI / ML model to detect and diagnose network anomalies.

[0173] In some embodiments, Figure 5 As shown in , as shown in step S511 , the network anomaly detection function NADF 520 is deployed and analyzed using the data collected by the OAM 510 .

[0174] In steps S521 and S522 , the OAM 510 initializes both the NDT MnS producer 540 and the NADF NDT MnS consumer 530 to enhance the detection and diagnosis capabilities of the NADF 520 .

[0175] In steps S531 and S532 , the NADF NDT MnS consumer 530 reads the simulation configuration from the NDT MnS producer 540 , and generates a set of fault injection cases based on the configuration.

[0176] In steps S541 and S542, the NADF NDT MnS consumer 530 simulates using the NDT MnS producer 540 to simulate the impact of at least one injected fault and collects its signature. In some embodiments, the NADF NDT MnS consumer 530 simulates using the NDT MnS producer to simulate the impact of each injected fault and collects its signature.

[0177] In step S541, the NADF NDT MnS consumer 530 injects at least one anomaly. The anomaly may include a communication network failure, a communication network failure, and / or a communication network anomaly problem. The anomaly may also include a list of predetermined failure scenarios, a heuristic or random exploration of the network, and a simulation configuration space for the NDT simulation. As a result of the simulation, an anomaly signature is obtained. In addition, the diagnosis of the anomaly is the original anomaly configuration injected in the simulation.

[0178] In step S542, the NDT MnS producer 540 simulates the impact of at least one injected anomaly and collects its signature. The signature may be a pattern. In some embodiments, the NADF NDT MnS consumer 530 uses the NDT MnS producer simulation to simulate the impact of each injected anomaly and collects its signature.

[0179] In step S543 , the NDT MnS producer 540 sends the collected signatures to the NADF NDT MnS consumer 530 .

[0180] Optionally, in steps S551 to S555, in order to calibrate the signature provided by the NDT MnS producer 540, the NADF NDT MnS consumer 530 may collect diagnostic anomalies from the NADF, inject their diagnostic root causes into the NDT MnS producer 540 simulation, and compare the NADF anomaly patterns with the effects monitored in the NDT MnS producer 530 simulation. The simulation with injected anomalies may be calibrated to make the results more reliable. The calibration may include comparing anomaly signatures of known diagnostic cases in the real network and comparing them with anomaly patterns / signatures of the same root causes injected in the NDT simulation.

[0181] In step S551, the NADF NDT MnS consumer 530 may receive a diagnostic anomaly from the NADF. By receiving the diagnostic anomaly from the NADF, at least one signature of the corresponding at least one root cause in the real network may be obtained.

[0182] In step S552 , the NADF NDT MnS consumer 530 may inject its diagnostic root cause into the simulation of the NDT MnS producer 540 .

[0183] In step S553 , the NDT MnS producer 540 simulation may simulate the diagnostic root cause injected into the NDT MnS producer simulation, and the NDT MnS producer 540 may acquire at least one signature of the injected diagnostic root cause.

[0184] In step S554 , the NDT MnS producer 540 may send at least one acquisition signature to the NADF NDT MnS consumer 530 .

[0185] In step S555, the NADF NDT MnS consumer 530 may compare the signature acquired in step S551 with the signature acquired in step S553, and calibrate the signature acquired in step S543 based on the comparison result. The simulation of injected anomalies may be calibrated to make the results more reliable. The calibration may include comparing anomaly signatures of known diagnosis cases in the real network and comparing them with anomaly patterns / signatures of the same root cause injected in the NDT simulation.

[0186] Therefore, calibration is performed by comparing the anomaly pattern / signature of known diagnosis cases in the real network and comparing it with the anomaly signature of the same root cause injected in the NDT simulation.

[0187] Finally, in step S561, the diagnostic knowledge generated by the NADF NDT MnS consumer 530 is deployed in the NADF 540 for use in the real twin network. This can be done by transferring training data from the NADF NDT MnS consumer 530 and training a supervised classification machine learning model in the NADF 540, or by training the model directly in the NADF NDT MnS consumer 530 and transferring the trained model to the NADF 540. Providing abnormal diagnosis to the target communication network can trigger one or more self-healing actions of the target communication network.

[0188] Therefore, using the above-described implementation using NDT simulation, fault injection is feasible also on an operational (live) network without compromising the network QoS.

[0189] In some embodiments, Figure 6 This shows that the new or changed interfaces include a NADF MnS Consumer 630 interface to initialize it and interact with the NDT MnS Provider 640 and NADF 620 .

[0190] As shown in step S611 , the data collected by the OAM 610 is used to deploy and analyze a network anomaly detection function (NADF) 620 .

[0191] In steps S621 and S622 , the OAM 610 initializes both the NDT MnS producer 640 and the NADF NDT MnS consumer 630 to enhance the detection and diagnosis capabilities of the NADF 620 .

[0192] In step S631 and step S632, the NADF NDT MnS consumer 630 configures fault injection in the NDT MnS producer 640, and the NDT MnS producer 640 generates a set of fault scenarios accordingly. A fault may also be referred to as an anomaly. An anomaly may include a communication network failure, a communication network failure, and / or a communication network abnormal problem. Anomalies may also include a list of predetermined fault scenarios, heuristic or random exploration of the network, and a simulation configuration space for NDT simulation.

[0193] In steps S641 and S642, the NDT MnS producer 640 simulates the simulated fault scenarios and provides the resulting fault signatures to the NADF NDT MnS consumer 630. Note that in this case, the signatures preferably may contain signatures of the injected faults (e.g., configuration) and their effects. In some embodiments, the NDT MnS producer simulates each simulated fault scenario and provides the resulting fault signatures to the NADF NDT MnS consumer 630.

[0194] In step S641, the NDT MnS producer 640 simulates the impact of at least one generated anomaly and collects its signature. The signature may be one or more patterns. In some embodiments, the NADF NDT MnS consumer 630 simulates the impact of each injected anomaly using the NDT MnS producer 640 simulation and collects its signature. The anomaly may include a communication network failure, a communication network failure, and / or a communication network anomaly problem occurrence. The anomaly may also include a list of predetermined failure scenarios, heuristic or random exploration of the network, and a simulation configuration space for the NDT simulation.

[0195] In step S642 , the NDT MnS generator 640 provides the obtained fault signature to the NADF NDT MnS 630 .

[0196] Steps S651 to S661 are the same as steps S651 to S655, wherein steps S651 to S655 are optional steps.

[0197] In another example implementation of the present disclosure, the simulation capability of the NDT MnS provider is used as a diagnostic sandbox to analyze and diagnose abnormal events (or anomalies) that have been detected. In this case, the simulation capability is used to inject different predefined anomalies or faults in an attempt to recreate the abnormal pattern of the selected event. The most appropriate set of causes, i.e., the root causes that led to the abnormal pattern, is proposed as a diagnosis of the abnormal event. Since the NDT simulation is run only after the abnormal event is detected and described in an abnormal pattern, the root cause assumptions for the simulation can be selected using heuristic methods and limited to a lower number of scenarios.

[0198] The diagnostic sandbox can be used both to diagnose previously detected anomalies as an offline post-processing step and to build a comprehensive diagnostic knowledge base from the diagnosis, which can be used again to train detection and diagnostic models in the future. Another use of the diagnostic sandbox is to diagnose currently occurring anomalies online (if NDT can support sufficiently fast or parallel what-if analysis). The online and offline approaches can also be combined, where the diagnosis is simulated online only if the diagnostic knowledge base is not closely matched, and if the diagnosis is found to be good, it is stored again in the knowledge base and can be used for further diagnosis.

[0199] For example, in the case of a coverage problem, potential assumptions tested in an NDT simulation may include:

[0200] 1. Bad weather (for example, heavy rain or snow);

[0201] 2. Configuration error, which can be tested by simulating action cell configuration

[0202] 3. Cell power amplifier failure, which can be simulated by reducing the cell transmit power from the configured value or reducing the antenna gain.

[0203] Figure 7 Another example implementation of the fault injection analysis based on network digital twins of the present disclosure is schematically illustrated. Figure 7 Anomaly detection and diagnosis are separated as shown in . Anomaly detection (which is usually easier than diagnosis) can be implemented using state of the art clustering methods, and the simulation capabilities of the NDT MnS provider are exploited to explore the diagnosis of selected abnormal events.

[0204] As shown in step S711 , the network anomaly detection function NADF 720 is deployed and analyzed using the data collected by the OAM 710 .

[0205] In steps S721 and S722 , the OAM 710 initializes both the NDT MnS producer 740 and the NADF NDT MnS consumer 730 to enhance the diagnostic capability of the NADF 720 .

[0206] In step S731, the NADF NDT MnS consumer 730 configures at least one anomaly injection in the NDT MnS producer 740. The NADF NDT MnS consumer 730 also requests the NDT MnS producer to receive an anomaly diagnostic that specifies the expected report or report type (e.g., a specific required network measurement). In this case, the fault is logically pre-selected at the consumer end to recreate a specific anomaly measurement set or pattern or signature.

[0207] In step S741, the NADF NDT MnS consumer 730 injects at least one anomaly injection. Anomalies include communication network failures, communication network failures, and / or communication network anomaly problems. Anomalies may also include a list of predetermined failure scenarios, heuristic or random exploration of the network, and simulation configuration space for NDT simulation.

[0208] In step S751 , the NDT MnS generator 740 simulates at least one injection anomaly.

[0209] In step S761 , the injected fault is provided to the NDT MnS producer 740 , which explores potential root causes (the list of potential causes may be obtained from a predefined set or may be specified from the consumer to the producer during step S731 ) to perform fault diagnosis.

[0210] In step S771 , the NDT MnS producer 740 sends the performed diagnostics and the requested report containing the measurement and pattern list to the consumer.

[0211] In step S781, to calibrate the diagnostics provided by the NDT MnS producer 740, the NADF NDT MnS consumer 730 may collect diagnostic anomalies from the NADF 720 and compare the NADF 720 anomaly patterns with the effects monitored in the NDT MnS producer 740 simulation. The calibration may include comparing anomaly signatures of known diagnostic cases in the real network and comparing them with anomaly patterns / signatures of the same root causes injected in the NDT simulation.

[0212] In step S791, the diagnostic knowledge generated by the NADF NDT MnS consumer 730 is deployed in the NADF 720 for use in the real twin network. This can be done by transferring training data from the NADF NDT MnS consumer 730 and training a supervised classification machine learning model in the NADF 720; or by training the model directly in the NADF NDT MnS consumer 730 and transferring the trained model to the NADF 720.

[0213] In steps S793 and S794, in the online NDT hypothetical simulation, the diagnostic results can be immediately provided to the real twin network to trigger self-healing actions and stored in the diagnostic knowledge base for later abnormal event diagnosis. In this option, the NDT MnS producer 740 is utilized to provide online diagnosis of ongoing faults. The NDT MnS producer 740 can also trigger the collection of data from the real network (e.g., from cells near the affected cell) to further support ongoing diagnosis.

[0214] In short, reference Figures 5 to 7 The described example embodiments may generally be viewed as analyzing anomalies in a network by using fault injection based on a network digital twin (NDT).

[0215] More specifically, compared with traditional technologies, there may be the following new aspects worth mentioning. First, the present disclosure configures a network digital twin NDT of a target communication network. NDT is not necessarily a representation of the entire network, as it may have a smaller scope: it may be a representation of a network, a subnet, a geographic area, a single cell, a cell group, and / or selected features synchronized between a real network and NDT. With this configuration, different anomalies can be simulated as accurately as possible in a twin target communication network. Secondly, anomalies are injected into the NDT to obtain signatures of the injected anomalies, such as patterns, so that the machine is configured to learn different anomaly signatures in the NDT, and a training data set or anomaly detection and diagnosis classification machine learning model is obtained. Third, the training data set or the anomaly detection and diagnosis classification machine learning model can be deployed in a network anomaly detection solution in a twin real network. Therefore, using the above-mentioned implementation using NDT simulation, fault injection is also feasible on an operational (real-time) network without compromising network QoS.

[0216] As an alternative or in addition, in the online NDT hypothetical simulation, the diagnostic results can be immediately provided to the real twin network from the NDT side to trigger self-healing actions, and stored in the diagnostic knowledge base for later abnormal event diagnosis or as a source of monitoring information for manual corrective actions. Through the above configuration, a simulation that is as accurate as possible to the twin target network is obtained without reducing the QoS of the twin target communication network. Optionally, the simulation with injected anomalies can be calibrated to make the results more reliable.

[0217] It should be noted that although in the above-mentioned example embodiments (refer to the accompanying drawings), the messages passed / exchanged between network components / elements may appear to have specific / clear names, depending on various implementations (e.g., underscore technology), these messages may have different names and / or be passed / exchanged in different forms / formats, as understood and recognized by those skilled in the art.

[0218] According to some example embodiments, corresponding methods suitable for being performed by an apparatus (network element / component) as described above, such as a UE, a CU, a DU, etc., are also provided.

[0219] However, it should be noted that the above-mentioned device (equipment) features correspond to corresponding method features, but for the sake of simplicity, these method features may not be explicitly described. The disclosure of this document is considered to also extend to such method features. In particular, the present disclosure is understood to relate to methods of operating the above-mentioned devices and / or providing and / or arranging corresponding elements of these devices.

[0220] In addition, according to some other example embodiments, a corresponding device (for example, implementing the UE, CU, DU, etc. as described above) is also provided, which includes at least one processing circuit system and at least one memory for storing instructions to be executed by the processing circuit system, wherein the at least one memory and the instructions are configured to be together with the at least one processing circuit system so that the corresponding device performs at least the corresponding steps as described above.

[0221] However, in some other example embodiments, a corresponding apparatus (eg, a UE, CU, DU, etc. implemented as described above) is provided, the apparatus comprising corresponding components configured to at least perform the corresponding steps described above.

[0222] It should be noted that the examples of the embodiments of the present disclosure are applicable to a variety of different network configurations. In other words, the examples shown in the above figures used as the basis for the above examples are merely illustrative and do not limit the present disclosure in any way. That is, based on the defined principles, other existing and proposed new functions available in the corresponding operating environment can be used in conjunction with the examples of the embodiments of the present disclosure.

[0223] It should also be noted that the disclosed example embodiments can be implemented in a variety of ways using hardware and / or software configurations. For example, the disclosed embodiments can be implemented using dedicated hardware and / or hardware associated with software that can be executed thereon. The components and / or elements in the accompanying drawings are merely examples and do not limit the scope of use or functionality of any hardware, software combined with hardware, firmware, embedded logic components, or a combination of two or more such components that implement a specific embodiment of the present disclosure.

[0224] It should be further noted that the description and the accompanying drawings illustrate only the principles of the present disclosure. Those skilled in the art will be able to implement various arrangements that, although not explicitly described or illustrated herein, embody the principles of the present disclosure and are included in its spirit and scope. In addition, all examples and embodiments outlined in the present disclosure are primarily for explanatory purposes only to help the reader understand the principles of the proposed method. In addition, all statements of the principles, aspects, and embodiments of the present disclosure and their specific examples provided herein are intended to cover their equivalents.

[0225] List of abbreviations:

[0226] Abbreviations

[0227] CDA: Central Diagnostic Agent

[0228] GDA: Gateway Diagnostic Agent

[0229] LDA: Local Diagnostic Agent

[0230] MnS: Management Services

[0231] NADF: Network Anomaly Detection Function

[0232] NDT: Network Digital Twin

[0233] OAM: Operations, Administration, and Maintenance

[0234] QoS: Quality of Service

[0235] SDO: Standards Development Organization

[0236] TRX: Transceiver

[0237] UE: User Equipment.

Claims

1. A first network node, configured to support detection and / or diagnosis of network anomalies in a target communication network based on a network digital twin (NDT), wherein the NDT simulates at least a portion of the target communication network, wherein the first network node comprises: at least one processor; as well as at least one memory storing instructions, which, when executed by the at least one processor, cause the first network node to at least: providing at least one anomaly injection case generated based on the simulation configuration to a second network node, and / or configuring at least one anomaly injection case in the NDT, the NDT being provided at the second network node; receiving a simulation signature and / or anomaly diagnosis of the simulation of the anomaly injection case on the NDT from the second network node; as well as The diagnostic knowledge generated based on the received simulation signature and / or anomaly diagnosis is deployed for the target communication network in a network anomaly detection function NADF, and / or the anomaly diagnosis is provided to the target communication network.

2. The first network node of claim 1 , wherein the anomaly injection case is a fault injection case indicating a network fault condition, and wherein providing the anomaly injection case to the second network node comprises: Faults in a set of fault injection cases are injected into the NDT to simulate the impact of the faults.

3. The first network node according to claim 1 or 2, wherein the first network node is initialized by an operation, administration and maintenance (OAM) entity to improve the detection and diagnosis capabilities of the NADF, and the first network node is further caused to: injecting one or more diagnosed root causes of anomalies into the NDT to simulate the impact of the root causes, wherein the root causes are the most appropriate causes of the anomaly signature that caused the selected event; and The diagnostic anomaly signature of the NADF is compared with the received simulation signature to calibrate the received simulation signature provided by the second network node.

4. The first network node of claim 1 , wherein the anomaly injection case is a fault injection case indicating a network fault condition, and wherein providing at least one anomaly injection case comprises: Injecting faults in a set of fault injection cases into the NDT to simulate the impact of the faults, and the first network node is further caused to: obtaining a first simulation signature for each abnormal injection case of the at least one abnormal injection case; obtaining a first signature of a root cause for each of the at least one diagnosed root cause of an anomaly in the target communication network; injecting at least one diagnostic root cause of anomaly into the NDT to simulate the impact of the root cause and obtaining a second simulation signature for each of the at least one diagnostic root cause of anomaly; The first signature and the second simulated signature of the root cause are compared to calibrate the first simulated signature provided by the second network node.

5. The first network node according to claim 1, wherein the anomaly injection case is a fault injection case indicating a network fault condition, and wherein after configuring at least one anomaly injection case in the NDT provided at the second network node, the first network node is further caused to: obtaining a first simulation signature for each abnormal injection case of the at least one abnormal injection case; obtaining a first signature of a root cause for each of the at least one diagnosed root cause of an anomaly in the target communication network; injecting at least one diagnostic root cause of anomaly into the NDT to simulate the impact of the root cause and obtaining a second simulation signature for each of the at least one diagnostic root cause of anomaly; obtaining a third simulated signature for each of the at least one diagnostic root cause of the anomaly in the target communication network; The first signature and the second simulated signature of the root cause are compared to calibrate the first simulated signature provided by the second network node.

6. The first network node according to claim 1 or 2, wherein deploying the diagnostic knowledge comprises: The received simulated signature for each of the at least one anomaly injection case is deployed in the NADF for use in the target communication network.

7. The first network node according to claim 1 or 2, wherein deploying the diagnostic knowledge in the NADF, and / or providing the abnormal diagnosis to the target communication network to trigger one or more self-healing actions of the target communication network comprises: training a supervised classification machine learning model in the first network node based on the received simulated signature, and providing the trained classification machine learning model to the NADF for anomaly detection in the target communication network; or The received simulated signature is reported to the NADF for use in training a supervised classification machine learning model of the NADF based on the received simulated signature.

8. The first network node according to claim 1 or 2, further being caused to read a simulation configuration from the second network node, and to generate one or more fault injection cases based on the simulation configuration.

9. The first network node according to claim 1 or 2, wherein the first network node is further caused to configure the fault injection in the second network node, wherein at the first network node, the faults are pre-selected to recreate a specific abnormal measurement set or pattern; and wherein the first network node is further caused to request fault diagnosis, the fault diagnosis comprising a report for fault diagnosis from the second network node; receiving the requested report from the second network node, the requested report comprising at least one of: the performed fault diagnosis, a list of measurements, and a simulated signature of at least one of the injected anomalies; and The diagnostic anomaly signature of the NADF is compared with the received fault diagnostic and / or simulation signature to calibrate the diagnostics provided by the second network node.

10. A second network node configured to support detection and / or diagnosis of network anomalies in a target communication network based on a network digital twin (NDT), wherein the NDT simulates at least a portion of the target communication network, wherein the second network node comprises: at least one processor; as well as at least one memory storing instructions, which, when executed by the at least one processor, cause the first network node to at least: providing a configuration for generating an anomaly injection case to the first network node, and / or receiving at least one anomaly injection case generated based on the simulation configuration from the first network node; as well as Simulating the impact of injection anomalies in a set of abnormal injection cases on the NDT; as well as A simulation signature and / or anomaly diagnosis of the simulation of the anomaly injection case on the NDT is reported to the first network node.

11. The second network node according to claim 10, wherein the anomaly injection case is a fault injection case indicating a network fault condition, and wherein the first network node and / or the second network node is caused to inject a fault in the set of fault injection cases into the NDT to simulate the impact of the fault, the NDT being provided at the second network node.

12. The second network node according to claim 10 or 11, wherein the second network node is further caused to: receiving one or more diagnosed root causes of anomalies, and simulating the impact of the one or more root causes on the NDT, wherein a root cause is the most appropriate cause of the anomaly signature causing the selected event; and The simulation signature indicating at least the impact of the root cause is reported to the first network node for calibration.

13. The second network node according to claim 10 or 11, wherein the anomaly injection case is a fault injection case indicating a network fault condition, and the second network node is further caused to: Based on the fault of the at least one abnormal injection case injected by the first network node or the second network node, simulate the impact of the fault on the NDT to obtain a first simulation signature; based on a diagnosed root cause of at least one anomaly, simulating the impact of the at least one root cause on the NDT to obtain a second simulated signature; as well as The first simulated signature and the second simulated signature are reported to the first network node for calibration.

14. The second network node of claim 10, wherein the second network node is configured to simulate the injected fault and provide diagnosis of potential root causes to perform fault diagnosis, wherein the fault diagnosis is provided for a past fault or an ongoing fault, wherein the second network node is further configured to trigger data collection from the target network to support the ongoing diagnosis.

15. The second network node according to claim 10 or 11, the second network node is further caused to: A simulation configuration is provided to the first network node, and the first network node generates the set of fault injection cases based on the simulation configuration.

16. The second network node according to claim 10 or 11, the second network node is further caused to: receiving the simulation configuration of the at least one anomaly injection case from the first network node, and The at least one exception injection case is generated.

17. The second network node according to claim 10 or 11, wherein the second network node is further caused to trigger reception of data from the target communication network to further support the diagnosis.

18. A method for supporting detection and / or diagnosis of network anomalies in a target communication network based on a network digital twin (NDT), wherein the NDT simulates at least a portion of the target communication network, wherein the method comprises: providing at least one anomaly injection case generated based on the simulation configuration to a second network node, and / or configuring at least one anomaly injection case in the NDT, the NDT being provided at the second network node; receiving a simulation signature and / or anomaly diagnosis of the simulation of the anomaly injection case on the NDT from the second network node; as well as Deploy diagnostic knowledge generated based on the received simulation signature and / or anomaly diagnosis for the target communication network in a network anomaly detection function NADF, and / or provide the anomaly diagnosis to the target communication network to trigger one or more self-healing actions of the target communication network.

19. A method for supporting detection and / or diagnosis of network anomalies in a target communication network based on a network digital twin (NDT), wherein the NDT simulates at least a portion of the target communication network, wherein the method comprises: providing a configuration for generating anomaly injection cases to the first network node, and / or receiving at least one anomaly injection case generated based on the simulation configuration from the first network node; as well as Simulating the impact of injection anomalies in a set of abnormal injection cases on the NDT; as well as A simulation signature and / or anomaly diagnosis of the simulation of the anomaly injection case on the NDT is reported to the first network node.

20. A computer readable medium having stored thereon instructions which, when executed by at least one processing unit of a machine, cause the machine to perform the method of claim 18 or 19.

Images