Methods and components for assigning intent management tasks to a different handler

Abstract

A first intent management function (IMF) may receive, from an intent owner, an intent indicating at least one escalation expectation. The escalation expectation may define at least one escalation condition that triggers the first IMF to assign the intent management task to the intent owner or a second IMF. The first IMF may determine if the at least one escalation condition is met. Responsive to determining that the at least one escalation condition is met, the first IMF may assign the intent management task to the intent owner or the second IMF.

Description

METHODS AND COMPONENTS FOR ASSIGNING INTENT MANAGEMENT TASKS TO A DIFFERENT HANDLERTECHNICAL FIELD

[0001] The present disclosure relates to assigning intent management tasks in a telecommunication network.BACKGROUND

[0002] In a telecommunication network, an intent manager or intent management function (IMF) provides a zero-touch control to fulfill one or more intents regarding a network environment. Presently, the intents are defined according to a standardized intent model. An intent owner, such as a human being or an IMF, provides the intents to an intent handler, e.g., another IMF. The intent handler controls the environment by observing the environment, performing reasoning based on perceived situation and prior knowledge, and taking autonomous intent-driven operations on the environment.

[0003] The journey toward zero-touch networks is gradual. During the transition from manual operations to fully autonomous operations, human involvement is often needed to enhance trust in autonomous, intent-driven actions and enhance capabilities of the IMFs. When automating intents’ resolution, it is desirable for the IMFs to be instructed on a desired level of human involvement in handling certain tasks. Presently, no known technical solution addresses this need.SUMMARY

[0004] The present disclosure tackles the problem of how to specify requirements for an IMF to assign an automation task to an intent owner or another IMF. To solve this problem, the present disclosure extends the standardized intent model to allow specifying escalation expectations. Escalation expectations target certain conditions upon which the IMF asksanother entity, such as the intent owner or another IMF, to participate or intervene in intent management operations.

[0005] According to one aspect of the disclosure, a method may be performed by a first IMF to assign an intent management task. The first IMF may receive, from an intent owner, an intent indicating at least one escalation expectation. The escalation expectation may define at least one escalation condition that triggers the first IMF to assign the intent management task to the intent owner or a second IMF. The first IMF may determine if the at least one escalation condition is met. Responsive to determining that the at least one escalation condition is met, the first IMF may assign the intent management task to the intent owner or the second IMF.

[0006] In some embodiments, the at least one escalation condition may indicate one or more of the following: at least one of an execution context, an action name, and an action type, each of which may be associated with at least one action; a minimum accuracy level of a prediction made by the first IMF; a problem in the first IMF; one or more expectations associated with at least a part of a network managed by the first IMF; any impact on at least one other intent or at least one other intent owner; and a minimum fitness score indicating utility improvement of the first IMF.

[0007] In some embodiments, the execution context may be one of proposing the at least one action, predicting the at least one action, evaluating the at least one action, and executing the at least one action.

[0008] In some embodiments, the at least one escalation condition may indicate the minimum accuracy level of the prediction made by the first IMF. To determine if the at least one escalation condition is met, the first IMF may determine whether the prediction made by the first IMF is less than the minimum accuracy level.

[0009] In some embodiments, the at least one escalation condition may indicate the problem in the first IMF. To determine if the at least one escalation condition is met, the first IMF may determine whether the problem has occurred.

[0010] In some embodiments, the at least one escalation condition may indicate any impact on the at least one other intent or the at least one other intent owner. To determine if the at least one escalation condition is met, the first IMF may determine whether the intent management task impacts the at least one other intent or the at least one other intent owner.

[0011] In some embodiments, the at least one escalation condition may indicate the minimum fitness score. To determine if the at least one escalation condition is met, the first IMF may determine whether the intent management task improves utility of the first IMF to an extent that is less than the minimum fitness score.

[0012] In some embodiments, the at least one escalation condition may indicate the minimum fitness score over a time frame. To determine if the at least one escalation condition is met, the first IMF may determine whether the intent management task improves utility of the first IMF to an extent that is less than the minimum fitness score over the time frame.

[0013] In some embodiments, the one or more expectations may be associated with a physical or virtual resource of the network or a service using or running on the network.

[0014] In some embodiments, the at least one escalation condition may be a domain specific escalation condition.

[0015] In some embodiments, the domain specific escalation condition may include at least one of the following: a Radio Access Network condition, a Core Network condition, a Transport condition, and a Cloud Computing condition.

[0016] In some embodiments, the escalation expectation may include an indication that indicates a need for propagating the escalation expectation to the second IMF.

[0017] In some embodiments, assigning the intent management task may include: freezing execution of the intent management task to an extent that requires assignment; sending, to the intent owner, an escalation report requesting an input regarding the intent management task; and resuming execution of the intent management task after receiving the input from the intent owner.

