Knowledge sharing in intent-based networks

Abstract

A computer-implemented method for automated handling of intents in an intent-based network (IBN), including a plurality of intent managers, is provided. The method is executed by a first intent manager. The method comprises generating a first set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts; receiving, from a second intent manager, an intent context including a set of intents; encoding the received intent context to a second set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts; identifying from the second set of embeddings knowledge relevant to the received intent context; decoding the identified knowledge from the second set of embeddings; and sending, to the second intent manager the decoded knowledge for use by the second intent manager for a proposal to fulfill the set of intents.

Description

KNOWLEDGE SHARING IN INTENT-BASED NETWORKS TECHNICAL FIELD

[0001] Disclosed are embodiments related to knowledge sharing in intent-based network (IBN) and, in particular, to automated handling of intents in an IBN including a plurality of intent managers.BACKGROUND

[0002] Intent based networks (IBNs) enable closed loop automation by capturing business intent from service providers and translating them to network actions, thereby enabling autonomous systems. In order to satisfy the business intents and continuously adjust for alignment, these systems use knowledge expressed in different formats, for example, in the form of a knowledge graph.

[0003] The agents working on this could be a machine learning (ML) application, a rule-based application, or any other software application. Each of these applications could rely on, for example, a knowledge graph to achieve its corresponding goals.

[0004] An essential enabler needed for autonomous operation is the necessity for the automated system to know its requirements, goals, and constraints. The system can only adapt and follow business needs if it knows them. The autonomous system needs to know what it is expected to achieve by the service provider, who employs the autonomous system, and the service provider’s customers who are served by it. This includes knowledge not only about expectations, but also about preferences and priorities. Knowledge about these topics can change dynamically because it ultimately originates from dynamic concerns, such as service provider strategy and customer need.SUMMARY

[0005] Knowledge repositories are at the center of the intent-based paradigm, functioning to store and manage knowledge. The explosion of knowledge increases system complexity, impacts storage, and can also bring down efficiency of the system. Also, it is important to have knowledge identified and available at the right time for autonomous systemsto consume experiences across a network, such as, for example, for intent managers across an intent-based network (IBN).

[0006] Life cycle management (LCM) of knowledge is an important need to understand relevancy based on context and to enable sharing within autonomous systems and across networks of the same profile using it. LCM of knowledge must be done for each knowledge unit, which can be, for example, a single triple - i.e., semantic knowledge data codified in the form of subject-predicate-object expressions) — or a logical group of triples created based on knowledge attributes or usage.

[0007] Current approaches do not provide any mechanism to share knowledge across intent managers which can, for example, learn continuously. Similarly, archiving or retaining the knowledge within an intent manager is mostly based on static, temporal configurations or on a domain expert’s manual operation.

[0008] It would be advantageous to indicate and share knowledge across intent managers of same profiles. It is possible that in a geo or segment distributed network, intent managers as autonomous systems evolve based on events, issues, behavior and knowledge gained by this process. However, this may not happen at equal speed and clarity at all intent managers of same profile. Currently, there are no means to extract and share this knowledge, so that we avoid time lapse in autonomous systems to extract unknown experience only.

[0009] Distributed knowledge across autonomous system instances of similar profile needs to be leveraged to improve the efficiency of intent managers as knowledge is continuously generated and consumed by agents. While it can be useful to share knowledge across clusters of intent managers, if broadcasted, it is not always needed knowledge and it is not always required to be shared or needed to be consumed. This could be due to a difference in characteristics of the geo-segment for that intent manager, could be due to privacy regulations of data / knowledge of the segment, or due to other reasons. This also is a challenge to be taken care in knowledge management.

[0010] A novel technique is required to effectively manage and share knowledge between intent managers in IBNs. While there is some resemblance to techniques used in edge networks or Content Delivery Networks (CDNs) based solutions to manage content and data,the characteristics of the objects being served in edge networks and CDNs (see Shuja et al., “ Applying Machine Learning Techniques for Caching in Edge Networks: A Comprehensive Survey, ” Journal of Network and Computer Applications, 2021,103005 -are different from the characteristics of knowledge in IBNs.

[0011] Embodiments disclosed herein leverage the unique characteristics of knowledge in IBNs, including:• Issues (and intents) will typically not occur in isolation and knowledge is also unlikely to be consumed in isolation.• Intent carries knowledge about requirements, goals, and constraints, including context and supplementary information. It does this based on suitable vocabulary and semantics. This is completely different from data and content in edge networks caching or replication.• Capturing the dependencies between knowledge units is critical for efficient intent-loop completion which also involves cognition.• A given context of intents may require more or less than the (linear) sum of the knowledge / facts required for the individual issues / intents.• Capturing the “semantics” of which issues typically occur with which intents along with its context and which knowledge artifacts are needed to serve those intents, is critical to (proactively or reactively) ascertaining its relevancy and sharing it across intent managers

[0012] A novel technique to effectively manage and share knowledge between intent managers in IBNs that enables intelligent and self-adapting life cycle management of knowledge is required to move towards zero touch operation.

[0013] Embodiments disclosed herein enable knowledge sharing and management in intent-based networks that provides sharing of relevant knowledge artifacts across intent managers and knowledge management for individual intent managers - e.g., knowledge not currently relevant to an intent manager and its peers may be archived.

[0014] In embodiments disclosed herein, intent managers develop and use domainspecific embeddings of knowledge artifacts that learn contextual associations between intents and knowledge artifacts relevant to those intents. Intent managers use this contextual relevance along with temporal factors to actively identify dis-used knowledge artifacts for archival or other house-keeping actions required of the context.

[0015] Embodiments disclosed herein can be applied in the context of Intent-based Autonomous Networks for Telecommunications. More particularly, with respect to standardization as per TM forum standards, embodiments disclosed herein address:1) the communication interface enabling the knowledge sharing between intentmanagers; and2) the intent-manager metadata attributes that enable the identification of (groups of) intent-managers as candidates for knowledge-sharing.

[0016] Embodiments disclosed herein are also applicable to other standards defining Intent based Autonomous Networks (e.g., 3GPP and IETF).

[0017] In embodiments disclosed herein, embeddings that capture associations between one or more intents being serviced and the knowledge artifacts that are relevant to them are developed. The embeddings developed aim at capturing contextual relevance of knowledge artifacts in both previously observed intent-contexts and new intent-contexts (generalizing to a previously unseen group of intents).

[0018] Embodiments disclosed herein use mechanisms for distributed learning of embeddings, the grouping of intent-managers to enable scalable messaging for knowledgesharing and the contextual + temporal determination of knowledge life-cycle management decisions (e.g., an artifact that is not relevant to an intent-manager or any of its peers may be archived).

[0019] From an industrialization / standardization perspective, embodiments disclosed herein provide for standardization of the message-passing interface between intent managers and of attributes / metadata of an intent-manager, that would aid in the discovery of its peer group for the purposes of knowledge sharing in Intent-based networks.

[0020] An advantage of some of the embodiments disclosed herein is that they provide for efficient intent loop execution and effective information sharing across intent managers in intent based networks (IBNs).

[0021] A further advantage of some of the embodiments disclosed herein is that they provide knowledge retention scalability. Constant archival of knowledge brings in improved scalability of knowledge retention and keeps the optimal needed knowledge in Intent managers where some instances could be resource critical.

[0022] According to a first aspect, a computer-implemented method for automated handling of intents in an intent-based network (IBN) including a plurality of intent managers is provided. The method is executed by a first intent manager. The method includes generating a first set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts. The method includes receiving, from a second intent manager, an intent context including a set of intents. The method includes encoding the received intent context to a second set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts. The method includes identifying from the second set of embeddings knowledge relevant to the received intent context. The method includes decoding the identified knowledge from the second set of embeddings. The method includes sending, to the second intent manager the decoded knowledge for use by the second intent manager for a proposal to fulfill the set of intents.

