Assisted intent manager selection and intent translation

Abstract

Methods for selecting an intent handler in a network. An example method performed by a first intent manager, acting as an intent owner, is for selecting, from among multiple intent managers in a network, an intent handler for handling the intent. The method comprises querying (1310) an intent manager registry to determine a plurality of intent manager candidates for acting as intent handler, based on management scope criteria for the intent. The method further comprises genera ng (1320) a plurality of intent objects for the intent manager candidates, based on input requirements, goals, and constraints for the intent, and ranking (1330) the intent manager candidates, based on the input requirements, goals and constraints for the intent, the generated intent objects, and one or more predetermined criteria. The method s ll further comprises selecting (1340) an intent manager candidate to act as intent handler for the intent, based on the ranking.

Description

[0001] ASSISTED INTENT MANAGER SELECTION AND INTENT TRANSLATION

[0002] TECHNICAL FIELD

[0003] This disclosure is generally related to autonomous networks and is more particularly related to the handling of intents in such networks.

[0004] BACKGROUND

[0005] Future data and communication network operations will require greater network autonomy, meaning that business, service, and resource operations will be able to make decisions and take the right actions for configuring, monitoring, and maintaining network components and functions based on goals and requirements set by service consumers or other autonomous systems. Decision-making processes in autonomous networks should ideally take place without any human intervention. In this scenario, business goals and user expectations are communicated to the parts (e.g., management domains, systems) that make up the autonomous network through "intents," where the term "intent" refers generally to an expression of the requirements that an autonomous system must meet.

[0006] Intent-Driven Management is a new paradigm in network and service management, where the main goal is to move network operations from manual or automated operation to fully autonomous. Every autonomous system needs to make decisions; therefore, it is essential that autonomous systems know their requirements, goals, and constraints. Intents are the knowledge that enables autonomous systems to make intelligent decisions. Intents express "what" should be achieved and do not prescribe "how" it should be done. The final decisions are made by the autonomous system, based on the intents. The intents should thus be used by the receiving system (autonomous system) to understand what is expected to be achieved, including utility models, preferred outcomes, etc.

