Patent Description:
Over the last few years, the research and standardization communities have worked collaboratively to develop a composable fifth-generation (<NUM>) network for the digitized connected world of humans and machines. This has been depicted in every single segment of the new communication system, starting by the powerful reachable air interface supported by New Radio (NR), multi-access edge computing, new transport network featuring dense wavelength division multiplexing (DWDM), the service-based architecture (SBA) of <NUM> core network, end-to-end (E2E) network slicing, network function virtualization (NFV) and service automation, etc. Using predefined policies, this is a software-driven network that tactically restructures domains and mobilizes resources in response to traffic changes. However, the current network topology, resources, functionality, and task assignment requires a self-optimization mechanism for automating network topology interface and components in response to dynamic changes in traffic and operating expenses.

With respect to network monitoring, there is a need to define a mechanism for: instantiating new probes, modifying existing probes, change the topology of the solution to meet network demands, reduce the footprint, or during self-troubleshooting. Also, the solution captures network anomaly that could be delivered as commands to the orchestrator to trigger lifecycle management (LCM) events to restore network functionality and optimization.

With respect to network automation, dynamic creation of topology and orchestration specification for cloud applications (TOSCA) templates is a key technology pillar for automating <NUM> and beyond networks. There are several modeling languages that are used today in VFV orchestration, such as TOSCA, YANG, Openstack HEAY models and Business Protocol Model and Notation (BPMN). The model driven principle is a key enabler for lifecycle management operations that automates various cloud operations such as creation, update, termination, scalability, etc. Although those processes have been tested, current orchestrator platforms are only supporting predefined policies for lifecycle management operations. This requires human intervention to define new LCM policies for a cloud network function (CNF) and then upload the templates to the orchestrator. The LCM operations should be either triggered manually which is the NFV orchestration main scope according to the ETSI NFV reference, or through predefined policy templates that are bundled with orchestration templates to get full automation, and this comes in service orchestration scope which is going beyond NFV orchestration scope by including intelligence and service assurance features to the traditional orchestration platforms.

All other proposals for self-automated LCM are assuming AI-based orchestrators with some inputs from hypervisor telemetry services. This means that orchestrators have limited ability to scale/modify/instantiate any virtual machines/containers with any of <NUM> slices because there are no indicators about internal processed load or capacity status. This is a major drawback in current designs for <NUM> and beyond networks and will impose a significant amount of work to create policy/automation templates for each state transition. The NFV community is working to develop automated smart orchestrators (e.g., ONAP), but there is no use of network functions analytics to automate network topology and resources for <NUM> and beyond. <CIT> describes a realized topology system management (RTSM) database, comprising a database, a number of stored realized topologies, and in which the realized topologies within the DBMS are searchable. A method of generating and tracking a realized topology is described, comprising deriving a realized topology from an instantiated topology, storing the realized topology in a RTSM database, and storing a data file representing an association of the realized topology with data describing attributes of a number of nodes of the realized topology and relationships between the nodes.

The present disclosure relates to automating <NUM> slices using real-time analytics. The objectives of the present invention are achieved through the subject-matter of the independent claims <NUM>, <NUM> and <NUM>, respectively claiming a method, an apparatus and a system.

The present disclosure relates to systems and methods for automating <NUM> slices using real-time analytics. The present disclosure enables lifecycle management operation with management and monitoring systems and 5GC NFs. The present disclosure leverages orchestration features using anomaly detection from monitoring systems to reduce the disturbance of services. Advantageously, this approach transforms a monitoring system into an active element of the network orchestration cycle. For <NUM> network operators, this enables real-time automation and dynamic creation of slices considering the real-time status and anomaly reports, reducing the lifecycle management operations by including only the necessary operations as defined by the workflow.