[0023] In some embodiments, generating the first set of embeddings includes using one or more of: intent definitions; intent constraints; measured states; deviation from intent expectation; actions taken; and knowledge used for actions taken.

[0024] In some embodiments, the first set of embeddings generated represent cooccurrence and / or contextual -relevance associations between one or more of: co-occurring intents; issues observed for the received intent context; and knowledge artifacts relevant for handling the received intent context.

[0025] In some embodiments, generating the first set of embeddings includes training and / or learning the first set of embeddings. In some embodiments, the training and / or learning the first set of embeddings comprises using an artificial intelligence / machine learning (AI / ML)model. In some embodiments, the training and / or learning the first set of embeddings comprises using one or more of: centralized learning; distributed learning; and federated learning. In some embodiments, the training and / or learning the first set of embeddings comprises using one or more of a pre-trained word-embedding model with or without additional domain-specific fine-tuning; and a self-trained word-embedding model starting from a word-encoding.

[0026] In some embodiments, the first set of embeddings generated include domainspecific embeddings of knowledge artifacts that learn contextual associations between intents and knowledge artifacts relevant to the intents.

[0027] In some embodiments, the method includes determining that the decoded knowledge is not relevant to the received intent context or will not be used. In some embodiments, the method includes one or more of storing the irrelevant or un-used knowledge; archiving the irrelevant or un-used knowledge; deleting the irrelevant or un-used knowledge; and processing the irrelevant or un-used knowledge based on an intended use.

[0028] In some embodiments, each intent manager in the plurality of intent managers has a profile signature with a plurality of attributes, and the plurality of attributes includes one or more of an attribute specifying a scope of knowledge sharing and / or requesting allowed for the intent manager; and / or a unique logical group identification (ID).

[0029] In some embodiments, the method further includes identifying a grouping of intent managers from the plurality of intent managers that the first intent manager is associated with.

[0030] In some embodiments, an interface for sending and receiving information between intent managers from the plurality of intent managers provides for requesting knowledge sharing between intent managers and sharing knowledge artifacts and embeddings. In some embodiments, the interface for sending and receiving information between intent managers uses a resource description framework schema (RDFS).

[0031] In some embodiments, the first intent manager and the second intent manager perform intent management functions including for: a radio access network (RAN); a core network; and / or a transport network. In some embodiments, the intent management functionsinclude one or more of: configuration management, configuration optimization, performance measurement, performance management, congestion control, slice orchestration, service level agreement (SLA) assurance, and energy efficiency.

[0032] In some embodiments, the first intent manager and the second intent manager each have a manager capability profile with similar scope of responsibilities. In some embodiments, the first intent manager and the second intent manager each have a manager capability profile with different geographical distribution or with different business contexts.

[0033] In some embodiments, the received intent context includes, in the set of intents, at least a first intent, and wherein the decoded knowledge sent to the second intent manager includes knowledge relevant to at least the first intent and a second intent. In some embodiments, the first intent is to resolve network congestion and the second intent is to maintain energy efficiency.

[0034] According to a second aspect, a computer-implemented method for automated handling of intents in an intent-based network (IBN) including a plurality of intent managers is provided. The method is executed by a second intent manager. The method includes identifying an intent context including a set of intents. The method includes sending, to a first intent manager, the identified intent context. The method includes receiving, from the first intent manager, knowledge relevant to the identified intent context. The method includes encoding the received knowledge to generate a set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts. The method includes identifying from the set of embeddings knowledge relevant to the identified intent context. The method includes decoding the identified knowledge from the set of embeddings. The method includes adding the decoded knowledge to a knowledge base. The method includes using the decoded knowledge for a proposal to fulfill one or more of the intents in the set of intents.

[0035] According to a third aspect, a first intent manager is provided. The first intent manager includes processing circuitry and a memory containing instructions executable by the processing circuitry for automated handling of intents in an intent-based network (IBN) including a plurality of intent managers. The first intent manager operative to generate a firstset of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts. The first intent manager operative to receive, from a second intent manager, a current intent context including a set of intents. The first intent manager operative to encode the received current intent context to a second set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts. The first intent manager operative to identify from the second set of embeddings knowledge relevant to the current intent context. The first intent manager operative to decode the identified knowledge from the second set of embeddings. The first intent manager operative to send, to the second intent manager the decoded knowledge for use by the second intent manager for a proposal to fulfill the set of intents.

[0036] According to a fourth aspect, a second intent manager is provided. The second intent manager includes processing circuitry and a memory containing instructions executable by the processing circuitry for automated handling of intents in an intent-based network (IBN) including a plurality of intent managers. The second intent manager operative to identify an intent context including a set of intents. The second intent manager operative to send, to a first intent manager, the identified intent context. The second intent manager operative to receive, from the first intent manager, knowledge relevant to the identified intent context. The second intent manager operative to encode the received knowledge to generate a set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts. The second intent manager operative to identify from the set of embeddings knowledge relevant to the identified intent context. The second intent manager operative to decode the identified knowledge from the set of embeddings. The second intent manager operative to add the decoded knowledge to a knowledge base. The second intent manager operative to use the decoded knowledge for a proposal to fulfill one or more of the intents in the set of intents.

[0037] According to a fifth aspect, an intent manager in an intent-based network (IBN) for automated handling of intents is provided. The intent manager includes one or more memories comprising instruction data representing a set of instructions and one or more processors configured to communicate with the one or more memories and to execute the set of instructions, wherein the set of instructions, when executed by the processor, cause the one ormore processors to perform the methods of any one of the embodiments of the first, second, third, and fourth aspects.

[0038] According to a sixth aspect, a computer program is provided comprising instructions which, when executed by processing circuitry, causes the processing circuitry to perform the methods of any one of the embodiments of the first, second, third, and fourth aspects.

[0039] According to a seventh aspect, a carrier is provided containing the computer program of the sixth aspect, wherein the carrier comprises one of an electronic signals, optical signal, radio signal or computer readable storage medium.

[0040] According to an eighth aspect, an apparatus is provided. The apparatus includes a memory and processing circuitry coupled to the memory, wherein the apparatus is configured to perform the methods of any one of the embodiments of the first, second, third, and fourth aspects.BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0042] FIG. l is a block diagram illustrating an architecture and a process for automated handling of intents in an intent-based network (IBN) according to some embodiments.

[0043] FIG. 2 is a block diagram illustrating an architecture and a process for an intent manager intent handling loop.

[0044] FIG. 3 is a block diagram illustrating an architecture and a process for an intent manager according to some embodiments.

[0045] FIG. 4 is a block diagram illustrating an architecture and a process for a responding intent manager and a requesting intent manager according to some embodiments.

[0046] FIG. 5 is a flow chart illustrating a process according to some embodiments.

[0047] FIG. 6 is a flow chart illustrating a process according to some embodiments.

[0048] FIG. 7 is a block diagram illustrating an architecture and a process for a responding intent manager and a requesting intent manager example use case according to some embodiments.

[0049] FIG. 8 is a block diagram illustrating an artificial intelligence / machine learning (AI / ML) model according to some embodiments.

[0050] FIG. 9 is a block diagram illustrating a profile for an intent manager according to the TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0., with additional attributes according to some embodiments.

[0051] FIG. 10 is a block diagram illustrating an architecture for intent manager registration and discovery according to the TM Forum Intent Manager Capability Profiles, IG1253D vl .0.0.

[0052] FIG. 11 is a block diagram illustrating an exemplary resource description framework schema (RDFS) used for an intent handling interface between intent managers for automated handling of intents according to some embodiments.

[0053] FIG. 12 is a block diagram of an apparatus according to some embodiments.