[0018] In some embodiments, assigning the intent management task may include: freezing execution of the intent management task to an extent that requires assignment; sending, to the second IMF, an escalation report requesting the second IMF to take control over the intent management task; sending, to the intent owner, a report indicating that the second IMF has taken control over the intent management task; receiving, from the second IMF, a signal suggesting the first IMF to take control over the intent management task; and resuming execution of the intent management task.

[0019] In some embodiments, the escalation expectation may include information that identifies the second IMF.

[0020] In some embodiments, the first IMF may select, from a plurality of IMFs, the second IMF based on its capability profile for handling assignment.

[0021] In some embodiments, a node in a communications network may comprise processing circuitry configured to perform the above method. The node may include the first IMF.

[0022] According to another aspect of the disclosure, a method may be performed by a first IMF to assign an intent management task. The first IMF may receive, from an intent owner, at least one expectation associated with at least a part of a network managed by the first IMF. The at least one expectation may be achievable through execution of the intent management task by the first IMF. The first IMF may receive, from the intent owner, an intent indicating at least one escalation expectation. The escalation expectation may define at least one escalation condition that triggers the first IMF to assign the intent management task to a second IMF. Thefirst IMF may determine if the at least one escalation condition is met. Responsive to determining that the at least one escalation condition is met, the first IMF may assign the intent management task to the second IMF for execution by the second IMF to achieve the at least one expectation . The first IMF may send, to the intent owner, a report indicating assignment associated with the at least one expectation.

[0023] In some embodiments, the escalation expectation may include information that identifies the second IMF.

[0024] In some embodiments, the first IMF may select, from a plurality of IMFs, the second IMF based on its capability profile for handling assignment.

[0025] In some embodiments, the intent management task may be executable on the network or on at least one other IMF to achieve the at least one expectation.

[0026] In some embodiments, the at least one expectation may be included in the intent or another intent received from the intent owner.

[0027] In some embodiments, a node in a communications network may comprise processing circuitry configured to perform the above method. The node may include the first IMF.

[0028] Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The above and other objects, features and advantages will be more apparent from the following description of embodiments with reference to the accompanied drawings.

[0030] FIG. 1 illustrates example components of a communications network relevant to one aspect of the technology.

[0031] FIG. 2 illustrates example autonomous operations via intent interfaces according to one aspect of the technology.

[0032] FIG. 3 illustrates autonomous network operations based on intent handling according to one aspect of the technology.

[0033] FIG. 4 illustrates a sequence diagram showing propagation of an escalation expectation within the hierarchy of IMF's according to one aspect of the technology.

[0034] FIG. 5 illustrates a sequence diagram showing example escalation expectations submitted to different IMFs according to one aspect of the technology.

[0035] FIG. 6 illustrates a sequence diagram showing an example escalation to the intent owner according to one aspect of the technology.

[0036] FIG. 7 illustrates a sequence diagram showing an example escalation to an escalation handler according to one aspect of the technology.

[0037] FIG. 8 illustrates a sequence diagram showing an example assignment to an escalation handler according to one aspect of the technology.

[0038] FIG. 9 illustrates a flow chart of a method performed by an IMF to assign an intent management task according to one aspect of the technology.

[0039] FIG. 10 illustrates another flow chart of a method performed by an IMF to assign an intent management task according to one aspect of the technology.

[0040] FIG. 11 illustrates an example architecture of an Open Radio Area Network according to one aspect of the technology

[0041] FIG. 12 is a block diagram showing internal components of an IMF according to one aspect of the technology.DETAILED DESCRIPTION