With <NUM>, the transformation towards a self-optimized network must implement the necessary tools for sensing network status and analyze the necessary subsequent actions. Remarkably, the <NUM> have those technical enablers defined already through the management data analytics service (MDAS). This service provides data analytics of different network components through monitoring element status, load levels, resources, etc. The acquired parameters are representative performance data for objects, network functions (NFs), network slices, and segments. Those analytics are ingested into the policy control function of that slice or service type to determine compliance with predefined status rules. This analytical system allows for balancing the service and preventing any interruptions resulted from unexpected incoming load or lack of enough processing resources. The MDAS has all the necessary functions that can be deployed across the network sites for on-time determination of network status. However, this service is still limited to policy enforcement functionalities and limited predictive/behavorial/anomaly detection. The MDAS needs to be interfaced to NFV management and orchestration (MANO) framework. This would allow orchestrators to access the telemetry services of both logic and physical networks for an automotive network that can devise its own resource management policies.

The <NUM> performance promises motivated all the technical advances that have been made over the last few years. However, there is still a need to understand the exact capabilities of those new network components and their compliance within fully automated architectures. Therefore, operators will need to deploy testing tools that operate in a live network to verify the functionality and tolerance of network components. This process will need to be implemented for every single software and hardware component to define refinement aspects and resilience factors. Moreover, conducting various analytics will allow research and development teams to provide the necessary solutions that resolve any <NUM> defects and define the initiative for beyond <NUM> networks.

Accordingly, the present disclosure relates to systems and methods for automating <NUM> slices using real-time analytics.

<FIG> is a block diagram of a cloud-based network <NUM> in a distributed service deployment. The <NUM> core (5GC) components will be segregated between a mobile edge cloud (MEC)/remote datacenter <NUM> and a central datacenter <NUM> where the main 5GC slice is located. A new radio (NR) <NUM> can communicate with components in the remote datacenter <NUM> via an N3 interface. The remote datacenter <NUM> can include user plane functions (UPF), IP services, etc. The NR <NUM> can communicate with the central datacenter <NUM> via N1/N2 interfaces. The central datacenter <NUM> can include unified data management (UDM), policy control functions (PCF), access and mobility management functions (AMF), session management functions (SMF), etc. The advantage of this architecture is it reduces the time delays through local access to user plane (UP) traffic. Also, there can be an orchestrator <NUM> connected to the remote datacenter <NUM> and the central datacenter <NUM>. As is known in the art, the orchestrator <NUM> can be a processing device that is configured to implement various functions described herein.

<FIG> is a block diagram of network data analytics function (NWDAF) functionality <NUM> to collect NFs status, metrics, etc. The NWDAF functionality <NUM> is implemented in the remote datacenter <NUM> and the central datacenter <NUM>. Monitoring will include radio resources and UE connectivity on the RAN side and anomaly detection on the core side for cross-layer management and monitoring between the orchestrator <NUM> and a software-defined networking (SDN)/NFV-enabled control layer <NUM>. It is possible to prioritize the request processing subject to radio resource availability. Monitoring and troubleshooting, and diagnosis are merged with the NWDAF functionality <NUM> for convergent network/traffic management and utilization. Using all ingested data, the orchestrator would be able to perform LCM operations soon after discovering the topology changes and association between elements of different layers.

Monitoring this distributed topology will involve:.

As described herein, virtual probes or simply probes can be software, such as NFVs that are configured to analyze real-world network traffic and obtain reliable insight into subscriber experience, analyze the performance and behavior of network components in a dynamic environment via KPIs and KQIs, generate call data records to troubleshoot any issue on the network and identify its root cause, and the like.

The probes <NUM> can be configured to obtain data on the N1 and/or N2 interfaces as well as based on service-based interfaces (e.g., hypertext transfer protocol (HTTP)). The obtained data can be published on a message bus <NUM> for storage <NUM> or use in a trusted shell (TSH) session.

<FIG> is a diagram of interactions between a <NUM> air interface, SDN controller, orchestration layer, telemetry services, and CNFs for validation and assurance. There are multiple service slices in <NUM> cores. There are multiple <NUM> cores up and running based on a number of supported slice services. Each core is associated with a certain logic network that is identified by the slice/service type (SST). Orchestrators/SDNs manage the association of components and large-scale topology.

