Intent conformance in a cloud-based network system

Abstract

A method in an intent management node and an intent management node are provided. The method includes generating a formal model based on the system, determining a service graph based on the intent and validating the compliance of the intent in the system based on the formal model and the service graph.

Description

[0001] INTENT CONFORMANCE IN A CLOUD-BASED NETWORK SYSTEM

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to wireless communications, and in particular, to configurations for supporting intent conformance in a system, such as a cloud-based network system.

[0004] BACKGROUND

[0005] The Third Generation Partnership Project (3 GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and mobile wireless devices (WD), as well as communication between network nodes and between WDs. The 3 GPP is also developing standards for Sixth Generation (6G) wireless communication networks.

[0006] Intent- Driven Networking is a paradigm that aims to bring intelligence to traditional networks. This intelligence not only aids professional network administrators in managing the network, but also aids users who may lack specific knowledge of the network operating the underlying system. European Telecommunications Standards Institute (ETSI) Experiential Networked Intelligence (ENI) defines an intent policy as a set of operational goals that a network should meet and outcomes that a network is supposed to deliver, defined in a declarative manner without specifying how to achieve or implement them. For example, an intent may be defined as “A web service to handle 1000 transactions per minute and provide the highest levels of security and reliability, with latency no longer than 3 seconds”.

[0007] In some existing systems and solutions, an intent-based service configuration, conformance, and auditing system may be provided, in which a customer provides a request for network services which might include information regarding specific hardware, hardware type, location, or specific networks to provide the network services. An engine determines whether the identified resources conform with the desired characteristics of the customer, for example, by measuring network performance metrics for the identified resources. If the resources do not conform with the desired characteristics, the system may reconfigure the network resources to provide the desired characteristics and performance. In some existing systems and solutions, intent conflict prediction has been applied in domains such as the aircraft domain. For example, methods exist for controlling aircraft height limitation. Such solutions perform conflict detection based on aircraft trajectory and intended flight path. Such solutions are not applicable to a system such as a cloud based system or network, however.

[0008] In some existing systems and solutions, conflicts among issued instructions may be predicted based on the issuer’s intent and the management of information exchange between automated systems. Such solutions may perform predictive error checking and conflict resolution by comparing the received data with application-specific knowledge data. The application- specific domain knowledge is represented by an ontology.

[0009] In some existing systems and solutions, a system for intent-based service configuration and service conformance is provided to check whether the assigned resources can support the service from a plurality of potential resources. This is done by analyzing meta-data regarding resource attributes and characteristics of unassigned network resources.

[0010] In some existing systems and solutions, a query language is utilized for user intent expression and web ontology and resource description framework to aid the processing of user intents, e.g., for a virtual network function (VNF) chaining application. This may apply, for example, to a network slice design phase, e.g., for determining all the network slice solutions from tenant intents, while taking into account operator policies. Such solutions may be designed to satisfy a tenant’s intent while automatically complying with the operator policies.

[0011] In some existing systems and solutions, an approach for facilitating high-level management-plane policy configuration conformance auditing and their reflection in the data plane is provided, e.g., to detect missing or spurious flow rules with respect to security policies. Existing systems and solutions, however, lack suitable configurations for supporting intent conformance in systems such as cloud-based network systems.

[0012] SUMMARY

[0013] Existing systems and solutions typically focus on detecting problems related to intent during a runtime phase. Such solutions are not proactive, as they do not check the requested configuration before the actual deployment, which may increase the number of conflicts / errors that a runtime system must handle. Further, existing systems and solutions typically detect conflicts between several received intents and not between an intent and the infrastructure where to deploy the intent or between the intent and the operator policies.

[0014] Further, existing systems and solutions do not utilize formal models, as described herein, for validating intent conformance.

[0015] Some embodiments advantageously provide methods, systems, and apparatuses for supporting intent conformance in a system, such as a cloud-based network system. Thus, references herein to “a cloud” or “the cloud” refer to a cloud-based network system. One example of such a system is the Internet.

[0016] For example, some embodiments of the present disclosure provide a system and a method for automatically analyzing an input intent in order to check the conformance of the requested configurations, e.g., before the actual deployment of such intent. Some embodiments of the present disclosure, for example, receive as inputs a system description and an intent, along with the intent’s requirements, check the validity of the intent requirements against the given system to create a validation result, and generate validity information and / or perform actions in response to checking the validity, i.e., in response to the validation result, such as generating an intent conformance report indicating whether the requested configuration is valid or not. If the requested configuration is valid, the intent may be deployed in the system, otherwise, the requested configurations may be analyzed, and changes may be suggested or implemented, e.g., to the required configuration in the intent (e.g., decreasing resource demand) and / or to the system operator (e.g., including / adding specific hardware or nodes at specific locations in the system).

[0017] Some embodiments provide a system and a method to check the conformance of the requested configuration of an input intent on a given infrastructure, e.g., before the actual deployment of the intent.

[0018] For example, in some embodiments, a method for a management node, such as an intent management node, is provided which: receives and analyzes an input intent; extracts a description of the cloud system model and the underlying infrastructure; obtains / receives / determines / etc. a list of components composing the cloud system including components, their dependencies, their properties, etc.; builds a formal model to describe the behavior of the cloud system and its infrastructure; applies the input intent (e.g., service graph) on the formal model using a model checker; checks functional and / or non-functional requirements of the input intent by verifying the output generated by the model checker (e.g., valid or not valid + traces), such that:

[0019] When the requirements are met, a request is sent to deploy the received intent, and the formal model is updated with the new changes accordingly;

[0020] When the requirements are not met, the traces generated by the model checker are analyzed to identify possible changes, e.g., using inductive reasoning, and appropriate changes are generated / determined, and indications of such changes are sent to the corresponding entities.

[0021] Some embodiments may advantageously support early detection of intent validity and its conformance with the underlying infrastructure, and accordingly may inform the corresponding entities, e.g., to prevent intent unsatisfaction / violation.

[0022] Some embodiments may advantageously build policies and / or constraints that may be used to conform intent validity.

[0023] Some embodiments may advantageously reduce the number of errors and / or conflicts to be handled at the run-time by the system.

[0024] Some embodiments may advantageously reduce the need for human intervention in checking the required actions to be applied (e.g., service re-composition, resources configurations, etc.) and service performance management.

[0025] According to a first aspect of the present disclosure, a method in an intent management node is provided. The method includes generating a formal model based on the system, determining a service graph based on the intent and validating the compliance of the intent in the system based on the formal model and the service graph.

[0026] According to one or more embodiments of this aspect, the system comprises a plurality of components, a plurality of dependencies of the components, and a plurality of properties of the components, and the method further comprises generating the formal model based on the plurality of components, the plurality of dependencies of the components, and the plurality of properties of the components. According to one or more embodiments of this aspect, the intent comprises a plurality of functional requirements and a plurality of non- functional requirements, and the method further comprises validating the compliance of the intent in the system by: validating the plurality of functional requirements; and validating the plurality of non-functional requirements.

[0027] According to one or more embodiments of this aspect, the method further comprises generating at least one validation result based on the validating of the compliance of the intent in the system. According to one or more embodiments of this aspect, wherein the method further comprises generating an intent conformance report based on the at least one validation result. According to one or more embodiments of this aspect, the method further comprises causing deployment of the intent in the system based on the at least one validation result. According to one or more embodiments of this aspect, the method further comprises updating the formal model based on the deployment of the intent in the system.

[0028] According to one or more embodiments of this aspect, validating the compliance of the intent in the system based on the formal model and the service graph is performed prior to the deployment of the intent in the system. According to one or more embodiments of this aspect, the method further comprises modifying at least one of the intent and the service graph based on the at least one validation result.

[0029] According to one or more embodiments of this aspect, the service graph corresponds to interactions and / or interdependencies between a plurality of services, and the method further comprises modifying at least one interaction and / or interdependency based on the at least one validation result. According to one or more embodiments of this aspect, the method further comprises generating the formal model by receiving a system description associated with the system, the system description comprising at least one of: at least one configuration file associated with the system; at least one log trace associated with the system; metrics data associated with the system; and system events data associated with the system.

[0030] According to one or more embodiments of this aspect, the method further comprises validating the formal model prior to validating the compliance of the intent in the system and tuning at least one parameter of the formal model based on at least one of result of validating the formal model. According to one or more embodiments of this aspect, the formal model corresponds to a communication sequential process (CSP) model. According to one or more embodiments of this aspect, the method further comprises determining a linear temporal logic (LTL) description of the service graph and validating the compliance of the intent in the system is based on the LTL description.

[0031] According to another aspect of the present disclosure, an intent management node is provided. The intent management node is configured to generate (Block S100) a formal model based on the system, determine (Block S102) a service graph based on the intent and validate (Block S104) the compliance of the intent in the system based on the formal model and the service graph.

[0032] According to one or more embodiments of this aspect, the system comprises a plurality of components, a plurality of dependencies of the components, and a plurality of properties of the components, and the processing circuitry is further configured to generate the formal model based on the plurality of components, the plurality of dependencies of the components, and the plurality of properties of the components. According to one or more embodiments of this aspect, the intent comprises a plurality of functional requirements and a plurality of non-functional requirements, and the processing circuitry is further configured to validate the compliance of the intent in the system by: validating the plurality of functional requirements; and validating the plurality of non-functional requirements.

[0033] According to one or more embodiments of this aspect, the processing circuitry is further configured to generate at least one validation result based on the validating of the compliance of the intent in the system. According to one or more embodiments of this aspect, the processing circuitry is further configured to generate an intent conformance report based on the at least one validation result. According to one or more embodiments of this aspect, the processing circuitry is further configured to cause deployment of the intent in the system based on the at least one validation result. According to one or more embodiments of this aspect, the processing circuitry is further configured to update the formal model based on the deployment of the intent in the system. According to one or more embodiments of this aspect, validating the compliance of the intent in the system based on the formal model and the service graph is performed prior to the deployment of the intent in the system.

[0034] According to one or more embodiments of this aspect, the processing circuitry is further configured to modify at least one of the intent and the service graph based on the at least one validation result. According to one or more embodiments of this aspect, the service graph corresponds to interactions and / or interdependencies between a plurality of services, and the processing circuitry is further configured to modify at least one interaction and / or interdependency based on the at least one validation result.

[0035] According to one or more embodiments of this aspect, the processing circuitry is further configured to generate the formal model by receiving a system description associated with the system, the system description comprising at least one of: at least one configuration file associated with the system; at least one log trace associated with the system; metrics data associated with the system; and system events data associated with the system.

[0036] According to one or more embodiments of this aspect, the processing circuitry is further configured to validate the formal model prior to validating the compliance of the intent in the system and tune at least one parameter of the formal model based on at least one of result of validating the formal model. In some embodiments, the formal model corresponds to a communication sequential process (CSP) model. According to one or more embodiments of this aspect, the processing circuitry is further configured to determine a linear temporal logic (LTL) description of the service graph, and validating the compliance of the intent in the system is further based on the LTL description.

[0037] BRIEF DESCRIPTION OF THE DRAWINGS

[0038] A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

[0039] FIG. 1 is a schematic diagram of an example network architecture illustrating a communication system according to principles disclosed herein;

[0040] FIG. 2 is a block diagram of a network node in communication with a wireless device over a wireless connection and in communication with a management node and core node over a wireless and / or wired connection, according to some embodiments of the present disclosure;

[0041] FIG. 3 is a flowchart of an example process in a management node, such as an intent management node, for supporting intent conformance in a system, such as a cloud system, according to some embodiments of the present disclosure; FIG. 4 is a flowchart of another example process for supporting intent conformance in a system, such as a cloud system, according to some embodiments of the present disclosure;

[0042] FIG. 5 is a flowchart of another example process for supporting intent conformance in a system, such as a cloud system, according to some embodiments of the present disclosure;

[0043] FIG. 6 is a flowchart of an example process for building a formal model for supporting intent conformance in a system, such as a cloud system, according to some embodiments of the present disclosure;

[0044] FIG. 7 is a flowchart of an example intent translation, according to some embodiments of the present disclosure; and

[0045] FIG. 8 is a flowchart of another example intent translation, according to some embodiments of the present disclosure.

[0046] DETAILED DESCRIPTION

[0047] Before describing in detail example embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to intent conformance in a system, such as a cloud system. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0048] Intent- Driven Networking aims to bring automation to the network, which may assist professional administrators in network management to handle conflicts / violations in a faster way as compared to current solutions. However, many problems or issues may occur while executing an intent, which may lead to an intent violation or service failure / degradation. Hence, an intent violation / unsatisfaction event may be triggered only after an intent is deployed, for example, by cloud system problems such as infrastructure hardware issues, cloud management software issues, shortages of resources and security attacks, etc. In most cases, intent violations / unsatisfaction, conflicts, or problems, are typically only detected after the deployment and execution stages. Existing solutions are typically reactive, meaning that they check what caused a problem after deploying an intent, and thus require recovery actions to repair such problems by providing more resources or reconfiguring the required services in an intent. As a result, such solutions may have additional and expensive costs that impact the quality of intent services and hence the satisfaction of the users. Therefore, there is a need to validate and check the validity of a received intent to create a validation result before deploying it on the underlying infrastructure and before the actual deployment.