[0054] FIG. 13 is a block diagram illustrating the current 5G RAN (a.k.a., the NextGeneration RAN (NG-RAN)) architecture.DETAILED DESCRIPTION

[0055] FIG. l is a block diagram illustrating an architecture and a process for automated handling of intents in an intent-based network (IBN) according to some embodiments.Referring to FIG. 1, at 110, the system or networks, such as a decentralized knowledge-centric system or network, for example, an intent-based network (IBN), to which the disclosed architecture and process can be applied, implements knowledge lifecycle management (LCM).

[0056] Effective information sharing between intent managers, thereby enabling efficient intent-loop execution, is provided at 120 by utilizing context-based relevancy determinations using domain-specific embeddings with a mechanism to capture co-association / co- occurrence / analogous patterns between intents, issues and / or network-states and knowledge artifacts.

[0057] For training or learning embeddings, at 130, distributed, centralized or federated learning is used, and logical-groups (e.g., based on history of intents or network topology) are used for scalable message passing and knowledge management.

[0058] Embodiments disclosed herein provide for, at 140, efficient intent-loop execution, at 150, effective information-sharing, and at 160, effective LCM decisions, e.g., archiving of irrelevant knowledge.

[0059] Intent-based systems and networks could generate or consume huge amounts of knowledge units, expressed as knowledge graphs. This gives rise to the importance of sharing knowledge across intent managers to enable efficient intent loop handling. Embodiments herein use context based on relevancy of knowledge using domain specific embeddings to identify knowledge that can be shared across intent managers.

[0060] FIG. 2 is a block diagram illustrating an architecture and a process for an intent manager intent handling loop 200. Referring to FIG. 2, the basic workflow which may happen within an intent manager which manages the autonomy and assurance of the intent handling loop 200 for an intent management function is illustrated. The intent handling loop 200 of the intent manager be a designed as a cognitive loop involving internal agents, for example, an intent agent 210 identifying an intent 1, and issues agent 220 for issue detection, a knowledgebase (KB) agent 230 for data grounding, a plurality of proposing agents 240(1) . . . 240(n) with proposals, and evaluating agent 250 to verify the final proposal for actuating using an actuation agent 260. Together, these agents enable the autonomous handling of the intent using knowledge, and the novel method for automated handling of intents of the embodiments disclosed herein enables the efficient management and sharing of the context and working knowledge used by the cognitive loops in different intent managers.

[0061] FIG. 3 is a block diagram illustrating an architecture and a process for an intent manager 300 according to some embodiments. Referring to FIG. 3, the intent manager 300 includes the intent handling loop 200, described with reference to FIG. 2, and an intelligent knowledge management module 310. The intelligent knowledge management module 310 includes an embedder component 320 and a request-respond component 330. The embeddercomponent 320 is comprised of a working knowledge sub-component 322, which includes context 324 and knowledge 326, and an embeddings sub-component 328.

[0062] The request-respond component 330 includes a receive relevant knowledge subcomponent 332, a respond with relevant knowledge sub-component 334, an encode knowledge from embedding sub-component 336, an identify relevant knowledge sub-component 338, a decode identified knowledge from embedding sub-component 340, a receive current context subcomponent 342, and a send current context sub-component 344.

[0063] The intelligent knowledge management module 310 uses the following one or more information and creates an embedding to create representations based on their similarity:• Intent definitions and constraints;• Measured states;• Deviation from intent expectation; and• Actions taken and knowledge used for the same.

[0064] New intents and observed state can get relevant knowledge for the problem it is solving from nearby points in the embedding. The embedding aims to capture co-occurring intents (>= 1), issues that were observed in such a context (>=1 dependent) and knowledge artifacts that were relevant for handling this context. It therefore captures co-occurrence and contextual -relevance associations between them.

[0065] The assumption is that a new context represented by its embedding of one or more intents and / or one or more states / deviations observed will lie sufficiently close in embeddingspace to reduce the knowledge-sharing problem in intent-based networks (IBNs) to an information-retrieval problem. The use of embeddings based on a common underlying language model enables generalization to previously unseen contexts (e.g., new intent combinations).

[0066] FIG. 4 is a block diagram illustrating an architecture and a process for a responding (first) intent manager 400 and a requesting (second) intent manager 450 according to some embodiments. The responding intent manager 400 and the requesting intent manager 450 each include the intent handling loop 200, described with reference to FIG. 2, and the intelligent knowledge management module 310, described with reference to FIG. 3.

[0067] Referring to FIG. 4, there are annotations illustrated that show the steps in the knowledge sharing process, designated as “0” to “5.” Also, certain sub -components in the responding intent manager 400 and the requesting intent manager 450 have been shaded out, indicating that those sub-components are not used when the intent manager is functioning as a responding intent manager or a requesting intent manager, respectively.

[0068] Starting with Step 0 - s410 (Training): The IBN includes a plurality of intent managers, and each intent manager accumulates its working knowledge - i.e., intent, state, knowledge artifacts — and creates the embedding and stores it locally in the intent manager. Referring to FIG. 4, the responding intent manager 400 has an intent 1 402 and needs to address an intent 2 404.

[0069] The agents that are part of the intent handling loop in the intent manager continuously consume / create knowledge to handle the intents based on which proposals are generated for resolving the intent. One of the proposals - referred to in FIG. 4 as “Composite action proposal” 406, is generated using such knowledge unique to the intent manager.

[0070] The intent manager accumulates all of this working knowledge and trains them to create an embedding which can be used for future executions and can be shared with other intent managers when needed. The trained embedding will seek to encode co-associations or cooccurrences between intents, issues / contexts and proposals / knowledge artifacts used.

[0071] At the end of the training process, every intent, context / issue, and knowledge artifact will be associated with an embedding that captures this association. Using embeddings as a mechanism to capture these co-association / co-occurrence patterns, enables effective information sharing between intent managers, as well as efficient intent-loop execution. In addition, using a suitable language-model as a basis to create these embeddings, semantic similarities between similar intents, contexts / issues and knowledge artifacts may also be encoded, leading to improved generalization to previously unseen scenarios.

[0072] Step Kintent Handling Loop) - s420: The requesting intent manager 450 may face similar intent and context as the responding intent manager 400, and sends the context to the request-respond component.

[0073] Step 2 (Requesting Client) - s430: The requesting intent manager 450 checks for any previous knowledge available in other intent managers by sending the context signature as a request over the standard interface between the intent managers.

[0074] Step 3 (Inference) - s440: The responding intent manager 400 receives the context signature, checks-for and identifies any relevant knowledge artifacts, given the embedding of the context-in-question and those of the knowledge artifacts available with the responding intent manager 400.

[0075] Step 4 (Responding Client) - s460: The responding intent manager 400 responds to the request by sharing the knowledge over the standard interface between the intent managers.

[0076] Step 5 (Requesting Client) - s470: The requesting intent manager 450 receives the relevant knowledge and adds the received knowledge to its knowledge base making it available for the intent handling loop.

[0077] Step 6 (Intent Handling Loop) - s480: The requesting intent manager 450 uses the newly received knowledge to efficiently come up with the proposal in the intent handling loop and the proposal gets actuated to resolve the intent.

[0078] FIG. 5 is a flow chart illustrating a process according to some embodiments. Process 500 is a computer-implemented method for automated handling of intents in an intentbased network (IBN) including a plurality of intent managers. The process is executed by a first intent manager. Referring now to FIG. 5, process 500 may begin with step s502.

[0079] Step s502 comprises generating a first set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts.

[0080] Step s504 comprises receiving, from a second intent manager, an intent context including a set of intents.

[0081] Step s506 comprises encoding the received intent context to a second set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts.

[0082] Step s508 comprises identifying from the second set of embeddings knowledge relevant to the received intent context.