<FIG> is a network diagram of digital infrastructure for three example slices, slice #A, #B, #C. <FIG> is a diagram of probe <NUM> orchestration. First, the probes <NUM> are referred to as vProbes, virtual probes, and can be CNFs. Specifically, if a probe <NUM> is out-of-order, a healing procedure can be automatically triggered for high availability and less administration. A monitoring system <NUM> can detect issues with the probe <NUM> and set a standby probe <NUM> to active and request a healing procedure via the orchestrator <NUM>, via a CNF manager (CNFM) <NUM> that initiates the request and virtual infrastructure manager (CIM) <NUM> that allocates or liberates the associated resources.

The probes <NUM> and NFs collect anomaly data from different network cores and ingest them into big data or the monitoring system <NUM>. The sessions are processed in various distributed core elements without having synchronization between clouds or proactive recovery LCM using probe analytics.

The present disclosure includes a workflow engine as a middle layer between the monitoring system <NUM> and the orchestrator <NUM> to trigger dynamic LCM events for associated clouds. The anomaly events could also be used to trigger LCM for probes. That is, the present disclosure utilizes slice internal analytics to automate logic networks for <NUM> and beyond. Sessions are processed in various distributed core elements without having synchronization between clouds or proactive recovery lifecycle management (LCM) using probe analytics.

Existing monitoring approaches lack any self-healing mechanism to handle scalability or issues found during self-troubleshooting, have no ability to enforce the instantiation of dedicated probes/data storage that can handle specific sets of data or certain datacenters, and there is no mechanism to adapt solution topology to meet the changes in network or footprint. Existing monitoring approaches are not compliant with zero-touch visions, i.e., automated approaches.

In the 5GC network, the LCM is managed using Kubernetes or the orchestrator <NUM> without any consideration to analytics obtained in real-time from the cloud. Operators use a monitoring solution to detect anomalies without leveraging the troubleshooting reports for real-time LCM operations, especially in large-scale networks. 5GC NFs will be distributed across multiple data raising questions about the of the mechanism that NFV/MANO will use to handle balanced loads across clouds.

<FIG> is a network diagram illustrating automatic workflow generation for the cloud-based network <NUM>. The following interfaces, groups, and components are utilized herein. An interface #<NUM> includes user plane (UP) probes 40U that capture UP traffic from UPF interfaces on the central cloud or intermediate UPF (I-UPF) on MEC clouds. The interface #<NUM> also includes RAN probes 40R located at the RAN, edge cloud, etc., and fiber probes 40F in the optical network.

An interface #<NUM> includes control plane (CP) probes 40C that capture signaling messages from 5GC NFs/service-based architecture (SBA).

An interface #<NUM> includes a capture unit <NUM> that is an NF that is configured to collects messages from the NWDAF <NUM>.

Group #<NUM> includes all data collected from the MEC datacenter(s) <NUM>. Group #<NUM> includes all data collected from the central datacenter <NUM>.

Component #<NUM> is data storage <NUM> for the solution. This could also be replicated with other components in local datacenters as explained below.

Component #<NUM> is the monitoring system <NUM> including probe counters, MDAS analytics, and probe alarms.

Interface #<NUM> is an application programming interface (API) <NUM>, such as a representational state transfer (REST) API, use to export anomaly alarms in form of commands to a workflow engine <NUM>.

Component #<NUM> is the workflow engine <NUM> or service that is used to execute processes (alarms, binaries) on the monitoring system <NUM> via specified virtual instances through the REST APIs <NUM> accessible in a cloud environment (e.g., mistral). For example, the workflow engine <NUM> can be implemented in the monitoring system <NUM>.

Interface #<NUM> includes APIs <NUM>, such as REST APIs, for embedding the workflow processes into the TOSCA templates <NUM>.

Component #<NUM> is the network grand orchestrator <NUM> component used for network automation. It involves two functions for the proposal: Automated update of TOSCA templates or automated creation of new one to define new LCM operation <NUM> and to enforce TOSCA Updates by triggering new Modify operation that updates the VNF descriptor by adding the new interface for the newly defined operation.

Interface #<NUM> is an API <NUM>, such as a REST API, used to connect the network orchestrator <NUM> with the datacenters <NUM>, <NUM>. APIs aligned with MEF standard should be a good implementation example of this interface.