[0049] As used herein, an intent may correspond to a high-level description of QoE in software defined networking (SDN), and / or a policy / rule definition for service orchestration. In embodiments of the present disclosure, intent may be generalized as a business goal definition, e.g., without necessarily including technical details. An intent may be expressed using a natural human language and / or some rule specifications following a certain format. An intent may comply, for example, with a Service Level Agreement (SLA). In embodiments described herein, the intent is not restricted to any specific format, and may be interpreted as “what” requirements need to be met in the cloud, rather than “how” to meet such requirements. For example, requirements may be grouped into (a) functional and (b) non- functional requirements, defined as:

[0050] Functional requirements: these define what a software, hardware, function, network, system, etc., must do and how the system must respond to inputs and generate the output (e.g., calculations, technical details, data manipulation, processing, etc.).

[0051] Non-functional requirements: these define the system’s non-fundamental behaviors, such as performance requirements, security requirements, reliability requirements, etc.

[0052] Examples of intents include: o Example 1: “A web service to handle 1000 transactions per minute and provide the highest levels of security and reliability, with latency no longer than 3 seconds”. o Example 2: “Service to provide two Slices. One with minimum throughput of 10 MB / s and the other with 20 MB / s. The second slice shall be able to serve at least 1000 users.”

[0053] Conformance: As used herein, conformance may correspond to a criterion to check the validity of a given intent alongside its translation (e.g., service graph, requirements) on a given system such as a cloud system (e.g., infrastructure, resources, etc.).