[0083] Step s510 comprises decoding the identified knowledge from the second set of embeddings.

[0084] Step s512 comprises sending, to the second intent manager the decoded knowledge for use by the second intent manager for a proposal to fulfill the set of intents.

[0085] In some embodiments, information used to generate the first set of embeddings includes one or more of intent definitions; intent constraints; measured states; deviation from intent expectation; actions taken; and knowledge used for actions taken.

[0086] In some embodiments, the first set of embeddings generated represent cooccurrence and / or contextual -relevance associations between one or more of co-occurring intents; issues observed for the received intent context; and knowledge artifacts relevant for handling the received intent context.

[0087] In some embodiments, the first set of embeddings generated include domainspecific embeddings of knowledge artifacts that learn contextual associations between intents and knowledge artifacts relevant to the intents.

[0088] In some embodiments, the first intent manager and the second intent manager each have a manager capability profile with similar scope of responsibilities. In some embodiments, the first intent manager and the second intent manager each have a manager capability profile with different geographical distribution or with different business contexts.

[0089] In some embodiments, the received intent context includes, in the set of intents, at least a first intent, and wherein the decoded knowledge sent to the second intent manager includes knowledge relevant to at least the first intent and a second intent. In some embodiments, the first intent is to resolve network congestion and the second intent is to maintain energy efficiency.

[0090] FIG. 6 is a flow chart illustrating a process according to some embodiments.Process 600 is a computer-implemented method for automated handling of intents in an intent-based network (IBN) including a plurality of intent managers. The process is executed by a second intent manager. Referring now to FIG. 6, process 600 may begin with step s602.

[0091] Step s602 comprises identifying an intent context including a set of intents.

[0092] Step s604 comprises sending, to a first intent manager, the identified intent context.

[0093] Step s606 comprises receiving, from the first intent manager, knowledge relevant to the identified intent context.

[0094] Step s608 comprises encoding the received knowledge to generate a set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts.

[0095] Step s610 comprises identifying from the set of embeddings knowledge relevant to the identified intent context.

[0096] Step s612 comprises decoding the identified knowledge from the set of embeddings.

[0097] Step s614 comprises adding the decoded knowledge to a knowledge base.

[0098] Step s616 comprises using the decoded knowledge for a proposal to fulfill one or more of the intents in the set of intents.

[0099] Example of intent managers for RAN management

[0100] In each network, there could be multiple intent managers distributed across geographies or logical divisions. Knowing the knowledge sharing attribute of the intent managers and sharing, if needed, the knowledge between these intent managers provides for efficient intent loop handling. The exemplary use case described herein includes two intent managers for RAN management, possibly with similar manager capability profiles (which can be based on the published profile on scope of responsibilities, as defined in the TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0 standard) distributed across geographies and having different context.

[0101] Since network state and issue detection / assurance may happen dynamically, the responding (first) intent manager may have faced a network congestion issue and come up with an effective proposal with composite action, which satisfies both energy efficiency intent and the network congestion intent, and the same may be applicable to other intent managers of similar profile who have not yet faced the same.

[0102] The context in one instance might have been already faced by other instances and sharing the knowledge will make the intent handling in the first instance efficient. In the below example, the responding (first) intent manager faces a network congestion context along with energy efficiency intent and it came up with the proposal with the knowledge unique to the manager. This proposal and knowledge artifacts relevant to the knowledge, can be shared with the requesting (second) intent manager when it faces the similar context.

[0103] FIG. 7 is a block diagram illustrating an architecture and a process for a responding (first) intent manager and a requesting (second) intent manager example use case according to some embodiments. The responding intent manager 700 and the requesting intent manager 750 each include the intent handling loop 200, described with reference to FIG. 2, and the intelligent knowledge management module 310, described with reference to FIG. 3.

[0104] Referring to FIG. 7, just as with the discussion of FIG. 4, there are annotations illustrated that show the steps in the knowledge sharing process, designated as “0” to “5.” Also, certain sub-components in the responding intent manager 700 and the requesting intent manager 750 have been shaded out, indicating that those sub-components are not used when the intent manager is functioning as a responding intent manager or a requesting intent manager, respectively

[0105] Starting with Step 0 - s710 (Training): The IBN includes a plurality of intent managers, and each intent manager accumulates its working knowledge - i.e., intent, state, knowledge artifacts — and creates the embedding and stores it locally in the intent manager. Referring to FIG. 7, the responding intent manager 700 for RAN management has an energy efficiency (EE) intent 702 and faces a network congestion context 704.

[0106] The agents that are part of the intent handling loop in the intent manager continuously consume / create knowledge to handle the intents based on which proposals aregenerated for resolving the intent. One of the proposals - referred to in FIG. 7 as “Composite Action” proposal 706, is generated using such knowledge unique to the intent manager.

[0107] The intent manager accumulates all of this working knowledge and trains them to create an embedding which can be used for future executions and can be shared with other intent managers when needed. The trained embedding will seek to encode co-associations or cooccurrences between intents, issues / contexts and proposals / knowledge artifacts used.

[0108] At the end of the training process, every intent, context / issue, and knowledge artifact will be associated with an embedding that captures this association. Using embeddings as a mechanism to capture these co-association / co-occurrence patterns, enables effective information sharing between intent managers, as well as efficient intent-loop execution. In addition, using a suitable language-model as a basis to create these embeddings, semantic similarities between similar intents, contexts / issues and knowledge artifacts may also be encoded, leading to improved generalization to previously unseen scenarios.

[0109] Step Kintent Handling Loop) - s720: The requesting intent manager 750 for RAN management may face similar intent and context as the responding intent manager 700, and sends the context to the request-respond component.

[0110] Step 2 (Requesting Client) - s730: The requesting intent manager 750 checks for any previous knowledge available in other intent managers by sending the context signature as a request over the standard interface between the intent managers.

[0111] Step 3 (Inference) - s740: The responding intent manager 700 receives the context signature, checks-for and identifies any relevant knowledge artifacts, given the embedding of the context-in-question and those of the knowledge artifacts available with the responding intent manager 700.

[0112] Step 4 (Responding Client) - s760: The responding intent manager 700 responds to the request by sharing the knowledge over the standard interface between the intent managers.

[0113] Step 5 (Requesting Client) - s770: The requesting intent manager 750 receives the relevant knowledge and adds the received knowledge to its knowledge base making it available for the intent handling loop.

[0114] Step 6 (Intent Handling Loop) - s780: The requesting intent manager 750 uses the newly received knowledge to efficiently come up with the proposal in the intent handling loop and the proposal gets actuated to resolve the intent.

[0115] Training or Learning embeddings and using them in inference

[0116] In some embodiments, generating the first set of embeddings includes training and / or learning the first set of embeddings. In some embodiments, the training and / or learning the first set of embeddings comprises using an artificial intelligence / machine learning (AI / ML) model. In some embodiments, the training and / or learning the first set of embeddings comprises using: centralized learning; distributed learning; and / or federated learning. In some embodiments, the training and / or learning the first set of embeddings comprises using: a pretrained word-embedding model with or without additional domain-specific fine-tuning; and / or a self-trained word-embedding model starting from a word-encoding. In some embodiments, the training and / or learning the first set of embeddings comprises using sentence embeddings to form embeddings of the intent-context and / or knowledge.

[0117] There various approaches that can be used for training or learning embeddings and using them in inference. FIG. 8 is a block diagram illustrating an artificial intelligence / machine learning (AI / ML) model 800 according to some embodiments. Referring to FIG. 8, the AI / ML model 800 illustrated is a neural network based model for learning associations between intents and knowledge artifacts. The AI / ML model 800 includes an intent context 810, which may comprise one or more co-occurring intents and, if available, it may include issues. The AI / ML model 800 includes a neural network 820 and knowledge artifacts 830(1) to 830(n).