In an embodiment, there can be encryption between the various components of the all monitoring solution including smaller elements of any component. Moreover, it is possible to use field encryption to hide the subscriber information (e.g., IMSI) across the solution.

Continuing with <FIG>, there are various data sources that collect various counters and messages from different interfaces and NFs. As described herein, the interfaces are as described above. The NFs can be CNFs or physical devices, including various components in the datacenters <NUM>, <NUM>.

The monitoring system <NUM> advantageously is able to obtain a view of the entire network via the probes 40C, 40U, 40R, 40F and the capture units <NUM>. The probes <NUM> are configured to obtain telecom related data and the capture units <NUM> are configured to obtain computing-related date (i.e., virtualized Information Technology (IT) infrastructure). The monitoring system <NUM> has the ability to correlate the telecom and IT data.

The RAN probe 40R captures info from a base station about user equipment (UE) location, RAN data, available frequency bands, available bandwidths, degradation in air interface through specific measurements of quality of service (QoS), drop reasons, throughput, transmission volume for each connection, transmission volume for each base station. The RAN probe 40R draws the topology for the network, can use call trace to add UE details, and then use another enrichment interface to capture international mobile subscriber identity (IMSI) for mapping UE location, status, transmission profile with passive monitoring solution on the core side.

The fiber probe 40F can tap into the transport network that connects various segments of the network and provides alarms about fiber cracks and deviation in performance caused by reflections or loss. Those probes also report alarms to the monitoring system <NUM> through API. This also allows to draw granularity per fiber link that allows visibility of fiber topology to the central monitoring system.

Again, the CP probes 40C capture all CP signaling for all 5GC interfaces, and the UP probes 40U capture UP traffic on the 5GC. The RAN probe 40E captures UE transmission profile (air interface domain), and the fiber probe 40F monitors the fiber (transport) network.

The monitoring system <NUM> captures telecom KPIs using the passive monitoring probes <NUM> and can correlate to captured analytics by the capture unit <NUM> NFs subscribed to the NWDAF <NUM>. For example, delays in UE registration or messages between NFs may be caused by <NUM>) overloaded NFs (limited computational resources) or <NUM>) NF functionality failures. The monitoring system <NUM> can process all probes data and NWDAF analytics to diagnose the error cause and trigger the necessary actions (probe instantiation or core network LCM).

The monitoring system <NUM> can select sets of KPIs and apply formulas to detect anomalies triggering LCM. Here, the monitoring system <NUM> can create subfamilies of KPIs Driving new LCM operations to LCM for the various architectures described herein. Finally, the monitoring system <NUM> can create rules that generate alarms. As described herein, lifecycle management relates to end customer experience, such as QOS, quality of experience (QOE), service layer agreements (SLA), root cause analysis, troubleshooting, etc. That is, the lifecycle management relates to anything in the 5GC that impacts service to subscribers.

The API <NUM> for the interface #<NUM> can be a consumer that is created to parse anomaly related LCM. Responsive to anomaly detection, a customized workflow creation can be triggered to perform new remediations actions with new LCM operation "custom," described below.

The workflow engine <NUM>, component #<NUM>, can push the newly created workflow to the orchestrator <NUM> through a network service (NS) Lifecycle management interface in the form of a subfile TOSCA format and/or YANG models for a CNF configuration.

The orchestrator <NUM>, the component #<NUM>, can embed the new workflow to the onboarded CNF package and enforce TOSCA updates (interfaces section considers the new workflow) via a CNF package management interface sol005. The workflow management component enforces the orchestrator to launch the modify LCM operation to update the CNF package via NS LCM sol005 Interface.

The API <NUM> for the interface #<NUM> can be used to perform the custom LCM operation by triggering the custom operation from the workflow management <NUM> component to perform the newly created workflow with remediation actions.

The monitoring system <NUM> via the workflow engine <NUM> can cause probe instantiation or core network LCM. For the probe insanitation, once an anomaly is detected, or alarms from NWDAF, or new NFs instantiated, or following network LCM transitions that cause new topology/core to exist, a generic or dedicated probe <NUM> is instantiated or removed.