[0054] QoE: Quality of Experience may correspond to a measure of the overall level of customer satisfaction with a vendor. QoE is related to but differs from Quality of Service (QoS), which embodies the notion that hardware and software characteristics can be measured, improved, and perhaps guaranteed. In contrast, QoE expresses user satisfaction both objectively and subjectively.

[0055] QoS: Quality of service (QoS) may correspond to a description or measurement of the overall performance of a service, e.g., the performance seen by the users of the network. To quantitatively measure the quality of service, several related KPIs of the network service may be considered, such as response time, throughput, transmission delay, availability, jitter, etc.

[0056] SLA: A Service Level Agreement (SLA) may correspond to a commitment between a service provider and a client. Aspects of the service such as quality, availability, and responsibilities are agreed upon between the service provider and the service user. SLA may include but limited to QoS KPIs.

[0057] As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0058] In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

[0059] In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and / or wireless connections.

[0060] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0061] The term “network node” used herein can be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multistandard radio (MSR) radio node such as MSR BS, multi-cell / multicast coordination entity (MCE), relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), etc. The network node may also comprise test equipment. The term “radio node” used herein may be used to also denote a wireless device (WD) such as a wireless device (WD) or a radio network node.

[0062] In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The WD herein can be any type of wireless device capable of communicating with a network node or another WD over radio signals, such as wireless device (WD). The WD may also be a radio communication device, target device, device to device (D2D) WD, machine type WD or WD capable of machine to machine communication (M2M), low-cost and / or low-complexity WD, a sensor equipped with WD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device etc.

[0063] Also, in some embodiments the generic term “radio network node” is used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell / multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH).

[0064] Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and / or New Radio (NR), may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure.

[0065] Note further, that functions described herein as being performed by a wireless device, core node, management node, intent management node, or a network node may be distributed over a plurality of wireless devices, core nodes, management nodes, and / or network nodes. In other words, it is contemplated that the functions of the network node, core node, management node, and wireless device described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

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

[0067] Some embodiments are directed to supporting intent conformance in a system, such as a cloud system.

[0068] Referring to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in FIG. 1 a schematic diagram of a communication system 10, according to an embodiment, such as a 3GPP-type cellular network that may support standards such as LTE and / or NR (5G), which comprises an access network 12, such as a radio access network, and a core network 13 comprising one or more core nodes 14 for performing core node functions. The core network may also comprise a management node 15 for performing one or more network management functions, which may be a type of core node 14 or a different type of node from core node 14. The access network 12 comprises a plurality of network nodes 16a, 16b, 16c (referred to collectively as network nodes 16), such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 18 a, 18b, 18c (referred to collectively as coverage areas 18). Each network node 16a, 16b, 16c is connectable to the core network 13 over a wired or wireless connection 20. A first wireless device (WD) 22a located in coverage area 18a is configured to wirelessly connect to, or be paged by, the corresponding network node 16a. A second WD 22b in coverage area 18b is wirelessly connectable to the corresponding network node 16b. While a plurality of WDs 22a, 22b (collectively referred to as wireless devices 22) are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole WD is in the coverage area or where a sole WD is connecting to the corresponding network node 16. Note that although only two WDs 22, one core node 14, one management node 15, and three network nodes 16 are shown for convenience, the communication system may include many more WDs 22, core nodes 14, management nodes 15, and network nodes 16.