[0118] Various exemplary approaches that can be used for training or learning embeddings and using them in inference are described.

[0119] Approach #1: Learning associations between intents, issues (created due to non- compliant network states) and knowledge artifacts through their descriptions.

[0120] Applicability - centralized, local / individual (intent manager) or federated training.

[0121] Assumptions - common language (vocabulary) and pre-trained word-embeddings across all intent managers.

[0122] Algorithm #1 (Training)(1) Identify a (off-the-shelf) pre-trained word-embedding model to provide embeddings for words in descriptions of intents, issues and knowledge. A Telco-specific wordembedding is preferred, to be able to cater to Telco jargons. Every embedding will be a vector of length nl (common sizes are 200, 300, 600).(2) Create a data set with input-output pairs of representing intent-context - knowledge artifact associations and vice versa. o Intent-contexts represent the aggregate word-embedding obtained using the descriptions of one or more intents in a given context. o Intent-contexts may additionally represent the aggregate word-embedding obtained using the descriptions of one or more ISSUES observed, in a given context. o Outputs will represent the aggregate word-embedding of the description of a knowledge artifact, relevant to the said intent-context.(3) Train a ML model (e.g., Neural Network) that is able to learn an association or mapping between intent-contexts (both intents only and intents + issues) and knowledge artifacts. This is a classification task.(4) After successful ML model training, the internal (model or Neural Network) representation of the intent-context (or knowledge artifact) represents the embedding that captures its association with relevant knowledge artifacts (or intents). The length of the embedding vector is determined by the model (e.g., number of hidden nodes in a single hidden-layer neural network)(5) Repeat step (2) by appending new data and optionally retaining the most recent data, at some predefined cadence.(6) Repeat step (3) as a retraining or fine-tuning step given new data from (5). This enables maintaining updated embeddings

[0123] Algorithm #2 (Inference)(1) Receive an intent context from requesting intent-manager. The intent-context will describe one or more intents; it may also contain descriptions of one or more issues that were observed.(2) Create an aggregate word-embedding representation using the description words of the of the received intent-context.(3) Pass the intent-context representation through the trained model, to obtain its embedding.(4) The embeddings of knowledge artifacts are available, obtained by passing their wordembedding based representations through the trained ML model in Algorithm #1(5) Use the intent-context-embedding and identify the nearest-neighbor knowledge artifacts, based on a cosine similarity metric and threshold. Either a predefined number of such artifacts (e.g., top 100) can be identified or the number can be based on a threshold of similarity.(6) Return the shortlisted knowledge-artifacts to the requesting intent-manager.

[0124] Approach #2: Same as Approach #1 but not using a pre-trained word-embedding and just using a simple word-encoding instead.• This is feasible but will just require much more data and training (=> time and computecost) to generalize well.• Essentially, in this case, we will follow the same procedure as in Approach #1 but we will also have to simultaneously learn embeddings that capture co-associations between words in descriptions.• Either a single model may be used for capturing associations between intent-contexts, knowledge artifacts and word-contexts or two Neural Networks WILL HAVE TO BE JOINTLY TRAINED (=> single cost function) where one does Approach #1 exactly and the other learns embeddings for words.

[0125] Approach #3 : Learning associations between intents, issues (created due to non- compliant network states) and knowledge artifacts through both descriptions and EXPLICIT IDs• Motivation - Message-passing in inference will only need to contain intent IDs and issue IDs and not their descriptions => shorter / more efficient messaging.• Assumptions - o common language (vocabulary) and pre-trained word-embeddings, across all intent managerso common IDs for intents, issues and knowledge artifacts - this is a non-issue in centralized learning but in case of local or federated learning of embeddings, a separate (centralized) ID-registry will have to be maintained so that intent- 1 in one intent-manager refers to intent- 1 in another intent manager. This approach is therefore more suited for centralized learning.• Procedure - The same as in Approach #1 can be used but the embedding for individual intent-IDs is also stored in the centralized registry. Alternatively, associations between ID’s and descriptions can also be “learnt” but this is un-necessary and sub-optimal, given the overall objective.

[0126] Approach #4: Learning associations between intents, issues (created due to non- compliant network states) and knowledge artifacts through only their IDs• Motivation - Message-passing in inference will only need to contain intent IDs and issue IDs and not their descriptions => shorter / more efficient messaging. Also, this approach does not require any pre-trained word-embedding model BUT will not effectively generalize to previously unseen intent contexts.• Assumptions - o common IDs for intents, issues and knowledge artifacts - this is a non-issue in centralized learning but in case of local or federated learning of embeddings, a separate (centralized) ID-registry will have to be maintained so that intent- 1 in one intent-manager refers to intent- 1 in another intent manager. This approach is therefore more suited for centralized learning. The ID-registry, when queried, returns a simple encoding of the queried intent, issue or knowledge artifact.• Procedure - o The same as in Approach #1 can be used but the intent-context representations aggregate simple encodings of intents and / or issues and knowledge-artifact representations also use a simple encoding scheme. o In this case, due to the lack of semantics (descriptions), a lot more data would be required. Generalization to unseen intents, issues and knowledge artifacts is limited; the model is essentially equivalent to a “look-up” table that associatesdifferent intent-contexts (combinations of intents and / or issues) with one or more knowledge artifacts.

[0127] As described above, in some embodiments, the training and / or learning the embeddings uses a pre-trained word-embedding model with or without additional domainspecific fine-tuning and / or a self-trained word-embedding model starting from a word-encoding. Such word-embedding models can be created and / or used in accordance with, for example, Mikolov et al, “Efficient Estimation of Word Representations in Vector Space,” arXiv: 1301.3781v3 [cs.CL] 7 Sep 2013(the Skip-Gram approach in particular); and Le et al., “Distributed Representations of Sentences and Documents,” arXiv: 1405.4053v2 [cs.CL] 22 May 2014.

[0128] A fundamental difference, however, between these references and the context here is, in these references, embeddings are created for words and paragraphs - while they model co-occurrence patterns too, words in text have spatial continuity. In embodiments disclosed herein, the embeddings model data (intents, issues that co-occurred and knowledge artifacts that were required for serving these intents) with temporal continuity (defined by the intent-loop where they co-existed).

[0129] In some embodiments, knowledge artifacts that are relevant to an intent manager and its peers within a logical group are identified. Knowledge artifacts deemed currently irrelevant may be subject to archival or other house-keeping actions.

[0130] In some embodiments, each intent manager in the plurality of intent managers has a profile signature with a plurality of attributes, and the plurality of attributes includes one or more of: an attribute specifying a scope of knowledge sharing and / or requesting allowed for the intent manager; and / or a unique logical group identification (ID).

[0131] In some embodiments, the method includes identifying a grouping of intent managers from the plurality of intent managers that the first intent manager is associated with.

[0132] In some embodiments, the method includes determining that the decoded knowledge is not relevant to the received intent context or will not be used. In some embodiments, the method includes one or more of: storing the irrelevant or un-used knowledge; archiving the irrelevant or un-used knowledge; deleting the irrelevant or un-used knowledge; and processing the irrelevant or un-used knowledge based on an intended use.

[0133] Logical Grouping of Intent managers for Knowledge Sharing

[0134] Logical groups of intent managers can enable scalability to real world applications, which may have many intent managers serving a practical deployment. Implementing the use of logical groups of intent managers would likely reduce a messagebroadcast problem to a message-multicast problem between a small group of intent managers for scalable message passing.

[0135] Logical groups of intent managers could, for example, be applied in intent owner or higher-level intent managers which manage intents to be sent to lower-level intent managers for knowledge sharing as groups. Various exemplary approaches that can be used are described.