[0042] Notably, modifications and other embodiments of the disclosed invention(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invcntion(s) is / are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.1. Overview

[0043] FIG. 1 illustrates a communications network relevant to the present disclosure, showing an intent owner 102 and one or more IMFs 104.

[0044] The intent owner may be a network operator, such as a human operator who operates via a portal. The intent owner may also be another IMF. The intent owner 102 may submit one or more intents 105 to the IMF 104. The intent 105 may represent a formal specification of one or more expectations, such as requirements, goals, and constraints, given to a technical system. Intents may represent the formal specification of expectations of physical or virtual resources of the network or services using or running on the network. Example expectations may include: at least 95% of Ultra Reliable Low Latency Communications (URLLC) users shall experience a latency of maximum 20 msec; at least 80% of the users of the conversational video service shall have a minimum Quality of Experience (QoE) of 4.0; and energy consumption of the system shall be kept to a minimum.

[0045] The IMF 104 may be an intent manager responsible for handling the intent 105. The IMF 104 may be referred to as an intent handler. The IMF 104 may perform an automation task that handles the intent 105. The automation task may be referred to as an intent managementtask, which may include one or more actions executable to achieve an expectation intended by the intent owner. The intent management task may include prediction of actions and actuation of actions, among other possibilities.

[0046] The intent management task may be executable on the environment or on at least one other IMF to achieve the expectation.

[0047] The IMF 104 may include a knowledge base 108 configured to store knowledge objects. The IMF 104 may further include a plurality of agents such as one or more data grounding agents 110, proposal agents 112, evaluation agents 114 and actuator agents 116.

[0048] The IMF 104 may provide a zero-touch control for the environment 106 based on the intent 105 provided by the intent owner 102. The IMF 104 may translate each expectation in the intent 105 to a target Key Performance Indicator (KPI) that needs to be met. Data grounding agents 110 may process raw data 118 exposed from the environment 106, and translate the raw data 118 into measured KPIs. The IMF 104 may compare target and measured KPIs, and determine a difference. For example, the target KPI may be “max 20 msec latency,” but the measured KPI may be “30 msec latency.” Minimizing the difference may be a goal that the IMF 104 needs to meet. One or more proposal agents 112 may propose one or more actions 120 to achieve the goal. Evaluation agents 114 may assess whether each proposed action is good or not. Finally, actuator agents 116 may execute the action(s) 120 on the environment 106 under control. Each IMF may have a capability profile, which describes actions that the IMF may take and intents that may be possibly handled by the IMF. The capability profile of each IMF may be queried by other IMFs or intent owners.

[0049] The environment 106 may refer to a network or a network core, such as 5G Core. The network may include multiple domains. The environment 106 may refer to the network in its entirety, or a domain within the network. For instance, in the case of a mobile network, theenvironment 106 may refer to the mobile network or a domain within the mobile network.Alternatively, the environment 106 may refer to another IMF.

[0050] In one embodiment, the intent owner 102 may send a first, original intent to the IMF 104 indicating an expectation. The intent owner 102 may send a second intent to the IMF 104 that indicates an escalation expectation.

[0051] In another embodiment, both the expectation and the escalation expectation may be sent to the IMF via the same intent. The intent may be a container for one or more expectations and / or escalation expectations.

[0052] The escalation expectation may express a level of autonomy that the intent owner 102 allows for the IMF 104 in handling the expectation. The escalation expectation may be provided by the intent owner 102 in the form of an intent. The intent owner may use the escalation expectation to enable the IMF to assign an intent management task for handling the expectation to another entity. The other entity may be the intent owner 102 or another IMF. The intent owner may use the escalation expectation to manually approve certain actions of the intent management task, if the intent owner wants to be involved in the approval of certain configuration / re-configuration operations. By submitting the escalation expectation, the intent owner may be unaware of the internal process of the IMF.2. Hierarchical Escalation

[0053] FIG. 2 illustrates an example hierarchical escalation, showing intent interfaces that may be affected by an escalation expectation. The intent owner 102, such as a human operator, may specify an escalation expectation via any one of the following portals: an operations portal 202, a business portal 204, a customer portal 206 and an order management portal 208. The escalation expectation may be mediated via an intent interpreter 212, if necessary. The intent interpreter 212 may facilitate communications between domain specific intent languages andinterfaces 210 and autonomous network operations 214. The autonomous network operations 214 may include business operations 216, service operations 218 and resource operations 220.

[0054] After the intent owner submits the escalation expectations via a portal, the escalation expectation may reach an IMF, such as a business intent manager 222 or a service intent manager 224. The business intent manager 222 may communicate with intent interpreters 212 and contract and order management 225. After the IMF receives the escalation expectation, the IMF may derive the escalation expectation, and / or submit the escalation expectation to one or more lower-level IMFs, such as intent managers 226, ADI Intent Manager 228a, AD2 Intent Manager 228b or ADn Intent Manager 228c, to notify them that the original intent is operating under the escalation expectation. The derivation performed by the IMF may be referred to as decomposition or refinement.

[0055] FIG. 3 illustrates an example hierarchy of intent management. Various instances of IMFs, e.g., business support system (BSS) 302 and operation support system (OSS) 304, may be allocated across operational layers and autonomous domains. The intent may originate directly from an input submitted by the intent owner via any of the following portals: operations portal 202, business portal 204 and customer portal 206. Alternatively, the intent may be derived automatically by the IMF and managed via an intent application programming interface (API). Intent APIs are represented by arrows in FIG. 3. In FIG. 3, the business operations 216 may include business portal 204, customer portal 206, BSS 302 and contract and order management 225. The service operations 218 may include operations portal 202, OSS 304, analytics 306, orchestration 308 and assurance 310. The resource operations 220 may include self-organizing network 312, other intent handlers 314 such as other IMFs, and network manager 316.3. Escalation Expectation General Structure

[0056] Escalation expectations may be submitted via an intent interface. For example, one or more escalation expectations may be grouped in the form of an intent and submitted via an intent API. The code snippet below shows two example escalation expectations submitted via the intent API. The escalation expectations provided below are for illustration purposes only. The escalation expectations may or may not be submitted via the intent API, depending on detailed implementations. ope : Autonomy Intent a imm: Intent ; rdfs:comment ’’intent for specifying the level of autonomy”; imm:hasExpectation [ a imm:EscalationExpectation ; rdfs:comment ’’This is a first escalation expectation”;]• imrmhasExpectation [ a imm:EscalationExpectation ; rdfs:comment ’’This is a second escalation expectation”;]•

[0057] Also, the prefixes, e.g., ope and imm, provided in the above code snippet and other code snippets discussed below, are presented for illustration purposes only. The prefixes may vary depending on detailed implementations.4. Escalation Expectation vs. Reporting Expectation

[0058] The escalation expectation may be different from a reporting expectation in the standardized intent model. The reporting expectation in the standardized intent model may merely specify conditions for certain notifications, e.g., reports. On the other hand, the escalation expectation may lock the IMF in a state while waiting for an input from another entity (e.g., stopping execution of the IMF before action approval by another entity). From animplementation perspective, the escalation expectation may extend the reporting expectation, and may inherit all fields and capabilities already available in the standardized intent model.5. Example Escalation Conditions

[0059] The escalation expectation may specify a predefined level of escalation to trigger the IMF to assign the intent management task. The predefined level may be generic and nonflexible.

[0060] In addition or alternatively, the escalation expectation may define one or more conditions to trigger the IMF to perform assignment. These conditions may be referred to as escalation conditions. The escalation conditions may specify operational constraints of the IMF in performing the intent management task. The escalation condition(s) may indicate one or more of the following: at least one of an execution context, an action name, and an action type, each of which is associated with at least one action; a minimum accuracy level of a prediction made by the IMF; a problem in the IMF; one or more expectations associated with at least a part of the network managed by the IMF; any impact on at least one other intent or at least one other intent owner; and a minimum fitness score indicating utility improvement of the IMF. Each escalation condition is discussed in further detail below.5.1 Action-based Escalation

[0061] In one example, the escalation condition may indicate at least one of an execution context, an action name, and an action type, each of which may be associated with at least one action. The execution context may include one of the following: proposing the action, predicting the action, evaluating the action, and executing the action.

[0062] Example action names may include “MoveUEAction,” “ChangeMBRAction,” “ScalcServcrAction," “ConnectUEAction” and “DeployServerAction”, among otherpossibilities. The action name may be discoverable in the capability profile of the IMF by the intent owner. By specifying an action name in the escalation condition, the intent owner may perform escalation based on the specific action name, and prevent autonomous operations of any action under that action name. For example, the intent owner may not want to allow autonomous operations for ScaleServerAction, because of monetary or trust concerns.

[0063] Example action types may include “TopologyChange,” “ConfigurationChangeAction,” and the generic “Action,” among other possibilities. When the generic “Action” is used as the action type, the escalation is for every action. The action type may be discoverable in the capability profile of the IMF by the intent owner. By specifying an action type in the escalation condition, the intent owner may perform escalation based on the specific action type, and prevent autonomous operations of any action of that action type. For example, the owner may not want to allow autonomous operations for TopologyChangeActions, because of regulatory or trust concerns.

[0064] The code snippet below provides an example escalation expectation submitted by the intent owner. In this example, every execution of “MoveUEAction” and every action that is of type “TopologyChange” may be escalated or assigned to the intent owner or another IMF for approval or intervention. ope : Autonomy Intent a imm: Intent ; rdfs:comment ’’intent for specifying the level of autonomy”; imm:hasExpectation[ a imm:EscalationExpectation ; imrmtarget imm:Execution ; imrmparams [ zt:Action zt:MoveUEAction;Zt:ActionType zt:TopologyChange]]•5.2 Accuracy-based Escalation

[0065] The IMF may make an internal prediction regarding certain actions, to indicate the impact of those actions on all the intents in the system. Usually, predictions made by the IMF may not be 100% accurate. Predictions with a lower accuracy may indicate a risk of fillfilling the same or other intents. If the prediction is not accurate, it may disrupt the intent management procedure.

[0066] In one example, the escalation condition may indicate a minimum accuracy level of a prediction made by the IMF. To determine if the escalation condition is met, the IMF may determine whether the prediction made by the IMF is less than the minimum accuracy level. The intent owner may use the minimum accuracy level to specify a risk-based or accuracybased escalation strategy. In one example, the intent owner may indicate that the actions with 99.9% prediction accuracy may be executed autonomously without any need for escalation.

[0067] Accuracy-based escalation may be used in conjunction with action-based escalation. The escalation condition that indicates the minimum accuracy level may further identify an action for which the escalation should apply.

[0068] The code snippet below provides an example escalation expectation in this regard. The intent owner may use a minimum accuracy level to indicate that execution of actions that are based on predictions with less than x% accuracy needs approval or intervention. ope: Autonomyintent a imm: Intent ; rdfs:comment ’’intent for specifying the level of autonomy”; imnrhasExpectation[ a imm:EscalationExpectation ; imm:target imm:Execution ; imm:params [ imm:minAccuracy imm:x;]]•5.3 Problem-based Escalation

[0069] The intent owner may require escalation for certain problems that are present in the IMF, such as problems fulfilling expectation xyz. In this regard, the escalation condition for triggering assignment may indicate one or more problems in the IMF. To determine if the escalation condition is met, the IMF may determine whether the problems have occurred.

[0070] Problem-based escalation may be used in conjunction with one or more specific intents or specific expectations associated with at least a part of the network managed by the IMF. For example, when the escalation condition indicates the problem in the IMF for triggering assignment, the escalation condition may refer to a specific intent or expectation. In the IMF, one or more components may be responsible for autonomously proposing actions that may solve problems with a specific intent. By specifying an escalation requirement for a specific intent, the intent owner may be involved in the resolution process and may manually add certain action proposals after the IMF performs the escalation.

[0071] The code snippet below provides an example escalation expectation in this regard. In the code snippet below, all problems that are associated with the intent expectation urllc-intent- expectation-1 may require intervention by the intent owner or another IMF. ope : Autonomy Intent a imm: Intent ; rdfs:comment ’’intent for specifying the level of autonomy”; imm:hasExpectation[ a imm:EscalationExpectation ; imm:target imm:Proposal ; imm:params [ imm:issue [ cc: expectation ne:urllc-intent-expectation- 1]]•5.4 Impact-based Escalation

[0072] During autonomous operations, some autonomous actions may not negatively impactother intents. Other actions may improve one intent by penalizing one or more other intents. Involvement of the intent owner or intervention by another IMF may be required for actions that pose negative impacts on other intents.

[0073] In one example, the escalation condition for triggering assignment may indicate any impact on at least one other intent or at least one other intent owner. To determine if the escalation condition is met, the IMF may determine whether the intent management task impacts any other intent or any other intent owner.

[0074] The code snippet below provides an example escalation expectation in this regard. The predicate “ope:impact” may point to one or more intents (or expectations). Alternatively, the predicate “ope:impact” may point to one or more intent owners from which one or more intents may be derived by the IMF, as the IMF may know the intent(s) of each intent owner. In the code snippet below, GoldCustomer may refer to an intent owner. The IMF may derive intents of GoldCustomer. Every time an action that is marked to be executed impacts a GoldCustomer, an escalation may be performed. The predicate “ope:impact” may indicate one or more specific intents (or expectations) in the IMF. By using the predicate “ope:impact,” every action that impacts the indicated intent (or the indicated expectation) or the indicated intent owner may be escalated or assigned to the intent owner or to another IMF for approval or intervention. ope : Autonomy Intent a imm: Intent ; rdfs:comment ’’intent for specifying the level of autonomy”; imm:hasExpectation[ a imm:EscalationExpectation ; imrmtarget imm:Execution ; imrmparams [ ope:impact zt: GoldCustomer;]]•

[0075] The code snippet below provides another example escalation expectation, in which assignment to the intent owner or another IMF may be triggered when the fulfdlment of a certain expectation, e.g., urrlc-intent-expectation-1, is predicted to be violated. ope : Autonomy Intent a imm: Intent ; rdfs:comment ’’intent for specifying the level of autonomy”; imm:hasExpectation[ a imm:EscalationExpectation ; imrmtarget imm:Execution ; imrmparams [ cc:impact ne:urllc-intent-expectation-l]]•5.5 Minimum Fitness Score

[0076] Each action proposed by the proposal agent 112 may have a fitness score, which may be used as a metric by the evaluation agent 114 for approving or rejecting proposed actions. Actions that improve utility of the IMF or decrease penalty of the IMF may be autonomously approved.

[0077] In one example, the escalation condition for triggering assignment may indicate a minimum fitness score that indicates utility improvement of the IMF. To determine if the escalation condition is met, the IMF may determine whether the intent management task improves utility of the IMF to an extent that is less than the minimum fitness score.

[0078] By using the minimum fitness score as the escalation condition for triggering assignment, the intent owner may restrict autonomous executions of actions that only partially improve the utility of the IMF or only partially decrease penalty of the IMF. The code snippet below illustrates an example escalation expectation in this regard. In the code snippet below, actions that improve the utility by less than 2% may be escalated or assigned to the intent owner or another IMF for approval or intervention.ope:AutonomyIntent a imm: Intent ; rdfs:comment ’’intent for specifying the level of autonomy”; imnrhasExpectation[ a imm:EscalationExpectation ; imm:target imm:Execution ; imnrparams [ opc:utility [ imm:delta ope:0.02]]]•

[0079] With respect to delta improvements, the IMF may move through a series of small actions. Each action may improve the utility of the IMF by a small percentage. In this case, the escalation expectation may include a timing aspect, e.g., escalate for actions that do not improve the utility by delta over a certain time “t”. In this regard, the escalation condition for triggering assignment may indicate the minimum fitness score over a time frame. To determine if the escalation condition is met, the IMF may determine whether the intent management task improves utility of the IMF to an extent that is less than the minimum fitness score over the time frame.

[0080] In one embodiment, the escalation expectation may include a series of planned actions instead of a single action. By doing so, the IMF may communicate to the intent owner that certain actions are part of an overall strategy. This more advanced way of reporting plans (e.g., a series of planned actions), instead of single actions, may apply to all types of escalation expectations described above. For example, for an action that impacts other intents, the IMF may report that the impact is transitory for that action and a subsequent planned action is planned to clear the impact and bring the system back on track.6. Escalation Flow6.1 Escalation Expectation Submission

[0081] In one example, the escalation expectation may have an optional field, such as an indication, that indicates a need for propagating the escalation expectation to another IMF. Once the intent owner submits the escalation expectation, the escalation expectation may move along the hierarchy of IMFs. For example, the escalation expectation may move along the hierarchy of the IMFs, when the escalation condition is domain agnostic (e.g., conflicting actions).

[0082] FIG. 4 illustrates an escalation expectation that propagates within the hierarchy of the IMFs. At step 402, the intent owner 102 may submit an escalation expectation to the first IMF 104a. At step 404, the first IMF 104a may propagate the same escalation expectation to the second IMF 104b. At step 406, the second IMF 104b may propagate the same escalation expectation to the third IMF 104c.

[0083] In another example, as illustrated in FIG. 5, the intent owner 102 may submit separate escalation expectations to different IMFs, as different IMFs may be required to escalate on conditions that are domain-specific. Example domain specific condition may include one or more of the following: Radio Access Network (RAN) condition, Core Network condition, Transport condition, and Cloud Computing condition. At 502, the intent owner 102 may submit a first escalation expectation to the first IMF 104a. At 504, the intent owner 102 may submit a second escalation expectation to the second IMF 104b. At 506, the intent owner 102 may submit a third escalation expectation to the third IMF 104c. The first, second and third escalation expectations may be different from one another.6.2 Escalation to Intent Owner

[0084] In one embodiment, as illustrated in FIG. 6, the IMF 104 may perform escalation to the intent owner 102. At step 602, the IMF 104 may receive an escalation expectation from the intent owner 102. At step 604, the IMF 104 may identify the escalation condition, and determine if the escalation condition is met. At 606, if the escalation condition is met, the IMF 104a may freeze execution of the intent management task to an extent that requires assignment (z.e., lock on escalation condition). Alternatively, at step 606, the intent owner may be informed by the IMF 104, and the intent owner may reply to the IMF 104 and ask the IMF 104 to freeze execution of the intent management task to the extent that requires assignment. The IMF 104 may not lock its full operations, but only the ones that require intent owner intervention (e.g., a specific action approval). At step 608, the IMF may send an escalation report to the intent owner. The escalation report may request an input from the intent owner regarding the intent management task. At step 610, the intent owner may set the required input (e.g., action approval). At step 612, the IMF may resume its execution of the intent management task after receiving the input from the intent owner.6.3 Escalation to Escalation Handler

[0085] In another embodiment, as illustrated in FIG. 7, a first IMF 104a may perform escalation to an escalation handler. The escalation handler may be a separate handler, such as a second IMF 104b. Once escalated, the escalation report and handling of the intent management task may be taken over by the second IMF 104b.

[0086] At step 702, the first IMF 104a may receive an escalation expectation from the intent owner 102. The escalation expectation may include information or a reference that identifies the second IMF 104b. At step 704, the first IMF 104a may identify the escalation condition, and determine if the escalation condition is met. At 706, once the escalation condition is met,the first IMF 104a may freeze execution of the intent management task to an extent that requires assignment (z.e., lock on escalation condition). Alternatively, the second IMF 104 may be informed by the first IMF 104a, and the second IMF may reply to the first IMF 104 and ask the first IMF 104a to freeze all actions related to the escalation condition (e.g., all actions associated with the intent of the intent owner) to an extent that requires assignment.

[0087] To select the second IMF 104b, the first IMF 104a may determine whether the escalation expectation received from the intent owner 102 identifies the second IMF. Alternatively, the first IMF 104 may select the second IMF 104b from a plurality of IMFs. The first IMF 104 may access capability profiles of the IMFs to select the right IMF that can handle the intent management task. The capability profile of each IMF may include the capability of handling different types of escalation.

[0088] At 708, the first IMF may send an escalation report to the second IMF, requesting the second IMF to take control over the intent management task. In one example, the escalation report may request an input from the second IMF.

[0089] At 710, the first IMF may send a report to the intent owner, indicating that the second IMF has taken control over the intent management task. At step 712, the second IMF may take control over the intent management task. In one example, the second IMF may set an input, and send the input to the first IMF. In another example, the second IMF may tell the first IMF what action(s) the first IMF is supposed to execute. In yet another example, if the escalation relates to an action execution condition, the second IMF may perform the action(s) directly with the network and resources.

[0090] At step 714, once the second IMF has finished its interference, the first IMF may take over again. The second IMF may directly inform the first IMF to take over again with a message. For example, after acting on the network resources, the second IMF may send a signal to thefirst IMF suggesting that the first IMF to take control over the intent management task.Thereafter, the first IMF may resume execution of the intent management task.6.4 Assignment of Responsibility to Escalation Handler

[0091] In another embodiment, referring to FIG. 8, the first IMF 104a may assign intent responsibilities to an escalation handler, such as the second IMF 104b. At step 802, the first IMF 104a may receive an escalation expectation from the intent owner 102. The escalation expectation may include a reference that identifies the second IMF. At step 804, the first IMF 104a may identify the escalation condition, and determine if the escalation condition is met. At 806, once the escalation condition is met, the first IMF 104 may assign the original intent(s) to the second IMF, so that the second IMF can handle the original intent(s) going forward. At 808, the first IMF 104 may delete the assigned intent(s). At 810, the first IMF 104a may inform the intent owner about the assignment. For example, the first IMF 104a may report to the intent owner that the original intent(s) have been assigned to the second IMF 104b. Thereafter, the intent owner may interact with the second IMF regarding the assigned intent(s), such as intent updates.

[0092] In some embodiments, the second IMF may transition the intent handling responsibility back to the first IMF 104a, when certain conditions are met.7. Example Methods of Operations

[0093] FIG. 9 illustrates a flow diagram with respect to a method performed by a first IMF 104a to assign an intent management task. At 902, the first IMF 104a may receive, from an intent owner 102, an intent indicating at least one escalation expectation. The escalation expectation may define at least one condition that triggers the first IMF to assign the intent management task to the intent owner or a second IMF 104b. At 904, the first IMF maydetermine if the at least one escalation condition is met. At 906, responsive to determining that the at least one escalation condition is met, the first IMF may assign the intent management task to the intent owner or the second IMF.

[0094] FIG. 10 illustrates a flow diagram with respect to another method performed by the first IMF 104a to assign the intent management task. At 1002, the first IMF may receive, from an intent owner 102, at least one expectation associated with at least a part of a network managed by the first IMF. The at least one expectation may be achievable through execution of the intent management task by the first IMF. At 1004, the first IMF may receive, from the intent owner, an intent indicating at least one escalation expectation. The escalation expectation may define at least one escalation condition that triggers the first IMF to assign the intent management task to a second IMF 104b. At 1006, the first IMF may determine if the at least one escalation condition is met. At 1008, responsive to determining that the at least one escalation condition is met, the first IMF may assign the intent management task to the second IMF for execution by the second IMF to achieve the at least one expectation. At 1010, the first IMF may send to the intent owner a report indicating assignment associated with the at least one expectation. In one embodiment, by indicating the assignment, the report may imply that the full intent management is assigned. In another example, the report may indicate that certain intent management actions for the at least one expectation are assigned to another IMF, e.g., the second IMF. The at least one expectation may be included in the intent or another intent received from the intent owner.8. Technical Advantage and Application

[0095] The present disclosure provides many technical advantages. For example, the present disclosure enables the intent owner to express constraints for autonomous operations via an intent model extension. The present disclosure allows the intent owner to use escalationexpectations to define conditions for autonomous operations of the IMFs. As a result, the IMFs equipped with escalation abilities may be trusted more easily by the intent owner.

[0096] The present disclosure described herein may be used in Open Radio Area Network (O- RAN). FIG. 11 includes an example RIC architecture of O-RAN. The present disclosure may be used in non-RealTime (RT) RAN Intelligent Controller (RIC) or near-RT RIC. In FIG. 11, the RIC architecture of O-RAN may include a service management and orchestration 1102 (SMO), a near-RT RIC 1104, E2 nodes 1106 and Y1 consumers 1108. The SMO 1102 may include a non-RT RIC 1110. The near-RT RIC 1004 may include one or more of the following: 01 termination 1112, Al termination 1114, Y1 termination 1116, near-RT RIC APIs 1118 for xApp (e.g., xApp 1, xApp 2, xAppN), messaging infrastructure 1120, conflict mitigation 1122, xApp subscription management 1124, management function 1126, security 1128, AI / ML support 1130, xApp repository function 1132, shared data layer 1134, database 1136, API enablement 1138, and E2 termination 1140. The IMFs may be implemented as xApps in the Near-RT RIC, or as rApps in the Non-RT RIC.9. Example Components of Entities

[0097] FIG. 12 illustrates example components of the IMF 104, such as IMFs 104a, 104b and 104c. Referring to FIG. 12, the IMF 104 may include processing circuitry 1202 communicatively coupled with memory 1204. The memoiy 1204 may store instructions executable by the processing circuitry 1202 to perform methods described in this disclosure.

[0098] The processing circuitry 1202 may be configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1204. The processing circuitry may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits(ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1202 may include multiple central processing units (CPUs).

[0099] The memory 1204 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1004a, 1004b and 1004c includes one or more application programs, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data. The memory 1204 may store any of a variety of various operating systems or combinations of operating systems.

[0100] In general, the various exemplary embodiments may be implemented in hardware or special purpose chips, circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto. While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special puipose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0101] Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and allmodifications will still fall within the scope of the non-limiting and exemplary embodiments of this disclosure.

Claims

CLAIMS1. A method performed by a first intent management function (IMF) to delegate an intent management task, the method comprising: receiving, from an intent owner, an intent indicating at least one escalation expectation, the escalation expectation defining at least one escalation condition that triggers the first IMF to delegate the intent management task to the intent owner or a second IMF; determining if the at least one escalation condition is met; and responsive to determining that the at least one escalation condition is met, delegating the intent management task to the intent owner or the second IMF.

2. The method of claim 1, wherein the intent management task relates to at least one action executable to achieve an expectation intended by the intent owner, wherein the expectation is represented in a second intent received from the intent owner, and wherein the expectation is associated with a network.

3. The method of claim 2, wherein the at least one escalation condition indicates one or more of the following: at least one of an execution context, an action name, and an action type, each of which is associated with the at least one action; a minimum accuracy level of a prediction made by the first IMF; a problem in the first IMF; one or more expectations associated with the network; any impact on at least one other intent or at least one other intent owner; and a minimum fitness score indicating utility improvement of the first IMF.

4. The method of claim 3, wherein the execution context is one of proposing the at least one action, predicting the at least one action, evaluating the at least one action, and executing the at least one action.

5. The method of any one of claims 3 to 4, wherein the at least one escalation condition indicates the minimum accuracy level of the prediction made by the first IMF, and wherein determining if the at least one escalation condition is met includes determining whether the prediction made by the first IMF is less than the minimum accuracy level.

6. The method of any one of claims 3 to 5, wherein the at least one escalation condition indicates the problem in the first IMF, and wherein determining if the at least one escalation condition is met includes determining whether the problem has occurred.

7. The method of any one of claims 3 to 6, wherein the at least one escalation condition indicates any impact on the at least one other intent or the at least one other intent owner, and wherein determining if the at least one escalation condition is met includes determining whether the intent management task impacts the at least one other intent or the at least one other intent owner.

8. The method of any one of claims 3 to 7, wherein the at least one escalation condition indicates the minimum fitness score, and wherein determining if the at least one escalation condition is met includes determining whether the intent management task improves utility of the first IMF to an extent that is less than the minimum fitness score.

9. The method of claim 8, wherein the at least one escalation condition indicates the minimum fitness score over a time frame, and wherein determining if the at least one escalation condition is met includes determining whether the intent management task improves utility of the first IMF to an extent that is less than the minimum fitness score over the time frame.

10. The method of any one of claims 2 to 8, wherein the expectation is associated with a physical or virtual resource of the network or a service using or running on the network.

11. The method of any one of the preceding claims, wherein the at least one escalation condition is a domain specific escalation condition.

12. The method of any one of the preceding claims, wherein delegating the intent management task includes: freezing execution of the intent management task to an extent that requires delegation; sending, to the intent owner, an escalation report requesting an input regarding the intent management task; and resuming execution of the intent management task after receiving the input from the intent owner.

13. The method of any one of claims 1 to 11, wherein delegating the intent management task includes: freezing execution of the intent management task to an extent that requires delegation; sending, to the second IMF, an escalation report requesting the second IMF to take control over the intent management task;sending, to the intent owner, a report indicating that the second IMF has taken control over the intent management task; receiving, from the second IMF, a signal suggesting the first IMF to take control over the intent management task; and resuming execution of the intent management task.

14. A method performed by a first intent management function (IMF) to delegate an intent management task, the method comprising: receiving, from an intent owner, a first intent indicating at least one expectation associated with a network, the at least one expectation being achievable through execution of the intent management task by the first IMF; receiving, from the intent owner, a second intent indicating at least one escalation expectation, the escalation expectation defining at least one escalation condition that triggers the first IMF to delegate the intent management task to a second IMF; determining if the at least one escalation condition is met; responsive to determining that the at least one escalation condition is met, delegating the intent management task to the second IMF for execution by the second IMF to achieve the at least one expectation indicated by the first intent; and sending, to the intent owner, a report indicating delegation associated with the first intent.

15. A node in a communications network comprising processing circuitry configured to perform the method according to any one of claims 1 to 13.

16. A node in a communications network comprising processing circuitry configured to perform the method according to claim 14.

Images