[0069] Also, it is contemplated that a WD 22 can be in simultaneous communication and / or configured to separately communicate with more than one network node 16 and more than one type of network node 16. For example, a WD 22 can have dual connectivity with a network node 16 that supports LTE and the same or a different network node 16 that supports NR. As an example, WD 22 can be in communication with an eNB for LTE / E-UTRAN and a gNB for NR / NG-RAN.

[0070] A management node 15, which in some embodiments may be referred to as an intent management node 15 and / or a cloud management node 15, may include an intent validity unit 24.

[0071] Example implementations, in accordance with an embodiment, of the WD 22, core node 14, management node 15, and network node 16 discussed in the preceding paragraphs will now be described with reference to FIG. 2.

[0072] The communication system 10 includes a network node 16 provided in a communication system 10 and including hardware 28 enabling it to communicate with the WD 22. The hardware 28 may include a radio interface 30 for setting up and maintaining at least a wireless connection 32 with a WD 22 located in a coverage area 18 served by the network node 16. The radio interface 30 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers. The radio interface 30 includes an array of antennas 34 to radiate and receive signal(s) carrying electromagnetic waves.

[0073] In the embodiment shown, the hardware 28 of the network node 16 further includes processing circuitry 36. The processing circuitry 36 may include a processor 38 and a memory 40. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 36 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 38 may be configured to access (e.g., write to and / or read from) the memory 40, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0074] Thus, the network node 16 further has software 42 stored internally in, for example, memory 40, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the network node 16 via an external connection. The software 42 may be executable by the processing circuitry 36. The processing circuitry 36 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by network node 16. Processor 38 corresponds to one or more processors 38 for performing network node 16 functions described herein. The memory 40 is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 42 may include instructions that, when executed by the processor 38 and / or processing circuitry 36, causes the processor 38 and / or processing circuitry 36 to perform the processes described herein with respect to network node 16.

[0075] The communication system 10 further includes the WD 22 already referred to. The WD 22 may have hardware 44 that may include a radio interface 46 configured to set up and maintain a wireless connection 32 with a network node 16 serving a coverage area 18 in which the WD 22 is currently located. The radio interface 46 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers. The radio interface 46 includes an array of antennas 48 to radiate and receive signal(s) carrying electromagnetic waves.

[0076] The hardware 44 of the WD 22 further includes processing circuitry 50. The processing circuitry 50 may include a processor 52 and memory 54. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 50 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 52 may be configured to access (e.g., write to and / or read from) memory 54, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0077] Thus, the WD 22 may further comprise software 56, which is stored in, for example, memory 54 at the WD 22, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the WD 22. The software 56 may be executable by the processing circuitry 50. The software 56 may include a client application. The client application may be operable to provide a service to a human or non-human user via the WD 22.

[0078] The processing circuitry 50 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by WD 22. The processor 52 corresponds to one or more processors 52 for performing WD 22 functions described herein. The WD 22 includes memory 54 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 56 and / or the client application may include instructions that, when executed by the processor 52 and / or processing circuitry 50, causes the processor 52 and / or processing circuitry 50 to perform the processes described herein with respect to WD 22.

[0079] The communication system 10 further includes the management node 15 already referred to. The management node 15 may have hardware 72 that may include a communication interface 74 configured to set up and maintain a wired and / or wireless connection 62 with one or more core nodes 14 and / or with a network node 16 serving a coverage area 18.

[0080] The hardware 72 of the management node 15 further includes processing circuitry 76. The processing circuitry 76 may include a processor 78 and memory 80. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 76 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs and / or ASICs adapted to execute instructions. The processor 78 may be configured to access (e.g., write to and / or read from) memory 80, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM and / or ROM and / or optical memory and / or EPROM. Thus, the management node 15 may further comprise software 82, which is stored in, for example, memory 80 at the management node 15, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the management node 15. The software 82 may be executable by the processing circuitry 76.

[0081] The processing circuitry 76 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by management node 15. The processor 78 corresponds to one or more processors 78 for performing management node 15 functions described herein. The management node 15 includes memory 80 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 82 may include instructions that, when executed by the processor 78 and / or processing circuitry 76, causes the processor 78 and / or processing circuitry 76 to perform the processes described herein with respect to management node 15, such as with respect to intent validity unit 24.

[0082] The communication system 10 further includes the core node 14 already referred to. The core node 14 may have hardware 72 that may include a communication interface 74 configured to set up and maintain a wired and / or wireless connection 62 with one or more core nodes 14, management nodes 15, and / or with a network node 16 serving a coverage area 18.

[0083] The hardware 72 of the core node 14 further includes processing circuitry 76. The processing circuitry 76 may include a processor 78 and memory 80. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 76 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs and / or ASICs adapted to execute instructions. The processor 78 may be configured to access (e.g., write to and / or read from) memory 80, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM and / or ROM and / or optical memory and / or EPROM.

[0084] Thus, the core node 14 may further comprise software 82, which is stored in, for example, memory 80 at the core node 14, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the core node 14. The software 82 may be executable by the processing circuitry 76.

[0085] The processing circuitry 76 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by core node 14. The processor 78 corresponds to one or more processors 78 for performing core node 14 functions described herein. The core node 14 includes memory 80 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 82 may include instructions that, when executed by the processor 78 and / or processing circuitry 76, causes the processor 78 and / or processing circuitry 76 to perform the processes described herein with respect to core node 14. In some embodiments, a management node 15 may be implemented in and / or identical to a core node 14. In some embodiments, the intent validity unit 24 may be implemented in the processing circuitry 76, processor 78, memory 80, and / or software 82 of the core node 14.

[0086] In some embodiments, the inner workings of the core node 14, management node 15, network node 16, and WD 22 may be as shown in FIG. 2 and independently, the surrounding network topology may be that of FIG. 1.

[0087] The wireless connection 32 between the WD 22 and the network node 16 is in accordance with the teachings of the embodiments described throughout this disclosure. More precisely, the teachings of some of these embodiments may improve the data rate, latency, and / or power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime, etc. In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve.