[0136] Approach #1 : Knowledge sharing flag and business driven Logical grouping ID assignment, which is also discussed below in connection with extending the IM profile and defining the intent handling interface in the TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0 standard, would enable a first-level grouping of which IMs can principally share knowledge with each other. This is primarily set using business-context (e.g., RAN or BSS), geography or other domain-related considerations.

[0137] Approach #2: Second level logical grouping of the intent managers for knowledge sharing could be achieved by using the following algorithm.• Algorithm #3: creating logical groups of intent managers(1) For each intent-manager■ Identify all unique intents it has served in a predefined time-horizon.■ Identify the embeddings of these unique intents.■ Aggregate these embeddings into a signature for the intent-manager.(2) Apply clustering or a distance-based nearest-neighbor approach applied to the intent-manager signatures, to identify logical groups of intent-managers.■ Clustering can incrementally increase the number of clusters and use standard metrics (e.g., the “elbow” metric) to decide the optimal number.■ Either the top-K nearest neighbor intent managers or all within a distance threshold, can be identified as a logical group (for each intent manager).(3) Logical groups may be revised periodically by repeating the above procedure at some predefined cadence.Variations (embodiments)(4) In embodiments with IDs for intents, for each intent manager a simple histogram of the intent (id’s) that have been served in the recent past (predefined timehorizon) provides a signature for that intent manager. Using these histogramsignatures for various intent managers logical groups may be constructed using any clustering or distance-based nearest-neighbor approach.(5) It is also possible to use a special “hash-function” to directly map intent-histories (of intent managers) to a predefined number of groups. This would constitute a third approach based on the idea of hashing or mapping intent histories to a set of logical groups.

[0138] As described above, the novel methods disclosed herein can be used to perform intent management functions for autonomous networks, including for: a radio access network (RAN); a core network; and / or a transport network. In such autonomous networks, where there are multiple intent management functions across unique domains, operational layer and sub domains / systems, the registration of intent managers, as described, for example, in TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0, should be extended.

[0139] Extending the interface between Intent Manager (IM, also referred to as Intent Handler) and the Intent Manager Registry (IMR): The IMR will incorporate additional profilesignature (IM capabilities) attributes that qualify an IM’s ability to request / share knowledge with other IMs. The IM — > IMR query interface will enable IMs to query / request the IMR, with its profile-signature, to identify / receive its logical peer-group with which it can request / share knowledge.

[0140] Defining the interface between Intent Managers (IMs): The interface between IMs of a logical peer-group will enable an IM to query / request its peers with a context-signature (of the intents it needs to service) and receive as response any available knowledge artifacts relevant to that context.

[0141] As per TMForum standards (TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0), every IM has a unique set of capabilities, as well as a defined scope of responsibilities. To make this information available to other functions, an IM creates a profileabout its own scope and capabilities. It then sends the profile to the IMR. Depending on the implementation of an IM, its capability profile might not be constant. It can change, for example, if policies or apps are added or machine learned models are replaced with an improved version. In modem systems, these are artifacts with their own life cycles, and changes in them can introduce or remove features with an effect on capabilities of an IM.

[0142] Further, along with extending registration of IMs, exposure of the interface from the IMF to IMs, and an embedding of all IMs with similar profiles or capabilities should also be extended. This can be an extension on top of query for IM capability profiles. This information will be very useful when the receiving IM needs to multi cast the request for knowledge for a given context of intents and issues, if there is any sharing IM able to share proposals and / or knowledge artifacts.

[0143] Based on the profile signature of an IM group, a query to the IMR will get the IM address and contact information of the instance of IM function the profile is about. The string, for example, contains the Internationalized Resource Identifiers (IRI(s)) that are representing the IM instances, as explained in TM Forum Intent Manager Capability Profiles, IG1253D vl .0.0.

[0144] As per the current standards, the details of the interface design between IMR and IMs is not specified. Capability publication interfaces are a common feature in adaptable systems. Therefore, standard methods and processes for designing the respective interface registration and publication interface could, perhaps, be applied.

[0145] As per current standards, models based on RDF / RDFS for expressing the IM capability profile could be used. Therefore, it would be sensible to base the discovery interface on a query language designed and standardized for RDF.

[0146] The profile signature of an IM should also be extended to have an attribute which can specify the scope of knowledge sharing / requesting allowed for the particular IM and a unique logical group ID, as described above, so that we keep the knowledge sharing functionality managed via capability profile linked to sub domains / sub systems of intents which the IM is supporting.

[0147] In, for example, slice management scope, the attribute could be “no knowledge share,” whereas for Energy and Power management scope of RAN, the attribute could be “shareknowledge.” Such a feature could be very useful in future multi-vendor scenarios where IMs of different vendors need to cooperate to serve the network traffic.

[0148] FIG. 9 is a block diagram illustrating a profile 900 for an intent manager (IM) according to the TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0., with additional attributes according to some embodiments. Referring to FIG. 9, two new attributes 910 and 920 are added to the profile for an intent manager (IM) according to the TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0. One new attribute added 910 is referred to as “imoTntentKnowledgeShare.” A second new attribute added 920 is referred to as “imo : IntentKnowledgeLogicalGroupID . ”

[0149] With the addition of these two new attributes to the IM profile 900, the properties of the Intent Manager Capability Profile (IMCP) model, according to the TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0, may also be extended by adding an additional property 930, referred to as “canShareKnowledge” in FIG. 9. The IMCP model could be extended by adding:

[0150] As per TMForum standards (TM Forum Intent Manager Capability Profiles, IG1253D vl .0.0), the interface between IMs or IMs within the same peer-group with the same capabilities and operational layer has not been defined. FIG. 10 is a block diagram illustrating an architecture 1000 for intent manager registration and discovery according to the TM Forum Intent Manager Capability Profiles, IG1253D vl.0.0. Referring to FIG. 10, the Intent Handling interface 1010 has not been defined. Defining such an interface as described above, the novel methods disclosed herein can be used to perform intent management functions for autonomous networks. In the intent-based network paradigm, where knowledge-sharing is going to be critical to realizing Zero-Touch or Cognitive Telecommunications Networks, the intent handlinginterface 1110, which is not defined in TM Forum Intent Manager Capability Profiles, IG1253D vl .0.0, should be defined.

[0151] In some embodiments, an interface for sending and receiving information between intent managers from the plurality of intent managers provides for requesting knowledge sharing between intent managers and sharing knowledge artifacts and embeddings. In some embodiments, the interface for sending and receiving information between intent managers uses a resource description framework schema (RDFS).

[0152] FIG. 11 is a block diagram illustrating an exemplary resource description framework schema (RDFS) 1100 used for an intent handling interface between intent managers for automated handling of intents according to some embodiments. As shown in FIG. 11, for the content of the interface between intent managers to request knowledge sharing and share knowledge artifacts and embeddings, the resource description framework (RDF) format may be used, since most of the information stored and used as working knowledge and expression could be RDF -based.

[0153] Referring to FIG. 11, the model 1100 illustrated is based on the RDF / RDFS modelling family. For the format 1110, the content 1120 is sent as turtle 1112 or JSON 1114 / JSON-LD 1116. The content 1120 includes context signature 1122 and knowledge 1124. The exemplary resource description framework schema (RDFS) 1100 shown uses the general ontology of intent management, as well as the intent interface ontology.