For the core network LCM, once the source of an anomaly is detected to be network related issue - for example, NF failure, NF scalability, topology, connectivity issues between core network components that are distributed over multiple clouds, etc., this proposed solution will trigger core network LCM: <NUM>) recreate NFs, or assign resources or, migrate NFs, etc. <NUM>) trigger a <NUM>nd probe LCM to reattach probes to the new workflow for continuous monitoring.

Events triggered by the monitoring system <NUM> are used to capture a subset of anomaly data from a 5GC slice (datacenters <NUM>, <NUM>). This is performed with zero touch operation: events are triggered by a prediction engine associated with the monitoring system <NUM>.

The custom operations defined in the proposed workflow could be related to the probes <NUM> or other NFs. This can include, for example, instantiating a new component (either a new data source, dedicated probe, cluster-based data storage (elastic search), and the like; scaling an existing component (or subcomponents) without affecting existing CNFs/NFs/NS; healing the monitoring system <NUM>; modifying an existing component (probe to be dedicated for a certain subset of data or selected NFs through rules modification); terminating components of the monitoring system <NUM>, including removing a dedicated probe after restoring normal operation, releasing the associated resource to reduce the footprint, etc..

There can be custom monitoring system <NUM> operations, such as a change in the topology (example: adding new data storage for certain data centers to reduce the signaling and data transmission between probes located in multiple sites). This can be achieved by pushing multiple custom workflows triggered by massive sudden increase in the traffic captured in certain network sites. The instantiation of multiple dedicated probes <NUM> and the request from the customer to have dedicated data storage for a subset of data. Dynamic adaptation in the monitoring system <NUM> reduces the overall footprint/consumed resources. This operation is driven by network scalability events, for self-optimization and self-troubleshooting of the monitoring system <NUM>.

For custom core network operations, the anomaly indicators can be used to trigger LCM events that recover network function normal and optimum behavior. This can include deciphering TLS1. <NUM> on 5GC HTTP/<NUM> interfaces for automated capture of network messages. There is a need to use specific mechanism that include NF attached sensors to retrieve the keys for the probe capturing unit.

This can also include harmonizing the processing capacity between components (network functions) for the core located in different datacenters <NUM>, <NUM>. This includes scalability load balancing, traffic diversion, etc. The <NUM> NFs may be located in multiple cloud datacenters <NUM>, 14and there is a need to synchronize the amount of resource dedicated for those NFs based on the incoming traffic.

This can also include using the topology to maintain the connectivity between various <NUM> core NFs for more robust network infrastructure. This can use a repository of the NFs explored by the monitoring system <NUM> to identify any missing or failed <NUM> core network functions during correlation between different time events to trigger network lifecycle management from the orchestrator <NUM> through the proposed workflow.

<FIG> is a flow diagram of a framework to perform custom operations <NUM>. A new workflow is created by the workflow engine <NUM> (step <NUM>-<NUM>). The new workflow is pushed then to the orchestrator through the CNF package management interface (step <NUM>-<NUM>). The onboarded CNFM package is updated with the new LCM custom to perform the new workflow (step <NUM>-<NUM>). The modify LCM operation is triggered by the workflow management operation and launched by the orchestrator <NUM> (step <NUM>-<NUM>). The custom LCM operation is triggered by the workflow management operation and launched by the orchestrator to perform the new workflow (step <NUM>-<NUM>).

<FIG> is a flowchart of a workflow service process <NUM> implemented by the workflow engine <NUM>. The process <NUM> can be implemented as a method that includes steps, via a processing device configured to execute the steps, and via a non-transitory computer-readable medium that includes instructions that cause one or more processors to implement the steps.

The process <NUM> includes obtaining <NUM> data from a plurality of interfaces <NUM>, <NUM> and network functions, NF <NUM>, in one or more datacenters <NUM>, <NUM> associated with a <NUM> core, 5GC, network, wherein the data relates to lifecycle management in the 5GC network; responsive <NUM> to analyzing the data with a set of key performance indicators, KPI, and rules associated therewith that are formulated to detect anomalies that impact the lifecycle management, generating an alarm based on the analyzing based on detection of an anomaly that impacts the lifecycle management; and creating <NUM> a workflow based on the alarm and pushing the workflow to the 5GC network via an orchestrator <NUM>.

The process <NUM> can further include the orchestrator <NUM> receiving the workflow as a topology and orchestration specification for cloud applications, TOSCA, template and triggering the workflow as a custom lifecycle management operation. The process <NUM> can further include obtaining the data from the plurality of interfaces and the NF via a monitoring system <NUM> and performing the analyzing via an analytics engine <NUM>. The monitoring system <NUM> and the workflow engine <NUM> can communicate through application programming interfaces, APIs, in a cloud environment.

The plurality of interfaces can include connections to probes <NUM> that are virtual network functions, CNF, configured to monitor any of a user plane, UP, and control plane, CP.

The NF are components configured to perform a network data analytics function, NWDAF <NUM>.

The workflow is one of a modify operation and a custom operation, each for a virtual network function, CNF, in the 5GC network.

The workflow is a custom operation to instantiate a new virtual network function, CNF, in the 5GC network, via the orchestrator <NUM>. The custom operation includes any of instantiating a new component in the 5GC network, scaling an existing component in the 5GC network, healing an existing component in the 5GC network, and terminating an existing component in the 5GC network.

The obtaining, the generating, and the creating are performed in real-time during operation of the 5GC network.

<FIG> is a network diagram of multi-cloud automation. A management data analytics system (MDAS) is a system that deploys Data analytics functions (DAFs) across all network segments from the RAN to the core to collect the functional status of network components. The CP probe 40C, UP probe 40U, and RAN probe 40R allow monitoring of sessions per UE from the air interface to core network with all associated NFs (components) and anomalies. This data can be correlated with MDAS for sophisticated smart diagnose of error cause.

The fiber probe 40F monitors the fiber connections between data centers (or multi access edge computing (MEC) nodes). The monitoring probes will detect anomaly and changes in performance/ behavior on data centers where fiber connects them. Anomalies from probes and alarms from fiber probes will be used by the monitoring system <NUM> to trigger a change in topology of the network either by <NUM>) migrating components to avoid defective fiber link, <NUM>) use the topology that has been built by monitoring solution to adapt connectivity using alterative links. The monitoring system <NUM> can corelate fiber probe alarms with MDAS data to detect QoS impacts and trigger necessary LCMs.