[0088] Although FIGS. 1 and 2 show various “units” such as intent validity unit 24 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry. Further, these units may be implemented in a single node and / or in separate nodes (e.g., virtual nodes, physical nodes, etc.).

[0089] FIG. 3 is a flowchart of an example process in a management node 15, referred to in some embodiments as an intent management node 15, for supporting intent violation reasoning in a system, such as a cloud system. One or more blocks described herein may be performed by one or more elements of intent management node 15 such as by one or more of processing circuitry 64 (including the intent validity unit 24), processor 66, and / or communication interface 60. Intent management node 15 is configured to generate (Block S100) a formal model based on the system, determine (Block S102) a service graph based on the intent and validate (Block S104) the compliance of the intent in the system based on the formal model and the service graph.

[0090] In some embodiments, the system comprises a plurality of components, a plurality of dependencies of the components, and a plurality of properties of the components, and the processing circuitry 64 is further configured to generate the formal model based on the plurality of components, the plurality of dependencies of the components, and the plurality of properties of the components. In some embodiments, the intent comprises a plurality of functional requirements and a plurality of non-functional requirements, and the processing circuitry 64 is further configured to validate the compliance of the intent in the system by: validating the plurality of functional requirements; and validating the plurality of non-functional requirements.

[0091] In some embodiments, the processing circuitry 64 is further configured to generate at least one validation result based on the validating of the compliance of the intent in the system. In some embodiments, the processing circuitry 64 is further configured to generate an intent conformance report based on the at least one validation result. In some embodiments, the processing circuitry 64 is further configured to cause deployment of the intent in the system based on the at least one validation result. In some embodiments, the processing circuitry 64 is further configured to update the formal model based on the deployment of the intent in the system. In some embodiments, validating the compliance of the intent in the system based on the formal model and the service graph is performed prior to the deployment of the intent in the system.

[0092] In some embodiments, the processing circuitry 64 is further configured to modify at least one of the intent and the service graph based on the at least one validation result. In some embodiments, the service graph corresponds to interactions and / or interdependencies between a plurality of services, and the processing circuitry is further configured to modify at least one interaction and / or interdependency based on the at least one validation result.

[0093] In some embodiments, the processing circuitry 64 is further configured to generate the formal model by receiving a system description associated with the system, the system description comprising at least one of: at least one configuration file associated with the system; at least one log trace associated with the system; metrics data associated with the system; and system events data associated with the system.

[0094] In some embodiments, the processing circuitry 64 is further configured to validate the formal model prior to validating the compliance of the intent in the system and tune at least one parameter of the formal model based on at least one of result of validating the formal model. In some embodiments, the formal model corresponds to a communication sequential process (CSP) model.

[0095] In some embodiments, the processing circuitry 64 is further configured to determine a linear temporal logic (LTL) description of the service graph, and validating the compliance of the intent in the system is further based on the LTL description.

[0096] As used herein, “network infrastructure” may refer to one or more physical and / or virtual nodes, devices, servers, cloud nodes, etc., such as WDs 22, network nodes 16, core nodes 14, management nodes 15, etc.

[0097] Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for supporting intent conformance in a system, such as a cloud system.

[0098] FIG. 4 is a flowchart illustrating an example embodiment of the present disclosure. In Step SI 10, inputs are provided / received / determined / etc. (e.g., by intent management node 15 and / or other nodes or entities in the system), such as the intent along with its the intent’s translation into a service graph, and an associated requirements specification. A system description may also be provided / received / determined / etc., which may include, e.g., configuration files, logs traces, metrics data, system events, etc. An intent validity unit 24, which may provide intent conformer functionality in an intent management node 15, receives these inputs in Step SI 12.

[0099] Thus, some embodiments provide a functionality for predicting and determining, at an early stage, such as prior to deployment, the validity of the requested configuration of a given input intent in a given system, e.g., before the actual deployment of the intent.

[0100] After checking intent conformance, in Step S 114, the intent validity unit 24 generates outputs such as validity information and / or an Intent Conformance Report indicating the validity of the request (i.e., valid / not valid), along with traces that can may later aid the intent management node 15 or other management node(s) 15, core nodes 14, etc., in identifying changes (if needed) to the input intent and / or the system.

[0101] Traces and / or metrics may relate to a previous execution, e.g., in order to build a formal model which closely resembles a real-world system, historical data may be used. For instance, if component A is observed to be frequently communicating with component B, then it may be inferred that these two components are connected, and this information may be used as an alternative to or as a complement to a system description.

[0102] FIG. 5 is a flowchart illustrating another example implementation according to some embodiments.

[0103] Step S120: Given the cloud system description, an intent management node 15, including intent validity unit 24, may be configured for building or generating a formal model for the corresponding system that describes the logical connections between its blocks.

[0104] Step S 122: The intent management node 15, including intent validity unit 24, applies the given intent to the formal model (e.g., formal cloud model, where the system is a cloud system) to verify its usefulness and efficiency. In some embodiments, the formal model may enable testing validity / conformance without requiring running or simulating an actual cloud network, for example, by making assumptions about how system components / entities / nodes / etc. may behave, and representing such assumptions as mathematical equations in a formal model.

[0105] Step S 124: After applying the input intent to the formal cloud model, the intent management node 15, including intent validity unit 24, may track / update / apply the corresponding changes to the formal model. The deployment of the intent on the formal model may be reflected, e.g., in the variables of the model that track the changes in the formal model (e.g., CPU utilization, sizes of queues, etc.). For example, if the number of users changes as a result of applying the intent, the formal model may need to change. It is also noted that FIG. 5 shows a link between Step S120 and Step S124. In this situation, this path is used if there are changes in the system description. Whenever there is a change in the system description, intent management node 15 updates the formal model.