[0007] Intents are defined as "the formal specification of all expectations including requirements, goals, and constraints given to a technical system." ("Intent in Autonomous Networks," Doc. # IG1253, v1.3.0, TM Forum.) This definition is commonly used throughout several different standardization groups, including the TM Forum, 3GPP SA5, and ETSI ZSM. One important aspect of this definition of intents is that it refers to a formal specification, which means that intents should be expressed with formally defined and complete semantics and vocabulary. This is achieved with the definition of formal models that cover the required expressiveness. Another important aspect is that intents are primarily intended for technical systems, or in other words, for machines. Therefore, there should be standardized interfaces that allow machines to exchange, negotiate and life cycle manage the intents. There are different possibilities for modeling intents and how they are formally expressed. Since intents need to be used in multi-vendor and multi-domain environments, a common modeling and language is required for interoperability. TM Forum's Autonomous Networks project has worked on a set of guidelines and specifications that provide details on the use of intent in autonomous networks and the formal intent modeling.

[0008] In a management system composed of sub-systems, intents are knowledge used for the communication of requirements, goals, and constraints between a pair of entities, referred to as intent managers or intent management functions. Because intents are knowledge objects, the life cycle of intents can be managed, i.e., new intents can be created, existing intents may be changed, intents can be removed from (sub)systems, etc. Each intent manager may play a distinct role in the life cycle of the intents, either as an intent owner, the origin of the intent, who has certain requirements, goals, and constraints for network operation, or as the intent handler, the receiver of the intent, who must fulfil these requirements, goals, and constraints. Intent managers exchange intents (as formal definitions of the requirements, goals and constraints) and intent reports (as formal feedback on the intent fulfilment).

[0009] An intent object instance should be uniquely identified within the management (sub)system. In practical scenarios with multiple layers of management and autonomous domains, multiple intent managers are needed, and they may play the roles of owner and / or handler for different intent objects. An intent object instance, however, is owned by one single intent owner, and it must be sent to one single intent handler for its fulfilment.

[0010] An intent manager registry is a logical entity that stores intent manager capability profiles of registered intent managers. This registry allows intent managers to discover one another and query their supported management scopes, interface procedures, and expressiveness, i.e., to determine the intent models supported and partially supported by a given intent manager. As discussed above, an intent model is an expression of requirements, goals, and constrains for a technical system, expressed with formally defined semantics and vocabulary. The semantics and vocabulary may be defined by standards, and / or may utilize proprietary definitions.

[0011] During the task of intent investigation, the intent owner must find the right intent handler for the specific intent object instance. This is done using the intent manager registry capabilities, as shown in Figure 1. Intent managers 110 register their capabilities for handling intents with the intent manager registry 120. This is done using intent manager capability profiles 125, which may also be referred to as simply intent manager profiles. Intent managers 110 "discover" the capabilities of other intent managers 110 from the intent manager registry 120 by submitting queries that may, for example, indicate a required management scope for an intent owned by the querying intent manager 110, and receiving an intent manager profile 125 for an intent handler in return. Figure 2 illustrates a model for expressing the classes and properties of an intent manager profile 125, based on the Resource Description Framework (RDF).

[0012] Figure 3 shows three phases required for intent-based management. Phase 1, i.e., intent manager profiles registration, involves registering the intent manager profiles of all intent managers, so that their capabilities can be later discovered by interested intent managers. This is shown in Figure 3 as an interaction between intent manager 110-A, which is acting as an intent handler, and intent manager registry 120.

[0013] Phase 2, i.e., intent manager profiles discovery, involves the discovery of the intent handler's profile before an intent is created and sent by an intent owner. This is shown in Figure 3 as an interaction between intent manager HOB, which is acting as an intent owner, and intent manager registry 120. This phase involves a simple query using filtering criteria such as management scope, or specific domain, e.g., all intent managers from a certain vendor, etc.

[0014] Phase 3, i.e., intent life cycle management, includes the various operations for managing intents as information objects. Examples of lifecycle management operations are intent creation, modification, deletion, query, or optional operations to negotiate the best intent to use. Phase 3 is performed after the intent owner selects an intent handler and provides it with an intent object to be used.

[0015] The initial parts of the intent-based management processes may be viewed as an "investigation phase." During this phase, the requirements, goals, and constraints for a given intent are determined, and an intent handler for fulfilling the intent is identified. The techniques described herein focus on improvements to this phase of intent management in autonomous networks.

[0016] SUMMARY

[0017] The techniques described herein comprise methods to select the best intent manager and to create the best corresponding intent object for an intent-based communication between an intent owner and an intent handler. As detailed below, these methods may be employed to list all candidate intent managers that are intent managers having the right management scope for a given intent object or for a given list of requirements. Based on the list and the candidate intent manager's capabilities expressed in their intent manager profiles, the candidates are ranked, according to some predetermined criterion. Optionally, there can be an ontology mapping that allows the consideration of intent managers that do not support all intent model extension, but have advanced capabilities, such as optional interface procedures for the management of the intent life cycle. The ranking can consider different criteria and can weight possible ontology mapping that needed to be undertaken, advanced capabilities of the intent manager, and other features that may weigh for or against the selection of a given intent manager.

[0018] An example method, according to some embodiments, is performed by a first intent manager, acting as an intent owner, and is for selecting, from among a plurality of intent managers in a network, an intent handler for handling the intent. This method comprises querying an intent manager registry to determine a plurality of intent manager candidates for acting as intent handler, based on one or more management scope criteria for the intent. The method further comprises generating a plurality of intent objects for the intent manager candidates, based on the input requirements, goals, and constraints for the intent, and ranking the intent manager candidates, based on the input requirements, goals and constraints for the intent, the generated intent objects, and one or more predetermined criteria. The method still further comprises selecting an intent manager candidate to act as intent handler for the intent, based on the ranking.

[0019] Examples of nodes configured to carry out the above method and the variations described herein are also described in detail below.

[0020] BRIEF DESCRIPTION OF THE FIGURES

[0021] Figure 1 illustrates intent manager registration and discovery.

[0022] Figure 2 is an example of Resource Description Framework (RDF) classes and properties for expressing intent manager profiles.

[0023] Figure 3 illustrates interactions between intent managers and intent manager registry.

[0024] Figure 4 illustrates building blocks of the techniques described herein.

[0025] Figure 5 is a signaling flow diagram illustrating an example technique according to some embodiments.

[0026] Figure 6 is a flow chart illustrating an example technique carried out by an intent owner, according to some embodiments.

[0027] Figure 7 illustrates an example intent object expressed as an RDF-based graph.

[0028] Figure 8 shows an example intent object corresponding to Figure 7 expressed in the textual format TURTLE. Figure 9 illustrates another example intent object expressed as an RDF-based graph.

[0029] Figure 10 shows an example intent object corresponding to Figure 9 expressed in the textual format TURTLE.

[0030] Figure 11 illustrates another example intent object expressed as an RDF-based graph.

[0031] Figure 12 shows an example intent object corresponding to Figure 11 expressed in the textual format TURTLE.

[0032] Figure 13 is a process flow diagram illustrating an example method, according to some embodiments.

[0033] Figure 14 is a block diagram of an example network node, according to some embodiments.

[0034] Figure 15 is an example virtualization environment in which some or more of the techniques described herein may be implemented.

[0035] DETAILED DESCRIPTION

[0036] Embodiments briefly summarized above will now be described more fully with reference to the accompanying drawings. These descriptions are provided by way of example to explain the subject matter to those skilled in the art and should not be construed as limiting the scope of the subject matter to only the embodiments described herein. More specifically, examples are provided below that illustrate the operation of various embodiments according to the advantages discussed above.

[0037] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods and / or procedures disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein can be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments can apply to any other embodiments, and vice versa. Other objects, features and advantages of the disclosed embodiments will be apparent from the following description. Some key concepts related to the techniques described herein are described first. These are based on the work done in TM Forum's Autonomous Networks but are also generic enough to be applied in any intent-based management system.

[0038] First is the concept of intent modeling. Intent models are based on ontologies that use the Resource Description Framework (RDF) / Resource Description Frame Schema (RDFS) suite. The ontologies are formed by a mandatory intent common model and optional intent extension models. These extension models may be specific to a particular domain of intent handling, and thus may more directly address requirements, goals, and constraints applicable to that domain by adding optional additional vocabulary and semantics.

[0039] Another concept is intent models federation. Intent extension models can be created by different organizations and can be federated to create intents that express requirements coming from different management domains.

[0040] A concept discussed above is the concept of intent manager. Intents are knowledge objects that need to be managed through their life cycles. Intent managers are the logical entities involved in this life cycle-management. An intent manager can play the role of intent owner and / or intent handler. An intent owner is the intent manager that originates the intents, i.e., the requirements, goals, and constraints. An intent handler is the intent manager that fulfils the intents, i.e., that receives the intents from an intent owner and fulfils the requirements, goals, and constraints of the intents. Note that intent managers may also be referred to as intent management functions.

[0041] Another concept is the intent manager registry. The intent managers need to publish and query their capabilities to allow machine-driven automation. The registration and discovery of intent manager capabilities is achieved with the intent manager registries, which provide for the registration, storage, and retrieval of intent manager profiles. An intent manager profile is a list of capabilities of an intent manager, e.g., management scope, supported models, interfaces, notations, etc.

[0042] The investigation phase of the intent life-cycle management is very important for the intent fulfilment success. During the investigation phase, two important decisions must be made by the intent owner. First, the best composition of requirements, goals, and constraints for an intent must be performed. Second, the best intent handler must be identified for the intent fulfilment.

[0043] In principle, these two decisions can take place in any order. For instance, an intent owner may already have an intent object, either as a newly created specification of requirements, goals, and constraints, or as an intent derived from another intent specification received from another intent handler (e.g., sub-intents derived from higher-level intents). In this case, the intent owner has to find the best intent manager in the intent manager registry that supports the intent model(s) used in the intent specification and that supports the needed intent management scopes. Alternatively, an intent owner may have not yet decided on an intent object that will be used to best specify the wanted requirements, goals, and constraints. In this case, the intent owner may decide to first select, using the intent manager registry, intent manager candidates that support the target intent management scopes, and then decide on the best intent object to be created.

[0044] In both of these cases, there may be many different options to be considered by the intent owner, which means that making the best decision may not be easy, or may require a trial-and-error approach.

[0045] One example of a complex decision-making scenario is where an intent owner with a given intent object discovers that only one intent handler supports all the required intent models and management scopes for handling the intent object, but this intent handler only provides basic intent interface operations, which may require a long trial-and-error process until the best requirements are fulfilled. The intent owner in this scenario may also discover that a second intent handler does not support all the required models but supports the needed management scopes and optional intent interface operations. To use the second intent handler, the intent object would need to be mapped to standardized intent models that are supported, but the best requirements could be easily agreed with the use of optional intent interface operations Probe and Best.

[0046] In this scenario, the intent owner should consider what to prioritize. On one hand, the intent owner can use the intent handler that supports the models used by the intent object. On the other hand, other intent handlers could be considered if using more interface operations is something advantageous, even with possible intent mappings being required. Given these questions to consider, it can be seen that the best-informed decision making cannot be achieved by simply considering the information available in the intent manager profiles but requires some type of further analysis of available capabilities and some ranking methodology.

[0047] An intent owner should therefore be able to carry out an automated and informed decision-making process during the investigation phase of the intent life-cycle management. Such a method is not part of the standardization for autonomous networks, because it is implementation-specific. But this process may rely on the building blocks provided by intent standardization, mainly the intent manager registry and the intent manager profile information that is under standardization process. The techniques described herein may be employed to allow intent owners to find the best intent handler and the best intent objects to be employed in an intent-based interaction, i.e., when specifying requirements, goals and constraints between two (or more) autonomous domains, where an autonomous domain is a technical system, with a defined boundary, that can carry out tasks and adhere to goals and objectives without manual human intervention, using, for example, closed control loop mechanisms. These techniques are based on the management functions, the intent models, and intent interface operations standardized by TM Forum guidelines, but can in principle be extended to other standards as the concept of intent is incorporated into other management architectures, e.g., in Open-RAN (O-RAN) Service Management and Orchestration (SMO), ETSI Zero- Touch Network and Service Management (ZSM) management architecture, or 3GPP SA5 management services. Note that the terms "intent interface operations" and "interface operations" may be used interchangeably. Likewise, the terms "optional intent interface operations" and "optional interface operations," which refer to procedures not required by TM Forum standards but which provide more sophisticated interactions between intent managers, may be used interchangeably.

[0048] These techniques assume the involvement of three intent management functions, i.e., an intent owner, an intent handler and an intent manager registry, as illustrated in Figure 3. As noted above, Figure 3 shows three phases of intent-based management: intent manage profile registration, intent manager profile discovery, and intent life-cycle management.

[0049] Phase 1, i.e., intent manager profiles registration, involves registering the intent manager profiles of all intent managers, so that their capabilities can be later discovered by interested intent managers. This phase is necessary because in intent-based management, different intent managers exchange intents that must be created based on the supported intent extension models and communicated through an interface using the supported interface procedures. All intent managers must register their own intent manager profiles in a common (set of) intent manager registry(ies). The intent manager profile is an artifact that describes the capabilities of an intent manager. The list of capabilities expressed in the intent manager profiles is used by the intent owners who need to select the best intent handler to receive an intent.

[0050] Phase 2, i.e., intent manager profiles discovery, involves the discovery of the intent handler's profile before an intent is created and sent by an intent owner. This phase involves a simple query using filtering criteria such as management scope, any specific domain, e.g., all intent managers from a certain vendor, etc. Phase 3, i.e., intent life cycle management, includes the various operations for managing intents as information objects. Examples of lifecycle management operations are intent creation, modification, deletion, query, or optional operations to negotiate the best intent to use. Phase 3 is performed after the intent owner selects the best intent handler and creates the best intent object to be used. Phase 3 is what follows the use of the techniques described herein, so it is not the focus of this disclosure.

[0051] The techniques described herein are based on an assumption that an intent owner either has a fully specified intent object (input type 2) or a list of requirements, goals and constraints that need to be converted into an intent object (input type 1). The goal of the techniques is to identify the best intent handler to support the requirements, goals and constraints and the best intent object to be used.

[0052] Based on the intent manager profiles available at an intent manager registry, the method creates a list of intent manager candidates and the corresponding intent objects to be used with. The list is ranked according to some selected criterion and the best intent manager (together with the corresponding intent object) is considered for the intent-based interaction between an intent owner and an intent handler.

[0053] As part of the process of creating the list of candidate intent manager and the corresponding intent object, an optional step of ontology mapping is used to allow the consideration of intent managers that do not support all intent model extensions considered by an existing intent object. This ontology mapping together with optional capabilities, such as optional interface procedures, are considered in the ranking to allow a better decision making in the process of choosing the best intent manager to be selected by an intent owner.

[0054] Figure 4 shows an overview of the process, considering the main building blocks of the method. As mentioned, the intent owner can use 2 types of inputs: either a list of requirements (input type 1), goals and constraints, or a fully-fledged intent object that can follow any standardized or proprietary modelling (input type 2); we consider as an example the intent model specified by TM Forum.

[0055] Regardless of the input type, the management scope is extracted and used by the intent owner to query the intent manager registry to find all possible intent manager candidates that can work as an intent handler. For type 2 inputs, the management scope can be extracted directly from the intent models in the intent object. For type 1 inputs, the management scope must be derived from the requirements, e.g., by identifying the services and / or systems that the requirements involve. The management scope, for instance, can limit the query to only intent managers that deal with Radio Access Network (RAN) services, or that are from a specific vendor, etc. In the example of Figure 4, Intent Manager 1 queries the intent manager registry at step 1 and receives in response, at step 2, a list of candidates, e.g., Intent Manager 2, Intent Manager 3, Intent Manager 4, etc.

[0056] Based on the preliminary list of intent manager candidates (the ones that support the required management scope) and the input, the intent owner now must rank the intent managers. Before it can do this, for each of the intent manager candidates, the intent owner has to either create a feasible intent object to be used with the respective intent manager candidate (if the input is a list of requirements) or translate the input, if the input is an intent, into a feasible intent object to be used with the given intent manager candidate.

[0057] At the end of this process, the intent owner has a ranked list of intent handler candidates and the corresponding intent objects. With this list of ranked intent handler candidate, the intent owner can select the best one (based on different criteria) and start the next phases of the intent life cycle management with the selected intent manager. In the example of Figure 4, the selected intent manager is Intent Manager 4; the other intent managers are illustrated with an "X," to indicate that these were deleted from consideration, based on the rankings.

[0058] Figure 5 is a signal flow diagram illustrating main steps for the three involved entities in an example of these techniques.

[0059] As shown at step 1, an intent owner queries the intent manager registry for all intent managers that support a given management scope. Management scope is the delineation of responsibility for operational tasks within a system domain or sub-system. By association with a defined scope, an intent manager claims that it is the responsible entity for intent targeting this scope.

[0060] Examples of intent management scopes are:

[0061] • at the business layer - contract negotiation scope, order management scope, regulatory policies scope, operator policies scope.

[0062] • at the service layer - service orchestration and assurance scope.

[0063] • at the resource operation layer - core network intent management scope, transport management scope, slice management scope, network function management scope.

[0064] As shown at step 2 in Figure 5, the intent manager registry sends, in response to the querying from the intent owner, the intent manager profiles for all intent managers that support the specified management scope. All these intent managers are considered as intent handler candidates in the selection process. At step 3, the intent owner either creates an intent object, if it has a list of requirements, goals and constraints (input type 1), or maps an existing intent object (input type 2) into the intent models supported by the intent manager, according to its intent manager profile.

[0065] The first case (creation of a new intent object) is the most common case, and it happens whenever a set of new requirements (or changes on existing requirements) is used. An example is a network slice template coming from operator or vertical for a new slice creation. The second case (mapping an existing intent into another) is a less common case, and it happens when intents are derived from other intents prior to the use of the proposed method, or whenever existing systems use the proposed method and there are already intents being used.

[0066] Further below, more details are provided regarding possible methods to be used in the case where Step 3 requires an intent mapping. At the end, the intent mapping will be the result of an ontology alignment (or ontology matching) between the ontology (set of intent extension models plus the intent common model) used by the intent to be translated and the ontology supported by the intent handler candidate. Ontology matching is a well-known and studied problem that has been investigated for the integration of systems and databases, especially in the Semantic Web.

[0067] Therefore, the core of the techniques described herein is not the ontology matching method; rather, it is the use of existing tools and algorithms to solve this problem. Furthermore, since the intent models considered, such as TM Forum's, are already expressed with the same language and using a common intent model, the matching become less complex and results are more measurable (in general, assessing the accuracy of an ontology matching methods require consensus on the evaluation methodology, such as the Ontology Alignment Evaluation Initiative - http: / / oaei.ontologymatching.org / ).

[0068] Referring back to Figure 5, at step 4 the intent object can be further improved, optionally, with invocation of optional interface operations supported by the intent manager (as specified in TMF921A and IG1253C). These operations allow a better negotiation of parameters of the intent objects, targeting mainly the best key performance indicators (KPIs) to be considered in the expectations. This is an optional step because not all intent managers are expected to support this.

[0069] Step 5 comprises creating a list with intent managers and corresponding intent object to be used. This list has all intent manager candidates provided by the intent manager registry and, for each intent manager candidate, the best intent object that can be used with that intent manager. The intent objects may have been produced from the input requirements or by mapping a previously existing intent. At step 6, the list created is ranked, based on some selected criterion. Since the intent handler candidates may have different capabilities and the intent objects associated may have suffered modifications by mapping the original intents, different criteria can be used to weight each of these characteristics differently.

[0070] One example of a formula to be used for ranking the list is shown below:

[0071] Rank = Wjf# of supported interface operations')

[0072] — Wj(# of expectation mapped or deleted)

[0073] In the formula above, the rank is increased with more interface operations being supported by the intent handler candidate and decreased by each mapping that the intent object was subject to. This provides a higher rank for intent handler candidates with more (optional) interface capabilities and with less (or none) changes in the intent object.

[0074] As shown at step 7 in Figure 5, with the selected intent handler and the creation of the intent object, the intent life cycle management operations can be performed. These operations can be performed using standardized APIs such as TMF921A, or other intent-based APIs from other standards groups, e.g., 3GPP.

[0075] Figure 6 shows the steps performed from the perspective of the intent owner, which is the node that executes the method to select the best pair of intent handler and intent object. This diagram reproduces, with more details, the same steps from Figure 5 and is provided for better illustration of the method.

[0076] Step 3 of Figure 5 and step 5 of Figure 6 may involve the modification of an existing intent that requires intent extension models that are not supported by the intent handler candidate to translate that intent into another that is supported. Since intents are created based on well-defined ontologies, the problem at the end is to find the best matching between the two ontologies (the one required by the intent, and the one supported by the intent handler candidate). This is an ontology matching problem, which is a problem that has been investigated for the integration of systems, especially in the Semantic Web. Many works from different areas have investigate and proposed methods for ontology mapping; a comprehensive survey on these methods can be found in Kalfoglou, Y., and Schorlemmer, M., "Ontology mapping: the state of the art," The knowledge engineering review, 18(1), pp.1-31 (2003). According to the authors of this survey, ontology matching can be defined as "the task of relating the vocabulary of two ontologies that share the same domain of discourse in such a way that the mathematical structure of ontological signatures and their intended interpretations, as specified by the ontological axioms, are respected." It is important to notice that any mapping of models rarely maps all the concepts, therefore typically some information is lost, which means that the resulting intent may not provide all details about the original requirements but yet be useful if other capabilities of the intent handler candidate are considered.

[0077] Various methods and tools can be used to create an ontology matching solution to implement the intent mapping needed in step 3 of Figure 5 and step 5 of Figure 6. At the end, in the case of intent mapping, the result of these methods will be a correspondence between classes and relations in the different intent extension models (used in the original intent and supported by the intent handler candidate). The final goal of the mapping is to use the correspondence to create another intent that has the maximum of information (related to the requirements) from the original intent that needs to be mapped.

[0078] To illustrate the mapping process, the intent model standardized by TM Forum, which is based on RDF, may be used. The intent objects are a graph that follows the ontology according to TM Forum model and they can be represented in different syntaxes, such as TURTLE. Figure 7 shows an example of an intent object represented as a graph, and Figure 8 shows the same intent object using TURTLE. This example of an intent object uses models standardized by SDO1 and from Vendorl. In the example of Figure 7 there are 3 expectations defined, namely vendorl:El, vendorl:E2 and vendorl:E3. vendorl:El is standardized by SDO1 and the other two expectations are defined with model extensions developed by vendorl. In the graph of Figure 7 the node at the top right, sdol:TransportSliceDelivery, is standardized, and the nodes for vendorl are vendor-specific.

[0079] Figure 9 shows an example of a mapping, for the same intent object shown in Figure 1, where none of the expectations that are Vendorl-specific had some correspondence in the ontology supported by the intent handler candidate, and were thus removed. Figure 10 shows the same intent object as in Figure 9 using TURTLE. The mapping results in an intent object that only follows SDO1 models. This means that less requirements are expressed in the intent object and the requirements that are expressed are less specific, since they follow standardized models, and the vendorl-specific models (which were removed) may generally be supposed to provide better expressiveness. Even though this loss of information in the intent object may result in less optimized service being produced, this mapping may be advantageous depending on the other characteristics of the intent manager considered, e.g., more interface procedures that allow a negotiation of better KPIs. In this example, the intent object shown in Figures 9 and 10 could be interpreted by an intent handler that supports vendorl and SDO1 intent extension models but does not support vendorlTransportExt intent extension model.

[0080] The example illustrated in Figures 9 and 10 can happen if the ontology matching method employed required a perfect matching. In this example, because there was no correspondence to the expectation parameter of maximum jitter, the whole vendorl:E2 was removed.

[0081] An alternative approach would be to allow for partial matching. Considering that SDO1 intent extension models provide some classes for general quality expectation (not transport-specific), the parameters of vendorl:E2 could be partially mapped into the ontology defined by SDO1. Figures 11 and 12 show the result of this, where one expectation (vendorl:E3) is removed but the other vendorl-specific expectation (vendorl:E2) is mapped into expectations standardized by SDO1. This is an example that shows some information loss, but less than in the example shown in Figures 9 and 10. Similar consequences to those discussed above apply here, i.e., a service less optimized being produced, but with other advantages, such as the exploitation of other advanced capabilities in the intent manager.

[0082] In view of the examples and details provided above, it will be appreciated that Figure 13 is a process flow diagram illustrating an example method, as performed by a first intent manager, acting as an intent owner. This method is for selecting, from among a plurality of intent managers in a network, an intent handler for handling the intent, along with an intent object to be handled by the selected intent handler. Note that this method is intended to be a generalization of and to encompass the various examples given above. Consequently, where the terminology used below to describe Figure 13 differs from that used to describe corresponding elements or features of the techniques discussed above, the terms used here should be understood to at least encompass their counterparts, unless the context demands otherwise.

[0083] As shown at block 1310, the method comprises querying an intent manager registry to determine a plurality of intent manager candidates for acting as intent handler, where this querying is based on one or more management scope criteria for an intent. This corresponds to step 1 of Figure 5 and step 2 of Figure 6.

[0084] As shown at block 1320, the first intent manager then generates a plurality of intent objects for the intent manager candidates, based on the input requirements, goals, and constraints for the intent. Note that this input, as discussed above, may be in the form of an already determined intent object, or not, in various instances. As also discussed above, this generating of intent objects is based on intent models supported by the intent manager candidates, as indicated by their respective intent manager capability profiles. This step corresponds to step 3 of Figure 5, or step 4 or 5 of Figure 6.

[0085] As shown at block 1330, the method further comprises ranking the intent manager candidates, based on the input requirements, goals and constraints for the intent, the generated intent objects, and one or more predetermined criteria. This corresponds to step 6 of Figure 5 or step 8 of Figure 6. Then, as shown at block 1340, an intent manager candidate is selected to act as intent handler for the intent, based on the ranking. This is shown explicitly as step 9 in Figure 6, and is implicit in step 7 of Figure 5. This ranking of the intent manager candidates may comprise calculating a ranking metric based on a number of supported interface operations for the intent and a number of classes and relations of the intent that are mapped or deleted in generating the intent object, for example.

[0086] In some embodiments or instances, the method may further comprise refining the generated intent objects for one or more of the intent manager candidates, based on optional interface operations supported by the respective intent manager candidates. This is shown at step 4 of Figure 5 and step 6 of Figure 6.

[0087] In some embodiments or instances, generating the intent objects for the intent manager candidates comprises creating the intent objects based on the input requirements, goals, and constraints for the intent and intent models supported by respective intent manager candidates and / or mapping an existing intent object into intent models supported by respective intent manager candidates to obtain the generated intent objects for the respective intent manager candidates. These alternatives are shown at steps 4 and 5 in Figure 6. Note that one of these approaches might be applied to one or more of the intent manager candidates while the other is applied to other candidates. It is also possible that multiple intent objects are created or multiple mappings are performed for a given intent manager candidate, such that the ranking shown at block 1330 is performed for multiple pairings of that intent manager candidate to respective candidate intent blocks.

[0088] The creating and / or mapping shown at block 1320 of Figure 13 comprises, in at least some embodiments or instances, identifying the supported intent models for the intent manager candidates by retrieving profiles for intent manager candidates from the intent manager registry and extracting respective lists of supported intent models from the profiles. This is shown at step 3 in Figure 6.

[0089] In embodiments or instances in which generating the intent object for at least one of the intent manager candidates comprises mapping an existing intent object into intent models supported by the respective intent manager candidate, this mapping may comprise performing an ontology matching between classes and relations of the existing intent object and corresponding classes and relations of intent models supported by the respective intent manager candidate. In these embodiments or instances, ranking the at least one of the intent manager candidates may then be based on an evaluation of correspondence between the classes and relations of the existing intent object and corresponding classes and relations of intent models supported by the respective intent manager candidate.

[0090] Advantages of the techniques, apparatuses, and systems described herein include that they may be used to provide automated and informed decision making during the investigation phase of intent life cycle management, as in practical scenarios there can be multiple options for the selection of an intent manager that will act as intent handler for the fulfillment of a given intent object. Selecting the best intent manager is crucial for the success of customer satisfaction, and the automated systems need to make such decision autonomously (without intervention of humans) and in an informed manner (considering and weighting all possibilities). The solutions described herein focus on automating and improving the selection of the best intent manager and the corresponding intent object with a formal method.

[0091] The improved selection flows from the use of criteria-based decision making for the selection of intent managers. The intent manager selection is a crucial step in the life cycle of intents. There can be multiple criteria to be considered in the selection, e.g., it is possible to only consider the intent managers that fully support all intent models and intent extension models, or to consider intent managers that support more optional and advanced interface procedures, such as intent negotiation, or to consider intent managers from a specific vendor, etc. These criteria can be embedded in the technique, e.g., using weighted parameters to reflect the criteria, since the ranking step weights the different capabilities and features of the intent manager to provide the best selection. This allows a more informed and efficient intent manager selection mechanism.

[0092] The techniques described herein are implemented as part of the intent manager registry and as part of the intent managers that play the role of intent owner. Each of these roles (intent manager registry, intent owner, and intent handler) can be implemented as (part of) a virtual network function or as part of existing network functions. Accordingly, these techniques can be implemented in a cloud environment, or using dedicated hardware nodes, in various embodiments.

[0093] One area of interest for possible future implementation is the O-RAN architecture. Currently, intents as discussed herein are not considered in the O-RAN architecture. In O-RAN, intents are defined as declarative policies and can be used for policy guidance over the Al interface for interactions between non-real-time RAN Intelligent Controller (RIC) and near-real-time RIC.

[0094] The type of intents considered herein are so far used to specify requirements for RAN services that can be consumed by the SMO. It is planned to bring this type of intent specification within the SMO architecture and to use the same type of modeling as considered in this invention. In the future, if the same type of intent is used in O-RAN's SMO, rApps could be used to implement the intent managers. In this case, the techniques described herein would be implemented within an rApp. The intent manager registry is a concept that does not exist in O-RAN's SMO, but it could be realized by any type of inventory service together with the SMO's Service Exposure Functions (SME), which is responsible for exposing the SMO services among different rApps consumers. The application of the techniques described herein in O-RAN depends on the future evolution of the architecture, especially at the SMO level, but it is expected that the techniques described herein can be implemented in any network environment in which intent-based management utilizing intents as described herein is employed.

[0095] Figure 14 is a block diagram of a network node 1400, in accordance with various aspects described herein. As used herein, the network node 1400 may be or comprise various combinations of hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The network node 1400 may provide one or more services to one or more UEs and / or other end user devices and / or provide one or more network management services.

[0096] The network node 1400 includes processing circuitry 1402 that is operatively coupled via a bus 1404 to an input / output interface 1406, a network interface 1408, a power source 1410, and a memory 1412. Other components may be included in other embodiments.

[0097] The memory 1412 may include one or more computer programs including one or more network node programs 1414 and data 1416, which may include network configuration data, for example. Embodiments of the network node 1400 may utilize only a subset or all of the components shown. The network node programs 1414 may be implemented in a container-based architecture. The network node programs 1414 and data 1414 may comprise computer program instructions and data for execution by the processing circuit 1402, such that execution of the computer program instructions causes the network node 1400 to carry out one or more of the methods and / or techniques described herein. Figure 15 is a block diagram illustrating a virtualization environment 1500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

[0098] Applications 1502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1500 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. For example, in various embodiments, various gateway exposure functions (GEF), network repository functions (NRF), and network data analytics functions (NWDAF) described herein can be instantiated as virtual NFs in environment 1500, such that each instantiation performs operations corresponding to methods (or procedures) described elsewhere herein.

[0099] Hardware 1504 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry (collectively denoted computer program product 1504a), and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1508a and 1508b (one or more of which may be generally referred to as VMs 1508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1506 may present a virtual operating platform that appears like networking hardware to the VMs 1508.

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

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

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

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

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

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

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

[0107] 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. In addition, certain terms used in the present disclosure, including the specification and drawings, can be used synonymously in certain instances (e.g., "data" and "information"). It should be understood, that although these terms (and / or other terms that can be synonymous to one another) can be used synonymously herein, there can be instances when such words can be intended to not be used synonymously. Further, to the extent that the prior art knowledge has not been explicitly incorporated by reference herein above, it is explicitly incorporated herein in its entirety. All publications referenced are incorporated herein by reference in their entireties. If the publications have different versions, the most recent version as of the filing date of this application is intended.

Claims

CLAIMS1. A method, performed by a first intent manager, acting as an intent owner, for selecting, from among a plurality of intent managers in a network, an intent handler for handling an intent, the method comprising: querying (1310) an intent manager registry to determine a plurality of intent manager candidates for acting as intent handler, wherein said querying is based on one or more management scope criteria for the intent; generating (1320) a plurality of intent objects for the intent manager candidates, based on the input requirements, goals, and constraints for the intent; ranking (1330) the intent manager candidates, based on the input requirements, goals and constraints for the intent, the generated intent objects, and one or more predetermined criteria; and selecting (1340) an intent manager candidate to act as intent handler for the intent, based on the ranking.

2. The method of claim 1, wherein the method further comprises refining the intent object for one or more of the intent manager candidates, based on optional interface operations supported by the respective intent manager candidate.

3. The method of claim 1 or 2, wherein generating (1320) the intent objects for the intent manager candidates comprises creating the intent objects based on the input requirements, goals, and constraints for the intent and intent models supported by respective intent manager candidates and / or mapping an existing intent object into intent models supported by respective intent manager candidates to obtain the generated intent objects for the respective intent manager candidates.

4. The method of claim 3, further comprising identifying the supported intent models for the intent manager candidates by retrieving profiles for intent manager candidates from the intent manager registry and extracting respective lists of supported intent models from the profiles.

5. The method of claim 3 or 4, wherein generating (1320) the intent object for at least one of the intent manager candidates comprises mapping an existing intent object into intent models supported by the respective intent manager candidate, and wherein said mapping comprises performing anontology matching between classes and relations of the existing intent object and corresponding classes and relations of intent models supported by the respective intent manager candidate.

6. The method of claim 5, wherein ranking (1330) the at least one of the intent manager candidates is based on an evaluation of correspondence between the classes and relations of the existing intent object and corresponding classes and relations of intent models supported by the respective intent manager candidate.

7. The method of any one of claims 1-6, wherein ranking (1330) the intent manager candidates comprises calculating a ranking metric based on a number of supported interface operations for the intent and a number of classes and relations of the intent that are mapped or deleted in generating the intent object.

8. A network node (1400) adapted to carry out a method according to any one of claim 1-7.

9. A network node (1400) for selecting, from among a plurality of intent managers in a network, an intent handler for handling an intent, the network node (1400) comprising: processing circuitry (1402); and memory (1412) operatively coupled to the processing circuitry (1402), the memory (14112) comprising program instructions for execution by the processing circuitry (1402) whereby the network node (1400) is configured to: query an intent manager registry to determine a plurality of intent manager candidates for acting as intent handler, wherein said querying is based on one or more management scope criteria for the intent; generate a plurality of intent objects for the intent manager candidates, based on the input requirements, goals, and constraints for the intent; rank the intent manager candidates, based on the input requirements, goals and constraints for the intent, the generated intent objects, and one or more predetermined criteria; and select an intent manager candidate to act as intent handler for the intent, based on the ranking.

10. The network node (1400) of claim 9, wherein the network node (1400) is configured to refine the intent object for one or more of the intent manager candidates, based on optional interface operations supported by the respective intent manager candidate.

11. The network node (1400) of claim 9 or 10, wherein the network node (1400) is configured to generate the intent objects for the intent manager candidates by creating the intent objects based on the input requirements, goals, and constraints for the intent and intent models supported by respective intent manager candidates and / or mapping an existing intent object into intent models supported by respective intent manager candidates to obtain the generated intent objects for the respective intent manager candidates.

12. The network node (1400) of claim 11, wherein the network node (1400) is further configured to identify the supported intent models for the intent manager candidates by retrieving profiles for intent manager candidates from the intent manager registry and extracting respective lists of supported intent models from the profiles.

13. The network node (1400) of claim 11 or 12, wherein the network node (1400) is configured to generate the intent object for at least one of the intent manager candidates by mapping an existing intent object into intent models supported by the respective intent manager candidate, wherein said mapping comprises performing an ontology matching between classes and relations of the existing intent object and corresponding classes and relations of intent models supported by the respective intent manager candidate.

14. The network node (1400) of claim 13, wherein the network node (1400) is configured to rank the at least one of the intent manager candidates based on an evaluation of correspondence between the classes and relations of the existing intent object and corresponding classes and relations of intent models supported by the respective intent manager candidate.

15. The network node (1400) of any one of claims 9-14, wherein the network node (1400) is configured to rank the intent manager candidates by calculating a ranking metric based on a number of supported interface operations for the intent and a number of classes and relations of the intent that are mapped or deleted in generating the intent object.

16. A computer program product for selecting, from among a plurality of intent managers in a network, an intent handler for handling an intent, the computer program product comprising program instructions configured to cause processing circuitry executing the program instructions to carry out a method according to any one of claims 1-7.

17. A computer-readable medium comprising the computer program product of claim 16.

Images