<FIG> is a block diagram of a service-based architecture with active verifiers <NUM>. The active verifier <NUM> is an active small NF element that generates messages similar to any NF in the 5GC. To ensure core network functionality, the verifiers <NUM> are instantiated on selected NFs to trigger messages in the core. This allows monitoring solutions to determine functionality and performance by capturing the messages through probes. This can be also used to analyze functionality of certain components (e.g., RabbitMQ when used as a message bus between NFs in SBA). This transforms a solution from passive to active monitoring, and self-troubleshooting of the probes when a certain probe is malfunctioning - messages are triggered through the verifier <NUM> and check if the probe can capture this message and time of capturing compared with the time of sending. Also, the verifier <NUM> is useful to determine the NWDAF functionality in self-troubleshooting mode. The process of launching the verifiers is also triggered by the monitoring system <NUM> and through workflow changes.

<FIG> is a block diagram of a processing apparatus <NUM> which may be used to realize any of the components described herein. The processing apparatus <NUM> may be a digital computer that, in terms of hardware architecture, generally includes a processor <NUM>, input/output (I/O) interfaces <NUM>, a network interface <NUM>, a data store <NUM>, and memory <NUM>. It should be appreciated by those of ordinary skill in the art that <FIG> depicts the processing apparatus <NUM> in an oversimplified manner, and practical embodiments may include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein. The components (<NUM>, <NUM>, <NUM>, <NUM>, and <NUM>) are communicatively coupled via a local interface <NUM>. The local interface <NUM> may be, for example, but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface <NUM> may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, among many others, to enable communications. Further, the local interface <NUM> may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor <NUM> is a hardware device for executing software instructions. The processor <NUM> may be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the processing apparatus <NUM>, a semiconductor-based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions. When the processing apparatus <NUM> is in operation, the processor <NUM> is configured to execute software stored within the memory <NUM>, to communicate data to and from the memory <NUM>, and to generally control operations of the processing apparatus <NUM> pursuant to the software instructions. The I/O interfaces <NUM> may be used to receive user input from and/or for providing system output to one or more devices or components. User input may be provided via, for example, a keyboard, touchpad, and/or a mouse. The system output may be provided via a display device and a printer (not shown). I/O interfaces <NUM> may include, for example, a serial port, a parallel port, a small computer system interface (SCSI), a serial ATA (SATA), a fibre channel, Infiniband, iSCSI, a PCI Express interface (PCI-x), an infrared (IR) interface, a radio frequency (RF) interface, and/or a universal serial bus (USB) interface.