[0106] Step S 126: The intent management node 15, including intent validity unit 24, checks whether the updated formal cloud model meets the input intent requirement specifications of the intent. The input requirements may include, e.g., performance requirements (e.g., throughput, latency), security requirements (e.g., high-level security), etc. These requirements may be monitored (e.g., by intent management node 15 and / or other nodes or entities in the system) through variables or other metrics to track changes in the system. For example, in some embodiments, a Process Analysis Toolkit (PAT) model checker may be used to verify the properties of the formal model, e.g., to perform a formal quantitative analysis of the cloud system. For example, if a handover success rate of >95% is part of the intent, then the PAT may check the formal model against that requirement. For example, PAT may accept a Communication Sequential Processes (CSP) language description of the formal model. An example CSP formal model is as follows:

[0107] Cloud_Cluster() = MasterNode_activate() || SlaveNodes_activate() ||

[0108] (|| i:{0..(N)}@DataNode_activate(i)) ||

[0109] (|| i:{O..(N)}@TaskTracker_activate(i)); where

[0110] MasterNode_activate(): initiates the cloud parameters with their default values and activates the master node process

[0111] SlaveNodes_activate(): activates N slave nodes in the cloud cluster

[0112] DataNode_activate(): activate the processes to manage the data at the slave nodes TaskTracker_activate(): activates the tracking process to evaluate the executed tasks / services on a given slave node

[0113] || implies parallel execution of processes

[0114] Step S128: The requirements are checked by intent management node 15, including intent validity unit 24, according to the updated version of the formal model.

[0115] Step S 130: If the requirements are met, the intent management node 15, including intent validity unit 24, generates validity information and / or an Intent Conformance Report indicating that the given intent and its specifications are valid. The intent management node 15, including intent validity unit 24, may send a request to deploy the intent services, e.g., to another management node 15, to core node(s) 14, to one or more network nodes 16, etc.

[0116] Step S132: After deploying the intent services on the system, the intent management node 15, including intent validity unit 24, obtains / determines / receives / etc. system feedback indicating changes in the system. According to this feedback, the management node 15, including intent validity unit 24, updates the formal cloud model. This update may include, e.g., updating CPU usage, IO latency, etc. Once updated, the formal model may be used by intent management node 15, including intent validity unit 24, to check conformance of additional / future intents.

[0117] Step S134: If the requirements specifications are not met, the intent management node 15, including intent validity unit 24, may generate invalidity information and / an Intent Conformance Report indicating that the given intent along with its specifications is not valid and its corresponding traces. These traces may be analyzed, e.g., using inductive reasoning, to identify possible causes that led to the failure of the intent requirements satisfaction. This analysis may include, e.g., extracting data about possible relations between intent specifications and the resulting specifications on the cloud system (e.g., KPIs, other metrics, etc.). For example, given a process A, which is working properly, a process B, which is working properly, and a process C, which is not working properly, the inductive reasoning may be utilized to determine where / how / why / etc. process C faulted. For instance, it may be determined that process C was not able to execute a task for an expected minimum number of users given an allocated set of resources, when receiving X requests per second, because the latency was too high. It may be determined that there is a need to therefore either increase the latency requirement of the intent, or increase the number of allocated resources, or both.

[0118] In some embodiments, inductive reasoning algorithms may be used by intent management node 15, including intent validity unit 24, to generate generalizations from specific observations. For example, the generated / observed / measured data for a given system (e.g., cloud system) may be used to draw conclusions. New inference rules may be built by going from the specific to the general, i.e., many observations may be used to produce generalizations and / or a pattern according to an explanation or a theory.

[0119] In some embodiments, inductive learning may enable the intent management node 15, including intent validity unit 24, to recognize patterns and regularities in previous knowledge or training data, and to extract general rules from them. The identified and extracted generalized rules may be used in reasoning and problem-solving.

[0120] In some embodiments, various tools and / or algorithms may be used in this step, such as a RULES (Simple Rule Extraction System) algorithm for extracting IF-THEN rules from a set of training examples. Algorithms under the RULES family are typically available in data mining tools, such as KEEL and WEKA, used for knowledge extraction and decision making. For instance, if the intent management node 15, including intent validity unit 24, observes a resource error frequently, then it may infer a need to increase an allocated resource amount; if it frequently observes problems in a virtual machine (VM), then it may infer a need to change the VM. Thus, it may be possible to extract knowledge from traces, metrics, KPIs, etc., for determining potential solutions to faults or failures in the system.

[0121] Step S136: After analyzing the traces or other metrics, the intent management node 15, including intent validity unit 24, may determine adjustments and / or changes to the input intent specifications (e.g., a resource demand needs to be decreased, additional capabilities need to be removed from the requirements, budget requirements need to be revised, etc.), and / or the intent management node 15, including intent validity unit 24, determines a need for changes to the system / infrastructure (e.g., include hardware accelerators at specific locations, etc.).

[0122] Step S138: The intent management node 15, including intent validity unit 24, sends change information to the corresponding entities, e.g., other management node 15, core nodes 14, network nodes 16, etc. For example, the intent management node 15 may inform a user who requested the intent that it is impossible to execute this intent in the system, and / or it may revise the intent (e.g., changes to the requirements, the amount of resources allocated to each service, etc.).

[0123] FIG. 6 is a flowchart illustrating an example process in an intent management node 15, including intent validity unit 24, for building a formal mode of a system, e.g., a cloud system, according to some embodiments of the present disclosure. These steps may correspond to detailed sub-steps of Step S120, for example, of FIG. 5.

[0124] In other words, These processes may be used to build a formal model which represents the behavior of the cloud system when running it on an underlying infrastructure.

[0125] A goal of this process is the construction of a formal model for the cloud system and its properties. To this aim, in some embodiments, the intent management node 15 may use a Communication Sequential Processes (CSP) language, described above, to formally model the cloud system, which may enable the modeling of synchronous and concurrent systems. Other languages or formal model tools may be used other than CSP without deviating from the scope of the present disclosure. This may enable modeling the behavior and communication of multiple processes and parallel components for different distributed and / or cloud-based systems, for example.

[0126] In some embodiments, the intent management node 15 may use a Linear Temporal Logic (LTL) or similar tool / language to provide a description of the properties which it aims to verify. In this context, the properties to verify may correspond to the requirements defined in an intent when deploying its services in the cloud system, for example. An example LTL is as follows:

[0127] #define goalO number_of_requests / second_per_service == 100;

[0128] #assert cluster reaches goalO;

[0129] #assert cluster reaches goalO && hand_over_success_rate >80;

[0130] #define goall end_to_end_latency ==10;

[0131] #assert cluster reaches goalO && goall; The intent management node 15 may construct a formal model to formally describe the components of the (cloud) system, e.g., including the dependencies between the components, updates of the system, and the requirements’ updates when an intent is deployed, as described in the following steps.

[0132] Step S150: Intent management node 15, including intent validity unit 24, analyzes input data (configuration files, log traces, metrics data, system events, etc.) and obtains / determines a system description of the cloud-based system.

[0133] Step S152: Intent management node 15, including intent validity unit 24, obtains / determines a list of various different blocks composing the cloud system, with respect to the input given from the user / intent and the system description. This may include, for example, the nodes, VMs, etc., which make up the system.

[0134] The following steps (Step S154, S156, S158) may be performed in parallel.

[0135] Step S154: Intent management node 15, including intent validity unit 24, obtains / determines a high-level description of the connections between the identified components in Step S152, and represents them as communication processes, for example. Intent management node 15, including intent validity unit 24, may build the relationships between the nodes and describe the relationships, for example, in terms of bandwidth, latency, etc.

[0136] Step S156: Intent management node 15, including intent validity unit 24, retrieves / obtains / determines possible dependencies between the identified cloud components and their corresponding communication processes, e.g., for tracking the possible changes in the formal model of the cloud after deploying an input intent (i.e., a service graph representation of an intent). This may include a variety of metrics, descriptions, variables, nodes, connections, etc. which describe the cloud system.

[0137] Step S158: Intent management node 15, including intent validity unit 24, tracks the changes in the requirements of the cloud system and the formal model accordingly, with respect to the changes in the deployed intent.

[0138] Step S160: Intent management node 15, including intent validity unit 24, combines the output of the previous steps (processes, components, requirements, etc.) to build a formal model of the cloud system and its specifications.

[0139] Step S162: Intent management node 15, including intent validity unit 24, checks the validity of the formal model. This may be a different type of validity compared to the validity checked in Steps S126 and S128 described in FIG. 5. For example, in some embodiments, the validity of the formal model may be checked in Step SI 62 independent of the intent.

[0140] Step S164: Intent management node 15, including intent validity unit 24, tunes the parameters of the formal model accordingly, based on the checking of the validity in Step S162.

[0141] FIG. 7 illustrates an example implementation according to some embodiments of the present disclosure. In this example, in Step S220, an intent is defined as “I want to have a holographic communication with high interaction, and latency less than 10ms, through a mobile 5G network.” In this case, the intent may include at least three elements: (1) holographic communication with high interaction; (2) latency less than 10ms; and (3) through a 5G mobile network.

[0142] A service graph may be determined / configured based on this intent. These services may be implemented in one or more network nodes 16, WDs 22, core nodes 14, management nodes 15, etc. Latency information, for example, may be measured for each service. A holo-generator service (Step S222 in the service graph) is determined to have a latency of 3ms. A holo-encoder service (Step S224) is determined to have a latency of 2ms. A holo-decoder service (Step S226) is determined to have a latency of 3ms . A holodisplay service (Step S228) is determined to have a latency of 2ms. A raw-holo-write service (Step S230) is determined to have a latency of 3ms. A storage service (Step S232) is determined to have a latency of 4ms. In some embodiments, the latency values or other metrics may be determined by intent management node 15, including intent validity unit 24, using a formal model, as described herein. Thus, an intent violation may be detected by intent management node 15, including intent validity unit 24, where the total latency sums to at least 10ms.

[0143] FIG. 8 illustrates another example implementation according to some embodiments of the present disclosure. FIG. 8 shows 5G Core (5GC) network architecture in which the main Network Functions (NFs) implemented for example in one or more management nodes 15 in the 5GC are associated to the packet core and user data management domain.

[0144] This 5GC architecture is based on what is called a Service-Based Architecture (SBA), which implements information technology network principles and a cloud-native design approach. In this new architecture, each network function (NF) offers one or more services to other NFs via Application Programming Interfaces (API). Each NF is formed by a combination of small pieces of software code, referred to as microservices. Some microservices can be re-used for different NFs, making implementation more effective and facilitating independent life-cycle management - which allows upgrades and new functionalities to be deployed with zero impact on running services.

[0145] The abbreviations used in FIG. 8 relate to 5G networking and are defined as follows:

[0146] Abbreviation _ Definition

[0147] 5G-EIR 5G Equipment Identity Register

[0148] AF Application Function

[0149] AMF Access and Mobility Function

[0150] AUSF Authentication Service Function

[0151] CHF Charging Function

[0152] GMEC Gateway Mobile Location Center

[0153] LMF Location Management Function

[0154] DN Data Network

[0155] NEF Network Exposure Function

[0156] NRF Network Repository Function

[0157] NSSF Network Slice Selection Function

[0158] NWDAF Network Data Analytics Function

[0159] PCF Policy Control Function

[0160] (R)AN (Radio) Access Network

[0161] SMF Session Management Function

[0162] UDM Unified Data Management

[0163] UDR User Data Repository

[0164] UE User Equipment

[0165] UPF User Plane Function

[0166] In this example, in Step S240, an intent is defined as “I need a 5G core to support 5,000 subscribers with a high QoE and latency less than 10ms, with a handover success rate greater than 95%. ” In this case, the intent may include: (1) a 5G core network; (2) support for 5,000 subscribers; (3) a high QoE; (4) a latency less than 10ms; and (5) a handover success rate greater than 95%.

[0167] In Step S242, a service graph may be determined / configured based on this intent. These services may be implemented in one or more network nodes 16, WDs 22, core nodes 14, management nodes 15, etc. Here, the total latency for the service graph may be monitored, e.g., by intent management node 15, which determines, in Step S244, a latency of 2ms and handover success rate of 70% for the 5G core with 5,000 users. In some embodiments, the latency values, handover success rate, or other metrics may be determined by intent management node 15, including intent validity unit 24, using a formal model, as described herein. Thus, an intent violation is detected in this example.