[0154] FIG. 12 is a block diagram of an apparatus 1200, according to some embodiments. As shown in FIG. 12, the apparatus may comprise: processing circuitry (PC) 1202, which may include one or more processors (P) 1255 (e.g., a general purpose microprocessor and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a network interface 1248 comprising a transmitter (Tx) 1245 and a receiver (Rx) 1247 for enabling the apparatus to transmit data to and receive data from other computing devices connected to a network 1210 (e.g., an Internet Protocol (IP) network) to which network interface 1248 is connected; and a local storage unit (a.k.a., “data storage system”) 1208, which may include one or more nonvolatile storage devices and / or one or more volatile storage devices. In embodiments where PC1202 includes a programmable processor, a computer program product (CPP) 1241 may be provided. CPP 1241 includes a computer readable medium (CRM) 1242 storing a computer program (CP) 1243 comprising computer readable instructions (CRI) 1244. CRM 1242 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like.

[0155] In some embodiments, apparatus 1200 may comprise and / or perform the functions of an intent manager, such as a responding or first intent manager and / or a requesting or second intent manager. In some embodiments, the CRI 1244 of computer program 1243 is configured such that when executed by PC 1202, the CRI 1244 causes the apparatus 1200 to perform steps / functions described herein (e.g., steps / functions described herein with reference to FIGS. 1-11). In other embodiments, the apparatus 1200 may be configured to perform steps / functions described herein without the need for code. That is, for example, PC 1202 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0156] FIG. 13 illustrates 5G RAN (NG-RAN) architecture. The 5G RAN architecture is described in the Third Generation Partnership Project’s (“3GPP”) Technical Specification (“TS”) 38.401 v. 15.8.0. The NG-RAN 1302 consists of a set of gNBs (104A, 104B) connected to the 5GC (100) through the NG interface. As specified in 3GPP TS 38.300, v. 17.5.0, the NG-RAN 1302 could also consist of a set of ng-eNBs, which may consist of an ng-eNB-CU and one or more ng-eNB-DU(s). An ng-eNB-CU and an ng-eNB-DU is connected via W1 interface. A gNB can support FDD mode, TDD mode or dual mode operation. gNBs can be interconnected through the Xn interface.

[0157] A gNB 1304A, 1304B may consist of a gNB-CU 1306 and one or more gNB- DU(s) 1308A-B. A gNB-CU and a gNB-DU is connected via Fl interface. One gNB-DU is connected to only one gNB-CU. NG, Xn and Fl are logical interfaces. For NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs terminate in the gNB-CU. For EN-DC, the Sl-U and X2-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU. The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB.

[0158] As described above, n some embodiments, the responding or first intent manager and the second or requesting intent manager may perform intent management functions including for: a radio access network (RAN), such as, for a network with the 5G RAN (NG- RAN) architecture of FIG. 13. In some embodiments, the intent management functions include one or more of configuration management, configuration optimization, performance measurement, performance management, congestion control, slice orchestration, service level agreement (SLA) assurance, and energy efficiency.

[0159] Also, as described above, in addition to the responding or first intent manager and the requesting or second intent manager performing intent management functions for a radio access network (RAN), in some embodiments, the responding or first intent manager and the requesting or second intent manager may perform intent management functions for a core network and / or a transport network.

[0160] While various embodiments of the present disclosure are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the abovedescribed exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0161] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

[0162] Autonomous System: Autonomous system means systems which are not operating based on manual and static programmatic and rules- but based on automation, giving way to more model- and knowledge- driven approaches that are based on the business expressions, service, and resource requirements and constraints. By adopting those approaches, services can adapt and evolve more autonomously as network conditions, business goals and customer requirements shift over time.

[0163] Intent-Based Networks: Intent is the one of major driving force for autonomous networks (AN) in Telecommunication. Automation of networks and related operations evolve and mature to full closed- loop autonomy with intent and Intent-based management is baked into the autonomy journey.

[0164] Intent: An intent is a “formal specification of all expectations including requirements, goals and constraints given to a technical system”. Intents are knowledge objects with a lifecycle that is actively managed by intent management functions. The role of intent in autonomous networks is to communicate requirements, goals, constraints, and preferences to evaluate the state of the controlled infrastructure and the utility of actions.

[0165] Intent Management function: Intent management function is the entity that operates an autonomous system by using intent. It can assume the role of an intent owner or intent manager or both according to intent life-cycle management and interface as defined in TM Forum Intent Ontology (TIO), TR292 Version 3.1.0.

[0166] Intent handling function: The intent manager or intent handling function receives an intent object and operates the domain it is responsible for accordingly. Intent managers do not modify intent, but they can reject it. However, once accepted they are obliged to fulfill the requirements and goals as well as possible based on the resources and solutions it has available.

[0167] Knowledge: Knowledge in the context of Intent based autonomous system here refers to knowing the operational goals and requirements as specified by intent. Knowledge also encompass facts representing domain-knowledge (that may be useful to achieve the goals), issues, proposals ( generated to accomplish goals) and even agent themselves. Knowledge also means knowing the state of the system or domain for which an instance of the intent management function has the responsibility to operate.

[0168] Knowledge Management: Knowledge management (KM) is the process of identifying, organizing, storing, applying, sharing, and disseminating information. This same definition applies to management of Knowledge as well in Intent based autonomous networks context, but methodologies and tools required to manage the complexity of dynamism, cognition makes it a unique topic to address and bring in Innovation.

[0169] Abbreviations:

Claims

CLAIMS:

1. A computer-implemented method (500) for automated handling of intents in an intent-based network (IBN) including a plurality of intent managers, the method, executed by a first intent manager, comprising: generating (s502) a first set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts; receiving (s504), from a second intent manager, an intent context including a set of intents; encoding (s506) the received intent context to a second set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts; identifying (s508) from the second set of embeddings knowledge relevant to the received intent context; decoding (s510) the identified knowledge from the second set of embeddings; and sending (s512), to the second intent manager the decoded knowledge for use by the second intent manager for a proposal to fulfill the set of intents.

2. The computer-implemented method according to claim 1, wherein generating the first set of embeddings includes using one or more of: intent definitions; intent constraints; measured states; deviation from intent expectation; actions taken; and knowledge used for actions taken.

3. The computer-implemented method according to any one of claims 1 or 2, wherein the first set of embeddings generated represent co-occurrence and / or contextual- relevance associations between one or more of: co-occurring intents;issues observed for the received intent context; and knowledge artifacts relevant for handling the received intent context.

4. The computer-implemented method according to any one of claims 1-3, wherein generating the first set of embeddings includes training and / or learning the first set of embeddings.

5. The computer-implemented method according to claim 4, wherein the training and / or learning the first set of embeddings comprises using an artificial intelligence / machine learning (AI / ML) model.

6. The computer-implemented method according to claim 4, wherein the training and / or learning the first set of embeddings comprises using one or more of: centralized learning; distributed learning; and federated learning.

7. The computer-implemented method according to claim 4, wherein the training and / or learning the first set of embeddings comprises using one or more of: a pre-trained word-embedding model with or without additional domain-specific finetuning; and a self-trained word-embedding model starting from a word-encoding.

8. The computer-implemented method according to any one of claims 1-3, wherein the first set of embeddings generated include domain-specific embeddings of knowledge artifacts that learn contextual associations between intents and knowledge artifacts relevant to the intents.

9. The computer-implemented method according to claim 1, further comprising:determining that the decoded knowledge is not relevant to the received intent context or will not be used.

10. The computer-implemented method according to claim 9, further comprising one or more of: storing the irrelevant or un-used knowledge; archiving the irrelevant or un-used knowledge; deleting the irrelevant or un-used knowledge; and processing the irrelevant or un-used knowledge based on an intended use.

11. The computer-implemented method according to claim 1, wherein each intent manager in the plurality of intent managers has a profile signature with a plurality of attributes, and the plurality of attributes includes one or more of: an attribute specifying a scope of knowledge sharing and / or requesting allowed for the intent manager; and a unique logical group identification (ID).

12. The computer-implemented method according to claim 1, further comprising: identifying a grouping of intent managers from the plurality of intent managers that the first intent manager is associated with.