The network interface <NUM> may be used to enable the processing apparatus <NUM> to communicate over a network, such as the Internet, a wide area network (WAN), a local area network (LAN), and the like, etc. The network interface <NUM> may include, for example, an Ethernet card or adapter (e.g., 10BaseT, Fast Ethernet, Gigabit Ethernet, 10GbE) or a wireless local area network (WLAN) card or adapter (e.g., <NUM>. 11a/b/g/n/ac). The network interface <NUM> may include address, control, and/or data connections to enable appropriate communications on the network. A data store <NUM> may be used to store data. The data store <NUM> may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store <NUM> may incorporate electronic, magnetic, optical, and/or other types of storage media. In one example, the data store <NUM> may be located internal to the processing apparatus <NUM> such as, for example, an internal hard drive connected to the local interface <NUM> in the processing apparatus <NUM>. Additionally, in another embodiment, the data store <NUM> may be located external to the processing apparatus <NUM> such as, for example, an external hard drive connected to the I/O interfaces <NUM> (e.g., SCSI or USB connection). In a further embodiment, the data store <NUM> may be connected to the processing apparatus <NUM> through a network, such as, for example, a network attached file server.

The memory <NUM> may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.), and combinations thereof. Note that the memory <NUM> may have a distributed architecture, where various components are situated remotely from one another but can be accessed by the processor <NUM>. The software in memory <NUM> may include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. The software in the memory <NUM> includes a suitable operating system (O/S) <NUM> and one or more programs <NUM>. The operating system <NUM> essentially controls the execution of other computer programs, such as the one or more programs <NUM>, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The one or more programs <NUM> may be configured to implement the various processes, algorithms, methods, techniques, etc. described herein.

It will be appreciated that some embodiments described herein may include or utilize one or more generic or specialized processors ("one or more processors") such as microprocessors; Central Processing Units (CPUs); Digital Signal Processors (DSPs): customized processors such as Network Processors (NPs) or Network Processing Units (NPUs), Graphics Processing Units (GPUs), or the like; Field-Programmable Gate Arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more Application-Specific Integrated Circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as "circuitry configured to," "logic configured to," etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.

Moreover, some embodiments may include a non-transitory computer-readable medium having instructions stored thereon for programming a computer, server, appliance, device, one or more processors, circuit, etc. to perform functions as described and claimed herein. Examples of such non-transitory computer-readable medium include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically EPROM (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by one or more processors (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause the one or more processors to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

Claim 1:
A method (<NUM>) implemented by a workflow engine (<NUM>) comprising:
obtaining (<NUM>) data from a plurality of distributed probes (<NUM>) and network functions, NF (<NUM>), in one or more datacenters (<NUM>, <NUM>) associated with a <NUM> core, 5GC, network, wherein the data relates to lifecycle management in the 5GC network and includes telecom data from the distributed probes (<NUM>) and computing data from the NF (<NUM>);
responsive (<NUM>) to analyzing and correlating the telecom data and the computing data to detect anomalies that impact the lifecycle management, generating an alarm based on the analyzing based on detection of an anomaly that impacts the lifecycle management; and
creating (<NUM>) a workflow based on the alarm and pushing the workflow to the 5GC network via an orchestrator (<NUM>), wherein the workflow includes instantiating at least one distributed probe as a virtual network function, VNF, during operation of the 5GC network and responsive to the analyzing and correlating the telecom data, for obtaining specific sets of data, and wherein the at least one distributed probe is located in any of a user plane, a control plane, a radio access network and a fiber network.