[0168] As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and / or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and / or functionality described herein may be performed by, and / or associated to, a corresponding module, which may be implemented in software and / or firmware and / or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

[0169] Some embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0170] These computer program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0171] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0172] It is to be understood that the functions / acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0173] Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0174] Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and / or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

[0175] Abbreviations that may be used in the preceding description include:

[0176] CSP Communication Sequential Processes

[0177] ENI Experiential Networked Intelligence

[0178] LTL Linear Temporal Logic

[0179] PAT Process Analysis Toolkit

[0180] QoE Quality of Experience

[0181] QoS Quality of Service

[0182] SLA Service Level Agreement

[0183] It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings.

Claims

What is claimed is:

1. A method implemented in an intent management node (15) for validating a compliance of an intent in a system, the method comprising: generating (S100) a formal model based on the system; determining (S102) a service graph based on the intent; and validating (S104) the compliance of the intent in the system based on the formal model and the service graph.

2. The method of Claim 1, wherein the system comprises a plurality of components, a plurality of dependencies of the components, and a plurality of properties of the components; and the method further comprises generating the formal model based on the plurality of components, the plurality of dependencies of the components, and the plurality of properties of the components.

3. The method of any one of Claims 1 and 2, wherein the intent comprises a plurality of functional requirements and a plurality of non-functional requirements; and the method further comprises validating the compliance of the intent in the system by: validating the plurality of functional requirements; and validating the plurality of non-functional requirements.

4. The method of any one of Claims 1-3, wherein the method further comprises generating at least one validation result based on the validating of the compliance of the intent in the system.

5. The method of Claim 4, wherein the method further comprises generating an intent conformance report based on the at least one validation result.

6. The method of any one of Claims 4 and 5, wherein the method further comprises causing deployment of the intent in the system based on the at least one validation result.

7. The method of Claim 6, wherein the method further comprises updating the formal model based on the deployment of the intent in the system.

8. The method of any one of Claims 6 and 7, wherein validating the compliance of the intent in the system based on the formal model and the service graph is performed prior to the deployment of the intent in the system.

9. The method of any one of Claims 4-8, wherein the method further comprises modifying at least one of the intent and the service graph based on the at least one validation result.

10. The method of any one of Claims 4-9, wherein the service graph corresponds to interactions and / or interdependencies between a plurality of services; and the method further comprising modifying at least one interaction and / or interdependency based on the at least one validation result.

11. The method of any one of Claims 1-10, wherein the method further comprises generating the formal model by: receiving a system description associated with the system, the system description comprising at least one of: at least one configuration file associated with the system; at least one log trace associated with the system; metrics data associated with the system; and system events data associated with the system.

12. The method of any one of Claims 1-11, wherein the method further comprises: validating the formal model prior to validating the compliance of the intent in the system; and tuning at least one parameter of the formal model based on at least one of result of validating the formal model.

13. The method of any one of Claims 1-12, wherein the formal model corresponds to a communication sequential process (CSP) model.

14. The method of any one of Claims 1-13, wherein the method further comprises: determining a linear temporal logic (LTL) description of the service graph; and validating the compliance of the intent in the system is further based on the LTL description.

15. An intent management node (15) for validating a compliance of an intent in a system, the intent management node comprising processing circuitry (64) configured to: generate a formal model based on the system; determine a service graph based on the intent; and validate the compliance of the intent in the system based on the formal model and the service graph.

16. The intent management node (15) of Claim 15, wherein the system comprises a plurality of components, a plurality of dependencies of the components, and a plurality of properties of the components; and the processing circuitry (64) is further configured to generate the formal model based on the plurality of components, the plurality of dependencies of the components, and the plurality of properties of the components.

17. The intent management node (15) of any one of Claims 15 and 16, wherein the intent comprises a plurality of functional requirements and a plurality of nonfunctional requirements; and the processing circuitry (64) is further configured to validate the compliance of the intent in the system by: validating the plurality of functional requirements; and validating the plurality of non-functional requirements.

18. The intent management node (15) of any one of Claims 15-17, wherein the processing circuitry (64) is further configured to generate at least one validation result based on the validating of the compliance of the intent in the system.

19. The intent management node (15) of Claim 18, wherein the processing circuitry (64) is further configured to generate an intent conformance report based on the at least one validation result.

20. The intent management node (15) of any one of Claims 18 and 19, wherein the processing circuitry (64) is further configured to cause deployment of the intent in the system based on the at least one validation result.

21. The intent management node (15) of Claim 20, wherein the processing circuitry (64) is further configured to update the formal model based on the deployment of the intent in the system.

22. The intent management node (15) of any one of Claims 20 and 21, wherein validating the compliance of the intent in the system based on the formal model and the service graph is performed prior to the deployment of the intent in the system.

23. The intent management node (15) of any one of Claims 18-22, wherein the processing circuitry (64) is further configured to modify at least one of the intent and the service graph based on the at least one validation result.

24. The intent management node (15) of any one of Claims 18-23, wherein the service graph corresponds to a plurality of system resources; and the processing circuitry (64) being further configured to modify at least one system resource of the plurality of system resources based on the at least one validation result.

25. The intent management node (15) of any one of Claims 15-24, wherein the processing circuitry (64) is further configured to generate the formal model by: receiving a system description associated with the system, the system description comprising at least one of: at least one configuration file associated with the system; at least one log trace associated with the system; metrics data associated with the system; and system events data associated with the system.

26. The intent management node (15) of any one of Claims 15-25, wherein the processing circuitry (64) is further configured to: validate the formal model prior to validating the compliance of the intent in the system; and tune at least one parameter of the formal model based on at least one of result of validating the formal model.

27. The intent management node (15) of any one of Claims 15-26, wherein the formal model corresponds to a communication sequential process (CSP) model.

28. The intent management node (15) of any one of Claims 15-27, wherein the processing circuitry (64) is further configured to: determine a linear temporal logic (LTL) description of the service graph; and validating the compliance of the intent in the system being is based on the LTL description.

Images