13. The computer-implemented method according to claim 1, wherein an interface for sending and receiving information between intent managers from the plurality of intent managers provides for requesting knowledge sharing between intent managers and sharing knowledge artifacts and embeddings.

14. The computer-implemented method according to claim 13, wherein the interface for sending and receiving information between intent managers uses a resource description framework schema (RDFS).

15. The computer-implemented method according to claim 1, wherein the first intent manager and the second intent manager perform intent management functions including for one or more of a radio access network (RAN); a core network; and a transport network.

16. The computer-implemented method according to claim 15, wherein the intent management functions include one or more of configuration management, configuration optimization, performance measurement, performance management, congestion control, slice orchestration, service level agreement (SLA) assurance, and energy efficiency.

17. The computer-implemented method according to claim 1, wherein the first intent manager and the second intent manager each have a manager capability profile with similar scope of responsibilities.

18. The computer-implemented method according to claim 1, wherein the first intent manager and the second intent manager each have a manager capability profile with different geographical distribution or with different business contexts.

19. The computer-implemented method according to claim 1, wherein the received intent context includes, in the set of intents, at least a first intent, and wherein the decoded knowledge sent to the second intent manager includes knowledge relevant to at least the first intent and a second intent.

20. The computer-implemented method according to claim 19, wherein the first intent is to resolve network congestion and the second intent is to maintain energy efficiency.

21. A computer-implemented method (600) for automated handling of intents in anintent-based network (IBN) including a plurality of intent managers, the method, executed by a second intent manager, comprising: identifying (s602) an intent context including a set of intents; sending (s604), to a first intent manager, the identified intent context; receiving(s606), from the first intent manager, knowledge relevant to the identified intent context; encoding (s608) the received knowledge to generate a set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts; identifying (s610) from the set of embeddings knowledge relevant to the identified intent context; decoding (s612) the identified knowledge from the set of embeddings; adding (s614) the decoded knowledge to a knowledge base; and using (s616) the decoded knowledge for a proposal to fulfill one or more of the intents in the set of intents.

22. The computer-implemented method according to claim 21, wherein generating the set of embeddings includes using one or more of: intent definitions; intent constraints; measured states; deviation from intent expectation; actions taken; and knowledge used for actions taken.

23. The computer-implemented method according to any one of claims 21 or 22, wherein the set of embeddings generated represent co-occurrence and / or contextual -relevance associations between one or more of: co-occurring intents; issues observed for the identified intent context; andknowledge artifacts relevant for handling the identified intent context.

24. The computer-implemented method according to any one of claims 21-23, wherein generating the set of embeddings includes training and / or learning the set of embeddings.

25. The computer-implemented method according to claim 24, wherein the training and / or learning the set of embeddings comprises using an artificial intelligence / machine learning (AI / ML) model.

26. The computer-implemented method according to claim 24, wherein the training and / or learning the set of embeddings comprises using one or more of: centralized learning; distributed learning; and federated learning.

27. The computer-implemented method according to claim 24, wherein the training and / or learning the set of embeddings comprises using one or more of: a pre-trained word-embedding model with or without additional domain-specific finetuning; and a self-trained word-embedding model starting from a word-encoding.

28. The computer-implemented method according to any one of claims 21-23, wherein the set of embeddings generated include domain-specific embeddings of knowledge artifacts that learn contextual associations between intents and knowledge artifacts relevant to the intents.

29. The computer-implemented method according to claim 21, further comprising:determining that the decoded knowledge is not relevant to the identified intent context or will not be used.

30. The computer-implemented method according to claim 29, further comprising one or more of storing the irrelevant or un-used knowledge; archiving the irrelevant or un-used knowledge; deleting the irrelevant or un-used knowledge; and processing the irrelevant or un-used knowledge based on an intended use.

31. The computer-implemented method according to claim 21, wherein each intent manager in the plurality of intent managers has a profile signature with a plurality of attributes, and the plurality of attributes includes one or more of an attribute specifying a scope of knowledge sharing and / or requesting allowed for the intent manager; and a unique logical group identification (ID).

32. The computer-implemented method according to claim 21, further comprising: identifying a grouping of intent managers from the plurality of intent managers that the second intent manager is associated with.

33. The computer-implemented method according to claim 21, wherein an interface for sending and receiving information between intent managers from the plurality of intent managers provides for requesting knowledge sharing between intent managers and sharing knowledge artifacts and embeddings.

34. The computer-implemented method according to claim 32, wherein the interface for sending and receiving information between intent managers uses a resource description framework schema (RDFS).

35. The computer-implemented method according to claim 21, wherein the first intent manager and the second intent manager perform intent management functions including for one or more of a radio access network (RAN); a core network; and a transport network.

36. The computer-implemented method according to claim 35, wherein the intent management functions include one or more of configuration management, configuration optimization, performance measurement, performance management, congestion control, slice orchestration, service level agreement (SLA) assurance, and energy efficiency.

37. The computer-implemented method according to claim 21, wherein the first intent manager and the second intent manager each have a manager capability profile with similar scope of responsibilities.

38. The computer-implemented method according to claim 21, wherein the first intent manager and the second intent manager each have a manager capability profile with different geographical distribution or with different business contexts.

39. The computer-implemented method according to claim 21, wherein the identified intent context includes, in the set of intents, at least a first intent, and wherein the decoded knowledge received from the first intent manager includes knowledge relevant to at least the first intent and a second intent.

40. The computer-implemented method according to claim 39, wherein the first intent is to resolve network congestion and the second intent is to maintain energy efficiency.

41. A first intent manager (1200) comprising: processing circuitry (1202); and a memory (1208) containing instructions (1244) executable by the processing circuitry for automated handling of intents in an intent-based network (IBN)including a plurality of intent managers, the first intent manager operative to: generate a first set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts; receive, from a second intent manager, a current intent context including a set of intents; encode the received current intent context to a second set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts; identify from the second set of embeddings knowledge relevant to the current intent context; decode the identified knowledge from the second set of embeddings; and send, to the second intent manager the decoded knowledge for use by the second intent manager for a proposal to fulfill the set of intents.

42. A second intent manager (1200) comprising: processing circuitry (1202); and a memory (1208) containing instructions (1244) executable by the processing circuitry for automated handling of intents in an intent-based network (IBN) including a plurality of intent managers, the second intent manager operative to: identify an intent context including a set of intents; send, to a first intent manager, the identified intent context; receive, from the first intent manager, knowledge relevant to the identified intent context; encode the received knowledge to generate a set of embeddings representing relationships between one or more of intents, issues, contexts, proposals and / or knowledge artifacts; identify from the set of embeddings knowledge relevant to the identified intent context; decode the identified knowledge from the set of embeddings;add the decoded knowledge to a knowledge base; and using the decoded knowledge for a proposal to fulfill one or more of the intents in the set of intents.

43. An intent manager (1200) in an intent-based network (IBN) for automated handling of intents, the intent manager comprising: one or more memories (1208) comprising instruction data (1244) representing a set of instructions; and one or more processors (1255) configured to communicate with the one or more memories (1208) and to execute the set of instructions, wherein the set of instructions, when executed by the processor, cause the one or more processors to perform the methods of any one of claims 1- 40.

44. A computer program (1243) comprising instructions (1244) which, when executed by processing circuitry (1202), causes the processing circuitry to carry out the methods of any one of claims 1-40.

45. A carrier containing a computer program (1243) according to claim 44, wherein the carrier comprises one of an electronic signals, optical signal, radio signal or computer readable storage medium.

46. A computer program product (1241) comprising a non-transitory computer readable medium (1242) having stored thereon a computer program (1243) according to claim 44.

47. An apparatus (1200), the apparatus comprising: a memory (1208); and processing circuitry (1202) coupled to the memory, wherein the apparatus is configured to perform the methods of any one of claims 1-40.

Images