Intent management in a communication network

Abstract

A method (600) performed by an intent management node in a communications network is disclosed. The method comprises detecting occurrence of an event in relation to a subject intent (610), and obtaining solution proposals to ensure compliance with the subject intent (620). The method further comprises, for each solution proposal, performing steps including evaluating, at each of a plurality of future time steps between the time of the event and a termination time, a predicted utility of intents following implementation of the solution proposal (630), generating, at each of the plurality of future time steps, an aggregated utility of the subject intent and intents managed by the IM node (640), and generating a solution proposal score based on the aggregated utilities at the future time steps (650). The method further comprises selecting a solution proposal according to the generated solution proposal scores (660).

Description

[0001] Intent Management in a Communication Network

[0002] Technical Field

[0003] The present disclosure relates to a method performed by an intent management node in a communications network. The present disclosure also relates to an intent management node and to a computer program product configured, when run on a computer, to carry out methods that may be performed by n intent management node.

[0004] Background

[0005] In a communication network, an intent manager (IM), or intent management function (IMF), provides a zero-touch control for an environment of the network. Figure 1 is a schematic illustration of an IM 110, illustrating the control loop that is orchestrated by the IM, and involves multiple agents. Agents have roles in the loop workflow such as making a proposal for a solution, predicting the outcome of the solution or evaluating how good a solution is to make a decision which solution to act on. Further agents are used to observe the environment 102 or act on selected solutions. These steps together form a closed loop with the purpose of fulfilling intent requirements and keeping those requirements fulfilled. The concept of intent management is based on integrating intent knowledge into generic looped intelligent systems according to: Stuart J. Russel, Peter Norvig 2003: “Artificial Intelligence, A Modern Approach” (2013).

[0006] In the context of communication network management, an intent is defined as “the formal specification of all expectations, including requirements, goals, and constraints, given to a technical system”. Examples of expectations might include “At least 95% of the LIRLLC (Ultra Reliable Low Latency Communication) users shall experience a latency of maximum 20 msec”, or “At least 80% of the users of the conversational video service shall have a minimum QoE (Quality of Experience) of 4.0”, or “Energy consumption of the system shall be kept to a minimum”. More detailed information on intents and how they relate to closed loops is described in Gomes, P. H., Buhrgard, M., Harmatos, J., Mohalik, S. K., Roeland, D., & Niemdller, J. (2021). Intent-driven Closed Loops for Autonomous Networks. Journal of ICT Standardization, 9(2), 257-290. https: / / doi.org / 10.13052 / iicts2245-800X.929. The intent manager illustrated at a high level in Figure 1 may be implemented in a cognitive framework (also known as a cognitive layer). The cognitive framework is further described in https: / / www.ericsson.com / en / reports-and-papers / ericsson-technologv- review / articles / adaptive-intent-based-networking, and Figure 2 illustrates IM internal architecture according to such an implementation. Referring to Figure 2, one or more intents are sent to the IM 210. These intents communicate operator 204 requirements to be met often in the form of setting a target value for Key Performance Indicators (KPI). Raw data and measurements of environment 202 state, including value updates for the involved KPIs, are obtained by data grounding agents 212. If observed KPI values and required values specified by an intent deviate, the IM 210 would need to find solutions involving corrective actions to implement in the environment. An example situation requiring a solution might be a target KPI specified in an intent of “max 20 msec latency” but a measured KPI of “30 msec latency”. One or more proposal agents 214 are responsible for proposing solutions that would solve an issue such as that set out above. A solution can be a single action, such as a configuration change, or it can be an action plan comprising a sequence of actions. Evaluation agents 216 make an assessment as to whether a proposed solution is good or not, and select the best solution. Finally, actuator agents 218 execute the action on the environment under control.

[0007] When applying the architecture of Figure 2 to a mobile communication network, the environment under control would be sub-domains and layers in the operation system stack of the network. The network would typically be divided into multiple domains (i.e., environments) with a dedicated intent manager per domain. Therefore, intent managers may come in a hierarchy. A more elaborate description of intents and the architecture around intents can be found in TM Forum specifications including “TM Forum Introductory Guide: Autonomous Networks - Technical Architecture” (IG1230) or “TM Forum Introductory Guide: Intent in Autonomous Networks” (IG1253). These specifications also include intent managers and the envisioned hierarchy of intent managers.

[0008] As discussed above, Intent Managers allow for zero touch control of communication networks. However, current published methods for intent handling consider only the end results of a solution. It is possible that during implementation of the solution that will result in a favorable end state, an environment may experience a degradation in performance before the desirable end state is reached. Alternatively, implementation of a solution may be time consuming, meaning an end user may be left exposed to a non- desirable state for an unacceptable period of time, before the solution takes effect. Use experience is heavily influenced by the length of time for which a user is exposed to a non-desirable state and how bad the state becomes before improvement is experienced. Sometimes a slow, but constantly improving solution is the most desirable. In other situations, a very quick solution might be preferable, even if it initially worsens the state. The currently proposed or implemented intent management processes do not have the tools to take into consideration factors other than the eventual end state achieved by a solution proposal.

[0009] Summary

[0010] It is an aim of the present disclosure to provide methods, an intent management node, and a computer program product which at least partially address one or more of the challenges mentioned above. It is a further aim of the present disclosure to provide methods, an intent management node, and a computer program product which cooperate to facilitate improved management of a communication network environment.

[0011] According to a first aspect of the present disclosure, there is provided a computer implemented method performed by an intent management node in a communications network, wherein the intent management node is operable to manage intents for an environment of the communication network. The method comprises detecting occurrence of an event in relation to a subject intent, wherein the subject intent is managed by or is submitted for management by, the intent management node. The method then comprises obtaining solution proposals to ensure compliance with the subject intent. The method further comprises performing a sequence of steps for each solution proposal. The sequence of steps includes, for the subject intent and intents managed by the IM node, evaluating, at each of a plurality of future time steps between the time of the event and a termination time, a predicted utility of the intent following implementation of the solution proposal. The sequence of steps further comprises generating, at each of the plurality of future time steps and based on the evaluated predicted utilities, an aggregated utility of the subject intent and intents managed by the IM node. The sequence of steps further comprises generating a solution proposal score based on the aggregated utilities at the future time steps. The method further comprises selecting a solution proposal according to the generated solution proposal scores, and performing at least one of implementing the selected solution, sending a notification that the subject intent cannot be fulfilled, accepting the subject intent, or rejecting the subject intent.

[0012] According to another aspect of the present disclosure, there is provided a computer program product comprising a computer readable non-transitory medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform a method according to any one of the aspects or examples of the present disclosure.

[0013] According to another aspect of the present disclosure, there is provided an intent management node operable to manage intents for an environment of a communication network. The intent management node comprises processing circuitry configured to cause the intent management node to detect occurrence of an event in relation to a subject intent, wherein the subject intent is managed by or is submitted for management by the intent management node. The processing circuitry is further configured to cause the intent management node to obtain solution proposals to ensure compliance with the subject intent. The processing circuitry is further configured to cause the intent management node to perform a sequence of steps for each solution proposal. The sequence of steps includes, for the subject intent and intents managed by the IM node, evaluating, at each of a plurality of future time steps between the time of the event and a termination time, a predicted utility of the intent following implementation of the solution proposal. The sequence of steps further comprises generating, at each of the plurality of future time steps and based on the evaluated predicted utilities, an aggregated utility of the subject intent and intents managed by the IM node. The sequence of steps further comprises generating a solution proposal score based on the aggregated utilities at the future time steps. The processing circuitry is further configured to cause the intent management node to select a solution proposal according to the generated solution proposal scores, and perform at least one of implementing the selected solution, sending a notification that the subject intent cannot be fulfilled, accepting the subject intent, or rejecting the subject intent.

[0014] Aspects of the present disclosure thus provide methods and nodes that enable intent management considering not just an eventual end state for actions ensuring compliance with an intent, but also additional factors, including intent utility before the end state is reached. By considering impact of solution proposals at a range of future time steps, example methods proposed herein allow solution selection based on a range of factors, improving solution selection decision making and environment management.

[0015] Brief Description of the Drawings

[0016] For a better understanding of the present disclosure, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:

[0017] Figure 1 is a schematic illustration of an Intent Manager (IM);

[0018] Figure 2 illustrates IM internal architecture according to an example implementation;

[0019] Figures 3, 4, and 5 illustrate different compliance latencies for intents;

[0020] Figure 6 is a flow chart illustrating process steps in a computer implemented method performed by an intent management node;

[0021] Figures 7a to 7d show flow charts illustrating another example of a computer implemented method performed by an intent management node;

[0022] Figure 8 is a block diagram illustrating functional modules in an example intent management node;

[0023] Figure 9 illustrates example utility paths for different solutions obtained by an intent management node;

[0024] Figure 10 illustrates an example of an intent owner specifying an undesirable state;

[0025] Figure 11 illustrates a flow through an example intent management node;

[0026] Figure 12 shows KPI graphs for hypothetical scenarios corresponding to solution proposals;

[0027] Figure 13 illustrates an in-memory representation of an actions graph for an example gaming scenario; and Figure 14 shows an example of intent rejection after an intent update operation by the owner.

[0028] Detailed

[0029] Examples of the present disclosure propose methods for intent management in which a solution is selected based on a combination of factors, including for example the severity of an intent degradation in combination with time of exposure to unfavorable states. Example methods proposed herein use predictions of future states with various time horizons, allowing consideration not just of an eventual end state, but also intermediate environment states during implementation of a proposed solution. Prediction agents can be configured to make a prediction for one or more specific times in the future, or different prediction agents may be used in combination, so delivering multiple predictions of a solution effect at multiple points in time, as opposed to just the expected end result.

[0030] Utility functions may be used to determine severity of degradation, and the value of a solution result at any point in time for which a prediction is available. In combination with the predictions at multiple points in time, this may provide a substantially continuous value assessment not only for the expected end state, but for any point in time towards that end state.

[0031] Example methods according to the present disclosure enable intent manager evaluation and decision making to be extended by considering additional concerns than the final expected outcome of a solution. According to different options for the methods disclosed herein, in some examples a threshold marking an unacceptable level of utility can be used. Any solution proposal that would at any point in time cause the system to go below this threshold may be discarded. An alternative or additional threshold may be used to mark an undesirable level of utility, with solutions having utility values above this threshold being preferred. A score may be calculated for a given solution proposal, representing a combination of time of exposure to an undesirable utility level and severity of degradation. In some examples, this score may be calculated from the area between the graph of utility over time and the threshold of undesirable utility. In such examples, a solution proposal having a lower score would be preferred. In order to provide additional context to the present disclosure, there now follows a discussion of the concepts of intent utility and intent compliance latency.

[0032] Intent utility is a measure of value that may be used to assess a solution for compliance with an intent. Intents are submitted to an intent manager by intent owners (i.e., a human operator or another intent manager) via the intent interface (see Figure 2). Intents specify requirements from the intent owner’s perspective, but they need to be fulfilled by an intent manager that acts as an intent handler and may not know exactly would be the perceived usefulness of fulfilling a given intent from the owner's perspective. The intent owner can introduce utility functions to quantify and communicate to the intent manager the owner’s notion of the value of having a given intent fulfilled. Utility functions are unusually expressed on a per KPI basis. The intent manager can apply these utility functions in the evaluation of how valuable a state is. Consequently, the intent handler can evaluate the value of a proposed solution from the state it would achieve. The intent manager would first predict the state (KPI values) a proposed solution is be expected to achieve, using a prediction agent. The utility functions would then be applied to the predicted KPI values and aggregated into a global score. This may be done separately for every proposed solution. At the end of this process one solution will have the highest utility score and this therefore the best solution available. This is called decision by utility maximization.

[0033] P104378 discloses a mechanism to ingest and calculate for each individual intent, and a mechanism to calculate the intent manager’s utility as a function of the individual intent utilities. In general, the objective of an IM while trying to solve intents is to choose action plans maximizing the IM utility. As discussed above, in the present disclosure, utility may be sued to assess not just the end state of a solution, but also the intermediate states into which a managed environment may be placed, as well as considering a time spent in such intermediate states. In order to assess time spent, the concept of intent compliance latency is helpful.

[0034] During autonomous operations, a system state might become degraded with respect to the requirements specified within the intent. If this occurs, the intent manager is expected to act so as to bring the system back into a compliant state. It might take a certain amount of time for the action to show an effect, and how much time typically depends on the actions taken. By referring to TR291 E a “compliance latency target” can be defined as the target time budget that the intent manager has available to reach a compliant system state with its actions. Similarly, “compliance latency reached” can be defined as the amount of the compliance latency budget used by the IM when satisfying a requirement.

[0035] Intent compliance latency can be expressed for different aspects of the requirements specified in an intent, affecting the instant of time from which the compliance latency budget should be calculated. The examples below clarify the three possible situations:

[0036] 1) Initial compliance latency specifies how long it shall take until the intent requirements are met after the intent was initially received or set. In the example of Figure 3, the “initial compliance latency reached” is equal to KPI target reached time minus set intent time.

[0037] 2) Update compliance latency specifies how long it shall take until the intent is met after its requirements were updated. In the example of Figure 4, the “update compliance latency reached” is equal to KPI target reached time minus intent (or KPI) update time. This limit ay be particularly interesting, for example if the update introduces more challenging requirement levels.

[0038] 3) Degradation compliance latency specifies how long it shall take to reach compliance again after system degradation means intent requirements are no longer fulfilled. In the example of Figure 5, the “degradation compliance latency reached” is equal to KPI target reached time minus intent (or KPI) degrade time.

[0039] Figure 6 is a flow chart illustrating process steps in a computer implemented method 600 performed by an intent management node in a communications network. The intent management node is operable to manage intents for an environment of the communication network. The intent management node may comprise a physical or virtual node, and may be implemented in a computer system, computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, an Open Radio Access Network, O-RAN, or fog deployment. In some examples, the intent management node and / or logical elements thereof may be implemented as one or more rApps or xApps. Examples of a virtual node may include a piece of software or computer program, a code fragment operable to implement a computer program, a virtualised function, or any other logical entity. The intent management node may for example be implemented in a core network of the communication network. In other examples, in which the communication network is a 3GPP network such as a 3G, 4G, 5G, 6G or other cellular communication network, the intent management node may be implemented in a Radio Access node, which itself may comprise a physical node and / or a virtualized network function that is operable to exchange, transmit, receive, process and / or orchestrate wireless signals. In some examples, a Radio Access node may comprise a base station node such as a NodeB, eNodeB, gNodeB, or any future implementation of this functionality. The intent management node may encompass multiple logical entities, as discussed in greater detail below, and may for example comprise a Virtualised Network Function (VNF). In other examples, the first node may be implemented in a device, which may be a wireless device, a wired device, a constrained device, etc.

[0040] Referring to Figure 6, the method 600 comprises, in a first step 610, detecting occurrence of an event in relation to a subject intent, wherein the subject intent is managed by or is submitted for management by, the intent management node. In step 620, the method 600 further comprises obtaining solution proposals to ensure compliance with the subject intent. The method 600 then comprises performing steps 630, 640, and 650 for each solution proposal. Step 630 comprises, for the subject intent and intents managed by the IM node, evaluating, at each of a plurality of future time steps between the time of the event and a termination time, a predicted utility of the intent following implementation of the solution proposal. Step 640 comprises generating, at each of the plurality of future time steps and based on the evaluated predicted utilities, an aggregated utility of the subject intent and intents managed by the IM node. Step 650 comprises generating a solution proposal score based on the aggregated utilities at the future time steps.

[0041] The method 600 further comprises, in step 660, selecting a solution proposal according to the generated solution proposal scores. In step 670, the method 600 then comprises performing at least one of implementing the selected solution, sending a notification that the subject intent cannot be fulfilled, accepting the subject intent, or rejecting the subject intent. The action taken in step 670 may depend upon whether the subject intent is managed by the intent management node or is submitted for management by the intent management node, as well depending on the generated solution proposal scores.

[0042] It will be appreciated that the method 600 examines not just the final utility of possible solutions, but also the utility of the intermediate states into which the environment will be placed by the solution proposals, owing to the evaluation of predicted utility at a plurality of future time steps. In this manner, a solution that results in high final utility but takes an unacceptably long time to achieve this, or which temporarily places the environment into an unacceptable state, can be avoided. The method 600 refers in step 610 to an event in relation to a subject intent. An event may encompass any trigger for the method 600, such as receiving a new intent for management, receiving a new intent for evaluation, receiving an updated intent or an update to an intent currently managed by the intent management node, or a change in the environment that means an intent is no longer fulfilled.

[0043] The solution proposals obtained in step 620 may be generated by the intent management node, or logical entities within the intent management node, such as prediction agents, or the solution proposals may be received, for example from one or more prediction agents instantiated outside the logical entity of the intent management node. The method 600 involves obtaining, for each proposed solution (each of which may comprise one or more actions and / or sub-actions), predicted utility values for individual intents managed by the intent management node at different future time steps. These are then aggregated at each time step, and may for example be represented on a solution utility graph, as discussed in further detail below. This aggregation of utilities for intents management by the intent management function enables the generation of the solution score, and selection of a solution. The final step 670 of the method covers the various actions that may be taken depending upon the selected solution. Each final action has an impact on the managed environment, whether that be through implementation of the selected solution, or increased or reduced resource constraints according to whether an intent is accepted or rejected. In other examples, the environment may be impacted through the sending of notification, meaning that the intent management node will stop trying to fulfil an intent that cannot be fulfilled without violating other constraint, so freeing environment resources for other purposes. In some examples, rejecting the subject intent could include rejecting a requested update for an intent that is already being managed by the intent management node.

[0044] Figures 7a to 7d show flow charts illustrating another example of a computer implemented method 700 performed by an intent management node in a communications network, the intent management node being operable to manage intents for an environment of the communication network. As for the method 600 discussed above, the intent management node may comprise a physical or virtual node, and may be implemented in a computer system, computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, an Open Radio Access Network, O-RAN, or fog deployment. In some examples, the intent management node and / or logical elements thereof may be implemented as one or more rApps or xApps. Examples of a virtual node may include a piece of software or computer program, a code fragment operable to implement a computer program, a virtualised function, or any other logical entity. The intent management node may for example be implemented in a core network of the communication network. In other examples, in which the communication network is a 3GPP network such as a 3G, 4G, 5G, 6G or other cellular communication network, the intent management node may be implemented in a Radio Access node, which itself may comprise a physical node and / or a virtualized network function that is operable to exchange, transmit, receive, process and / or orchestrate wireless signals. In some examples, a Radio Access node may comprise a base station node such as a NodeB, eNodeB, gNodeB, or any future implementation of this functionality. The intent management node may encompass multiple logical entities, as discussed in greater detail below, and may for example comprise a Virtualised Network Function (VNF). In other examples, the first node may be implemented in a device, which may be a wireless device, a wired device, a constrained device, etc. The method 700 illustrates examples of how the steps of the method 600 may be implemented and supplemented to provide the above discussed and additional functionality.

[0045] Referring initially to Figure 7a, in a first step 710, the intent management node detects occurrence of an event in relation to a subject intent, wherein the subject intent is managed by or is submitted for management by the intent management node. As discussed above, the intent management node is operable to manage intents for an environment of the communication network. As illustrated at step 710a, the environment may comprise at least one of a cell of a communication network, a cell sector of a communication network, at least a part of a core network or transport network of a communication network, a slice of a communication network, and / or one or more other intent management nodes. The intent management node may thus be part of a hierarchy of intent management nodes, with lower nodes in the hierarchy receiving intents to be fulfilled from higher nodes in the hierarchy, and higher nodes in the hierarchy selecting solution proposals that include intents to be provided to lower nodes in the hierarchy.

[0046] It will be appreciated that appropriate metrics may be specified in intents for the various different type of environment. The metrics may in some examples measure performance of tasks by the environment, such as provision of network services transport services, radio access services, etc. For example, if the environment comprises a cell, a cell sector, or a group of cells of a communication network, the task may comprise provision of Radio Access Network (RAN) services to wireless devices connecting to the network from within the environment. In other examples, if the environment comprises a network slice, or a part of a transport or core network, the task may be to provide end-to-end network services, core network services such as mobility management, service management etc., network management services, backhaul services or other services to wireless devices, to other parts of the communication network, to network traffic originating from wireless devices, to application services using the network, etc.

[0047] As illustrated at step 710b, an event in relation to a subject intent, wherein the subject intent is managed by or is submitted for management by the intent management node, may comprise at least one of: receipt of a new intent submitted for management by the intent management node; receipt of a new intent submitted for evaluation by the intent management node; receipt of an update to an intent managed by the intent management node; a change in environment state causing an intent managed by the intent management node to no longer be fulfilled.

[0048] An intent, as illustrated at 710c, may comprise a specification of expectations for the environment, the expectations including at least a target value of at least one metric describing performance of the environment. In some examples, the metric may describe performance of the environment in an implicit manner. For example, the metric may measure performance or another characterizing feature of a service using the environment. As this metric will be impacted by the performance of the environment, this metric implicitly describes performance of the environment. Consequently, according to examples of the present disclosure, an expectation included in an intent may be associated with a physical or virtual resource of the network or a service using or running on the network. In further examples, the metric may explicitly describe performance of the environment. As discussed above, the metric may be a KPI or other measures of performance, and may be appropriate to the environment under consideration, including for example latency, throughput, coverage, signal quality, jitter, Maximum Bit Rate (MBR), Quality of Service (QoS), Quality of Experience (QoE), energy consumption, network slice performance, allowed service interruption time, mean time between failure, mean time to recover, communication service availability ratio, successful handover, packet loss, spectrum efficiency, etc. According to different examples of the present disclosure, an intent may further comprise a range of additional elements, including for example minimum requirements for metrics, and other requirements or constraints that may be imposed on the environment. Such requirements or constraints my include safety requirements or constraints, privacy requirements or constraints, cost requirements or constraints, explainability requirements or constraints, etc.

[0049] Referring still to Figure 7a, in step 720, the intent management node obtains solution proposals to ensure compliance with the subject intent. As illustrated at 720a, a solution proposal may comprise at least one of an action for implementation in the environment, a plurality of actions for implementation in the environment, a series of actions for sequential implementation in the environment, an intent for implementation in the environment, and / or a plurality of intents for implementation in the environment. In the case of an intent or plurality of intents, the environment may comprise an intent management node and / or a plurality of intent management nodes, as discussed above.

[0050] It will be appreciated that each action in a solution proposal may comprise one or more sub-actions, which may be implemented more or less independently. Additionally, and in the event that a solution proposal comprises a series of actions for sequential implementation in the environment, the prediction of metric values at future time steps discussed below in step 730a may take account of the sequential implementation of each action in the series, i.e. , not just taking account of the impact over time of a single action, but updating the prediction to take account also of implementation of subsequent actions in the series.

[0051] Referring now to Figure 7b, the intent management node then performs a series of steps for each of the obtained solution proposals. The intent management node therefore, in step 725, selects a next solution proposal for consideration. In step 730, for the subject intent and intents managed by the IM node, the intent management node evaluates, at each of a plurality of future time steps between the time of the event and a termination time, a predicted utility of the intent following implementation of the solution proposal. This evaluation may be performed sequentially for each of the subject intent and intents managed by the intent management node.

[0052] As illustrated at 730a, evaluating, at each of the plurality of future time steps, a predicted utility of the intent under consideration following implementation of the solution proposal may first comprise predicting, at each of the plurality of future time steps, a value of one or more metrics specified in the intent following implementation of the solution proposal. As discussed above, in the event that a solution proposal comprises a series of actions for sequential implementation in the environment, the prediction of metric values at future time steps may take account of the sequential implementation of each action in the series, i.e., not just taking account of the impact over time of a single action, but updating the prediction to take account also of implementation of subsequent actions in the series. Evaluating predicted utility of the intent under consideration may then comprise, at step 730b, calculating a utility of the intent at each of the plurality of future time steps based on the predicted metric values. It will be appreciated that calculating a utility of an intent may comprise calculating a value of a utility function, the utility function being a function of values of metrics specified in the intent.

[0053] Step 730 involves evaluating a predicted utility of an intent under consideration following implementation of the solution proposal at each of a plurality of future time steps between the time of the event and a termination time. As illustrated at 730c, the termination time may comprise at least one of: a time at which the solution has been fully implemented; a time at which the subject intent has been fulfilled; a predefined time after the time of the event; and / or a predetermined time after the subject intent has been fulfilled.

[0054] It will be appreciated that according to the termination condition, it may be that intent utility is investigated beyond fulfilment of intent requirements, for example to check for metric stability following fulfilment of an intent.

[0055] In step 735, the intent management node performs the action of, for the subject intent and intents managed by the IM node, at each future time step, checking for fulfilment of a pruning criterion, and, if the pruning criterion is fulfilled, pruning the current solution proposal. According to examples of the present disclosure, pruning a solution proposal may be understood as meaning discarding, or removing the solution proposal from the set of obtained solution proposals, i.e., it is no longer evaluated for utility etc., and the intent management node moves on to the next solution proposal. The intent management node may therefore perform the steps 735 and 730 substantially concurrently, according to the nature of the pruning condition. This may involve, for example checking, after each prediction of a future state, or each calculation of utility, whether the pruning condition has been fulfilled. If at any time during the evaluation, the pruning condition is fulfilled, the intent management node may prune the current solution proposal, and return to step 725 to select a next one of the obtained solution proposals for evaluation. In this manner, the computational load of evaluating multiple solution proposals may be reduced by early pruning of proposals that violate e.g., latency budget, safety conditions, or threshold metric values.

[0056] The process of performing step 735 is illustrated in greater detail in Figure 7d. Referring now to Figure 7d, for each intent under consideration, and at each future time step (step737), the intent management node checks for fulfilment of a pruning criterion (step 736). This checking for fulfilment of a pruning criterion may comprise performing at least one of: comparing a predicted value of a metric specified in the intent following implementation of the solution proposal to a threshold value of the metric specified in the pruning condition at step 736a; comparing a time elapsed since occurrence of the event to a latency budget specified in the pruning criterion in step 736b; and / or comparing a safety risk measure to a threshold safety risk specified in the pruning condition at step 736c.

[0057] In some examples, the threshold values specified in the pruning condition may be taken from the relevant intent, which for example may specify target values of metrics but may also specify limiting thresholds which the relevant metric must not be allowed to reach / pass. Similarly, the latency budget may be specified in the pruning condition explicitly, or may be extracted from an intent under consideration. The safety risk measure could be a numerical score, or a counter for a number of times the environment is exposed to a safety risk as a consequence of states predicted to be entered during implementation of the solution. The threshold could be a value for the numerical score, a maximum value for the counter, or some combination of both, etc.

[0058] In step 738, the intent management node checks whether the comparisons in steps 736a, b and / or c have indicated that the pruning condition is fulfilled. If the pruning condition is fulfilled, then the solution proposal currently under consideration is pruned, i.e. discarded or removed from consideration, and the intent management node returns to step 725 to select the next of the obtained solution proposals. If the pruning condition is not fulfilled, then the intent management node moves on to the next time step, and the prediction of future metric values and calculation of utility according to step 730. The intent management node thus checks for fulfilment of the pruning condition as part of the ongoing evaluation of intents according to the currently considered solution proposal until the termination condition is reached.

[0059] Referring again to Figure 7b, as illustrated at step 735a, if all obtained solution proposals are pruned, the intent management node may perform at least one of rejecting the subject intent or sending a notification that the subject intent cannot be fulfilled. All solution proposals being pruned would indicate that the intent management node has been unable to obtain a solution proposal that allows the subject intent to be fulfilled without violating a condition that has been deemed unacceptable, either as a minimum required standard specified in an intent already managed by the intent management node, or as a safety or other risk that cannot be tolerated in the environment, as expressed via the pruning condition.

[0060] In step 740, following the evaluation at step 730 (and assuming the solution proposal under consideration is not pruned at step 735), the intent management node then generates, at each of the plurality of future time steps and based on the evaluated predicted utilities, an aggregated utility of the subject intent and intents managed by the intent management node. The aggregated utility may for example be a sum, or a weighted sum, or some other combination of the utilities of the different intents at a given time step.

[0061] Referring now to Figure 7c, in step 750, the intent management node generates a solution proposal score based on the aggregated utilities at the future time steps. As illustrated at 750a, generating a solution proposal score based on the aggregated utilities at the future time steps may comprise calculating the aggregated utility over time for a solution proposal. As illustrated at 750b, in further examples, generating a solution proposal score based on the aggregated utilities at the future time steps may comprise calculating the area between a graph of aggregated utility over time for a solution proposal and a threshold value of aggregated utility, below which the environment is considered to be in an undesirable state. The definition of an undesirable state may be an aggregated utility threshold that is defined by a communication network operator, end user, or other authority, and / or may be set out in one or more intents, and / or may be defined by or programmed into the intent management node. At step 755, the intent management node checks whether all of the obtained solution proposals have been considered in steps 730 to 750. If all solution proposals have not been considered, then the intent management node returns to step 725 to select the next of the obtained solution proposals. If all solution proposals have now been considered, the intent management node proceeds, in step 760, to select a solution proposal according to the generated solution proposal scores.

[0062] As illustrated at step 760a, selecting a solution proposal according to the generated solution proposal scores may comprise evaluating the solution proposals according to an evaluation criterion. This may involve, as illustrated at step 760b, comparing, for the solution proposals, at least one of: a predicted final aggregated utility for the solution proposals; a time spent in an undesirable utility state; a minimum value of aggregated utility; and / or the generated solution proposal score.

[0063] It will be appreciated that the final aggregated utility for a solution proposal refers to the aggregated utility at the end of implementation of the solution, and may be evaluated for example when metric values have stabilized following implementation of the final action specified in the solution proposal. As discussed above, an undesirable utility state may be defined by a threshold value of aggregated utility, below which the environment is considered to be in an undesirable state. This is distinguished from an unacceptable state, which is defined by a (lower) threshold value of aggregated utility, and may be specified as part of a pruning condition and / or as part of the evaluation criterion. The evaluation criterion may for example seek to minimize time spent in an undesirable state, avoid entering an unacceptable state completely, and maximize a final aggregated utility. It will be appreciated that the evaluation criterion may take account of multiple factors, for example seeking to maximize and / or minimize one or more parameters, while ensuring that one or me limiting thresholds for those or other parameters are respected. These multiple considerations may be evaluated on a hierarchy, for example requiring limiting thresholds to be respected, and within the limit of what is possible once such thresholds are respected, maximizing or minimizing parameter values according to a specified order of importance for those parameters. With respect to the evaluation criterion factors discussed above, and as illustrated at 760b, for the solution proposals, comparing a minimum value of aggregated utility may comprise at least one of: comparing minimum values of aggregated utility between solution proposals; and / or comparing the minimum value of aggregated utility for each proposal to a threshold value of aggregated utility below which the environment is considered to be in an unacceptable state.

[0064] In step 770, the intent management node performs at least one of implementing the selected solution, sending a notification that the subject intent cannot be fulfilled, accepting the subject intent, or rejecting the subject intent. As illustrated at 770a, the action taken at step 770 may be taken according to a result of the evaluation. For example, if no solution proposal meets the evaluation criterion, and the subject intent is a currently managed intent, the intent management node may send a notification that the subject intent cannot be fulfilled. In this manner, the intent management node may cease trying to fulfil the intent, so freeing resources in the environment for fulfilment of other managed intents. In another example, if no solution proposal meets the evaluation criterion, and the subject intent is an intent submitted to the intent management node for evaluation, the intent management node may reject the subject intent. In further examples, if a solution proposal has been selected according to the evaluation criterion, then the intent management node may either implement the selected solution and / or accept the subject intent, according to whether the subject intent is already managed by the intent management node, or has been submitted for evaluation by the intent management node.

[0065] It will be appreciated that intents submitted for evaluation by the intent management node may be evaluated in a simulated environment, for example via a digital twin intent management node, which may evaluate newly submitted intents before determining whether they should be accepted for management by the intent management node. In this manner, disruption to the environment as a consequence of newly received intents which cannot be fulfilled can be avoided.

[0066] As discussed above, the methods 600 and 700 are performed by an intent management node, and the present disclosure provides an intent management node that is adapted to perform any or all of the steps of the above discussed methods. The intent management node may comprise a physical node such as a computing device, server etc., or may comprise a virtual node. A virtual node may comprise any logical entity, such as a Virtualized Network Function (VNF) which may itself be running in a cloud, edge cloud or fog deployment. The intent management node may be operable to be instantiated in a cloud based deployment.

[0067] Figure 8 is a block diagram illustrating an example intent management node 800 which may implement the method 600 and / or 700, as illustrated in Figures 6 and 7a to 7d, according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 850. Referring to Figure 8 the intent management node 800 comprises a processor or processing circuitry 802, and may comprise a memory 804 and interfaces 806. The processing circuitry 802 is operable to perform some or all of the steps of the method 600 and / or 700 as discussed above with reference to Figures 6 and 7a to 7d. The memory 804 may contain instructions executable by the processing circuitry 802 such that the intent management node 800 is operable to perform some or all of the steps of the method 600 and / or 700, as illustrated in Figures 6 and 7a to 7d. The instructions may also include instructions for executing one or more telecommunications and / or data communications protocols. The instructions may be stored in the form of the computer program 850. In some examples, the processor or processing circuitry 802 may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry 802 may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) etc. The memory 804 may include one or several types of memory suitable for the processor, such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive, etc.

[0068] Figures 6 and 7a to 7d discussed above provide an overview of methods which may be performed according to different examples of the present disclosure. These methods may be performed by an intent management node as illustrated in Figure 8. The methods enable an intent management node to consider not just end state utility of solutions proposed for fulfilment of intents, but also the intermediate states traversed by a manged environment according to the proposed solutions. There now follows a detailed discussion of how different process steps illustrated in Figures 6 and 7a to 7d and discussed above may be implemented. The functionality and implementation detail described below is discussed with reference to the modules of Figure 8 performing examples of the methods 600 and / or 700, substantially as described above.

[0069] As discussed in the explanation of methods 600 and 700 above, an important aspect of methods according to the present disclosure is the evaluation of predicted intent utility at a plurality of future time steps, according to different proposed solutions. This is carried out in steps 630, 730, and 730a to 730c of the above discussed methods. This prediction may be supported by prediction agents, within or external to the intent management node, which agents can make predictions for a specific time in the future. For example, one agent might predict throughput 5 minutes into the future, and another would predict throughput for 1 hour in the future. Yet another agent might be able to do both predictions, generating a set of predictions annotated with the timeframes of their applicability. Such an agent might also be configured with a particular time horizon, and would make its predictions accordingly. One or more prediction agents can be trained appropriately according to the predictions they are required to make, by curating / selecting the set of training data that both reflects outcomes after the relevant time period and is also annotated with the outcome latency.

[0070] In some examples, if the solution proposal consists of a sequence of actions to be executed over time, a sequence of individual predictions can be used for every constituent action in the proposal, creating a time series of expected states and KPI values. The difference between this and the predictions discussed immediately above, is that in the present example, a prediction is tied to a new action that is happening over time. Predictions discussed above can start with a single action and produce multiple predictions for different times in the future without new intermediate actions. In contrast, predictions related to a sequence of actions reflect not only the ongoing effect of a first action in the sequence, but also the cumulative effect of new intermediate actions being carried out according to the sequence.

[0071] Steps 650, 750, 735, and 736 to 739 of the methods 600, 700 make reference to states which are undesirable or unacceptable. Such states may in some examples be defined with respect to a threshold value of utility, and may be used in the scoring and selection of solution proposals, and / or in the pruning of solution proposals according to examples of the present disclosure. Undesirable and unacceptable states are discussed in greater detail below, with reference to particular illustrating examples. Typically, proposing agents, which may be logical functions within the intent management node, or may be separate from the intent management node, generate multiple alternative solution proposals. Using prediction agents, the intent management node can create an expected path of intent fulfilment through multiple points in time. As illustrated in step 730, such an expected path may be calculated for every solution proposal. Using utility functions, the expected path may be transformed from KPI value domain into utility domain. The result is a utility path over time for each solution. Figure 9 illustrates utility paths for two different solutions obtained by an intent management node to fulfill a QoE target in an intent. Each solution proposal (P2 and P3) is represented by a graph of utility value.

[0072] The striped area of Figure 9 represents a level of utility that is below a threshold for an “undesirable” level of utility, meaning time within this state should be minimized. The solution proposals seek to exit this undesirable state, and move to a level of utility that is above the undesirable threshold. A threshold value for an undesirable state can be a separately defined new threshold in the intent model. It is a threshold of utility.

[0073] In the example of Figure 9, both solution proposals start at the currently observed state with a utility score of 2. The solution proposal represented by path P3 is expected to leave the undesirable state region after 4 seconds and without further degrading the system state. The utility according to solution proposal P3 is not expected to fall below the initial starting point, and is predicted to reach a final utility value of 5. The solution proposal represented by path P2 initially leads to further degradation of the state. Path P3 also takes longer to leave the undesirable state, although it is then predicted to reach a higher final utility of 6. The solution proposals P2 and P3 consequently differ in how long and to what extent they expose the network and its users to an undesirable state. This can be quantified by calculating the area between the path graph and the threshold value for entering the undesirable state (4 in this example). This area is significantly larger for P2 than for P3, meaning P3 total exposure to undesirable state (both in duration of exposure and severity of state) is significantly smaller for P3. Despite only reaching a final utility of 5, the P3 solution proposal may therefore be the better choice.

[0074] According to examples of the present disclosure, the intent management node has the capability to take into account additional metrics in its decision process, these metrics showing the advantages of a solution proposal from different points of view: 1 . Expected final utility level;

[0075] 2. Expected time until the system improves out of the undesirable state region;

[0076] 3. Intermediate further degradation;

[0077] 4. The combination of bad state exposure time and severity as expressed by areas between the solution utility path and the undesirable state threshold.

[0078] In addition to the concept of an undesirable state, the concept of an unacceptable state is also introduced. An unacceptable state marks a utility threshold below which a solution path must never fall. If a solution is expected to lead to a state below that threshold, the respective solution is not considered feasible and would be discarded from the decision making, for example as part of the pruning process of step 735. In the example illustrated in Figure 9, the unacceptable threshold might be set at 1.5. This would mean that the solution P2 is not feasible, as it causes the environment to enter an unacceptable state.

[0079] In some examples, unacceptable state thresholds may be set by network operator. In further examples, unacceptable state threshold may be set by an intent owner. Undesirable state thresholds may generally be set by an intent owner, expressing intent owner preferences for a level of utility that has negative consequences for whatever the intent is seeking to achieve. An example of an intent owner specifying an undesirable state is illustrated in Figure 10. An intent management node will typically have multiple solution proposals available, with multiple feasible paths (solution proposals) according to compliance latency requirements, and the definition of an undesirable state can assist the intent management node with deciding which of the solution proposals should be selected. For example, a gaming application might indicate that when the user has a QoE of less than 4, the gameplay becomes undesirable (because the intent owner has noticed that user drops from the session when the situation arises). On the other hand, when QoE is between 4 and 5, the user keeps playing even with a degraded quality as the quality reduction has a minimal impact on gameplay. The intent owner may therefore specify in the intent a restriction defining an "undesirable state". This state should be avoided in the intent management process, and so provides additional information about intent owner preferences when fulfilling intent expectations with respect to time. By taking this additional information into account, the intent management node provides enhanced functionality to the intent interface.

[0080] It will be appreciated that a utility function provides the mapping from individual performance metrics, including KPIs, to the utility that may be used to decide between solution proposals. A utility function can also specify the utility associated with exposure time area to an undesirable state. The smaller this area, the higher the utility. One or more additional utility functions, for example encompassing exposure time area and other metrics, can be introduced by an intent owner, and communicated to the intent management node by inclusion in an intent. These additional utility functions enable the integration of concerns like problem exposure time into the general decision making based on global utility maximization. Through the utility functions for low exposure to undesirable state, the value of low exposure is expressed and considered in the context of other concerns.

[0081] In some examples of the present disclosure, the intent management node may seek to select solution proposals whose action paths maximize the intent management node’s utility over time (that is maximizing the utility of intents managed by the intent management node over time). When trying to satisfy a certain KPI with respect to an intent, other KPIs (e.g., from other intents) might be affected because, for example, applications share the same network’s resources. The overall impact of actions on all intents can be considered in the decision making of the intent management node using rules-based policies or concepts like utility maximization. Typically, multiple action paths are feasible and consist of multiple branches with different constituent actions. One of the alternative branches is the path with maximum overall utility. This means, based on predictions of the outcome of alternative actions in the path, a path utility can be calculated by applying utility functions. The most valuable solution is the one consisting of the actions of the path with maximum path utility.

[0082] Illustrative example: considering compliance latency requirements while selecting actions.

[0083] The following example scenario illustrates selecting a solution proposal characterized by a sequence of actions. As discussed above, in an intent manager, one or more proposal agents are responsible for proposing actions that would solve intents and, during evaluation, an assessment is made as to whether or not a proposed action (or a sequence of actions) should be implemented in the managed environment. In the intent management node of the present disclosure, the proposal agents may be logical functions within the intent management node, or may be external to the intent management node. Figure 11 illustrates a flow through an example intent management node for evaluating a sequence of actions with respect to compliance latency requirements. Referring to Figure 11 , on the left part of the figure are illustrated trigger conditions for starting to count the compliance latency budget available. These trigger conditions are examples of events as discussed in steps 610 and 710 of the methods 600, 700. The main examples of trigger conditions include intent insertion (or provision of a new intent for evaluation), intent update (or provision of intent update for evaluation), and intent degradation events, although these are not the only examples of trigger events. For example, if the intent handler receives a call on the optional interfaces (PROBE, BEST or PREFERENCE) the methods of the present disclosure may also be triggered.

[0084] In the example illustrated in Figure 11 , the proposal agents generate 3 different solution proposals, each solution proposal comprising a single action: A1 , A2, and A3. According to a conflict detection architecture (as discussed for example in W02023 / 200412 Conflict detection for interacting closed loops) a consequence of implementing the actions of the three solution proposals can be individually predicted with respect to their impact on the system state, leading to predicted states for actions A1 , A2, and A3.

[0085] The evaluation component may then evaluate how the network will evolve if one of these solution proposals is selected. In the hypothetical scenario 1 , the solution proposal comprising action A1 is selected, and the prediction agent(s) have already calculated that this action will lead the network toward a certain predicted state. The intent management node can now use rules and relations (including for example machine reasoning) for looking at the issues that will be generated if action A1 is implemented, and which actions will result from such issues. In the present example, it can be seen that actions A4 and A3 will be proposed. In the hypothetical scenario 2, the solution proposal comprising action A2 is selected. This action will lead to a set of issues and the proposal of actions A6 and A1 . Similarly, for hypothetical scenario 3, action A0 will follow action A3.

[0086] Starting from these scenarios, evaluation can continue with a look-ahead strategy, by opening other scenarios and investigating what will happen after the selection of actions in a recursive way.

[0087] Figure 12 shows KPI graphs for the hypothetical scenarios 3 and 1 discussed above. Each graph represents evolution of a KPI specified in an intent over time, following a trigger event in the form of degradation of the KPI value below a target set in the intent. The evaluation process discussed above predicts that the two hypothetical scenarios illustrated in Figure 12 will result in satisfaction of the KPI target set in the intent:

[0088] Scenario 3: A3 followed by AO (on the left)

[0089] Scenario 1 : A1 followed by A4 (on the right)

[0090] In Figure 12 it can clearly be seen that A3 followed by AO (shown on the left graph) allows for respecting the illustrated latency target, i.e. , the compliance latency reached is lower than the compliance latency target. A1 followed by A4 (shown on the right graph) is potentially a better sequence of actions for the KPI in the long term, but the compliance latency target would be violated if this sequence of actions is implemented. Violation of latency budget is one condition that can be managed via the pruning of step 735 of the method 700, as discussed in further detail below.

[0091] The following discussion explores pruning of solution proposals based on a pruning criterion related to latency budget, however it will be appreciated the implementation detail provided could equally be applied to other examples of pruning condition, as set out above with reference to the method 700.

[0092] The illustrative example discussed above shows how examples of the present disclosure may build a sequence of actions at runtime that respect a certain compliance latency target. Recursively exploring the possible evolution of the system’s state is a computationally expensive problem, with the future states potentially exploding exponentially. To address the state explosion problem, examples of the present disclosure propose the runtime pruning of actions while evaluating solution proposals by building a sequence of actions (i.e., actions graph) respecting a compliance latency target (or other pruning criterion).

[0093] In an illustrative example, an intent owner wants the intent management node to assure a gaming application. As the owner wants to ensure optimal experience for the application users, it specifies that users' QoE must be greater or equal to 5 (KPI target), and it should take at most 20 seconds (i.e., initial compliance latency target) for a user to experience such QoE from service instantiation. Figure 13 illustrates an in-memory representation of an actions graph for the present gaming example. Each node is an action (e.g., AO, A1 , A2, etc.) and each node is labeled with the KPI state for which the action is proposed (e.g., A1 is proposed in a state where QoE=2). Each arrow connecting two nodes is labelled with the time (estimated by predictor agents) necessary for an action to move the system to a certain state (e.g., action A1 will take 25 seconds to lead to the managed environment entering a state in which QoE= 4, at which state action A7 will be taken).

[0094] Referring to Figure 13 it is possible to examine which sequence of actions allows the intent manager to satisfy both the KPI target (QoE>=5) and the compliance latency requirements (i.e. , t=20s). AO followed by A7 allows to move the system into a state in which QoE=5 but it does that in t=25s + 3s = 28s, which is more than the compliance latency requirement. The same issue of exceeding compliance latency budget can be seen for action AO, which takes 23s to move to the target QoE. A2 will reduce the QoE to 1 in 3.5s (thus initially worsening the target KPI), but then this action will be followed by action A4, which will bring the QoE to 5 in just an additional 5s. A3 followed by A5 it is also a good option, because it will bring the QoE to 6 in 10s.

[0095] It will be appreciated that the leaf nodes in the action graph have no name because it becomes irrelevant to look at action proposals once the target value for the relevant KPI (QoE in this example) has been reached.

[0096] On the basis of the above analysis, the intent management node should choose from between the two feasible sequences of actions for bringing the game application up and running according to a certain quality and timing:

[0097] • A2 -> A4

[0098] • A3 -> A5

[0099] Evaluating this action graph only once constructed is inefficient. For example, it is already possible to determine that that AO will violate the compliance latency requirement, so it is irrelevant for the intent management node that, following AO, A7 will bring the system to an acceptable value of QoE. Runtime pruning of solution proposals, as discussed above with reference to step 735 of method 700, addresses this issue.

[0100] The following discussion sets out an example implementation of the methods 600, 700.

[0101] The example scenario discussed with reference to Figure 13 used QoE as an example KPI, however it will be appreciated that in general, each intent comes with multiple KPIs that are different in nature (e.g., latency, maximum bit rate, jitter).

[0102] The example implementation may include the following steps:

[0103] 1. Identify trigger condition for the intent (for example, intent insertion, intent update, intent degradation). (Step 610 / 710)

[0104] 2. Get the utility function and the compliance latency target of the intent (e.g., initial compliance latency target t=20s for the gaming example).

[0105] 3. Initialize paths PI with PI = {A} (i.e. , PI is a set of actions). PI is empty initially. Each path that is created afterward is associated with a: “path budget” that is initially equal to the compliance latency target (in the example, pbO = pb1 = pb2 = pb3 = 20s), and a “path utility” that is the sum of the intent management node utility over the path (that is the integral over time of all the utilities of intents managed by the intent management node. (Steps 630 / 730)

[0106] 4. The set of optimal paths P with P = {A} is initially empty.

[0107] 5. Build a sequence of actions satisfying the KPI target within the compliance latency target. (Steps 630, 640 / 730, 735, 740)

[0108] 5.1. Trigger proposal agents and get actions.

[0109] 5.2. Each proposed action is added to the path it belongs to or a path is created (initially, in the example, P0 ={A0}, P1={A1}, P2 = {A2}, P3 = {A3}).

[0110] 5.3. Predict the effect of actions on all the KPIs specified in all intents managed by the intent management node).

[0111] 5.4. Update path budget pbx = pbx - actionEffectTime (e.g., pbO of P0 = {A0} is updated to pbO = 20s -15s = 5s).

[0112] 5.5. Update path utility.

[0113] 5.6. Discard path Px in PI with pbx<= 0.

[0114] 5.7. If the KPI is reached by path Px add the path to the set of optimal paths and discard Px.

[0115] 5.8. If there are no paths, terminate the loop and return P.

[0116] 5.9. Create hypothetical issues for the non-discarded paths.

[0117] 5.10. Go to step 5.1.

[0118] At the end of execution of the above steps, for the example in Figure 13, the output will be A2 -> A4, that is P2 = {A2, A4} and A3 -> A5, that is P3 = {A3, A5}. Following the above implementation sequence, the intent management node may then choose from among feasible action paths by considering, on top of compliance latency targets (as the method above shows), undesirable states, and total utility maximization.

[0119] Rejecting intent or intent update

[0120] It will be appreciated that the subject intent, to which the trigger event relates, may be an intent managed by the intent management node, or an intent submitted to the intent management node for management. The subject intent may be a new intent, or the event may be updating of an already managed subject intent. According to TM Forum TR291 E, the following reporting can be used as a reason for intent or intent update rejections:

[0121] In order to perform the steps of the methods disclosed herein for a newly received intent or intent update, in some examples, the methods disclosed herein may be used to test in a “digital twin fashion” if the managed environment would be able to deal with such an update or new intent. If no sequence of actions in solution proposal (described and illustrated as paths in the above examples) can be found, then the intent management node may determine that the newly submitted intent or intent update cannot be accepted. Figure 14 shows an example of intent rejection after an intent update operation by the owner. In the example of Figure 14, the intent update is rejected because of compliance latency being too short, but similar sequence diagrams could be envisaged or other rejection reasons, as set out in the table above.

[0122] Example methods and nodes set out in the present disclosure enable intent management that considers not just an eventual end state for actions ensuring compliance with an intent, but also additional factors, including duration and severity of exposure to undesirable states before the end state is reached. By considering impact of solution proposals at a range of future time steps, example methods proposed herein allow action plan building based on multiple factors, including for example: compliance latency requirements, utility, avoiding unacceptable states and avoiding long exposure to undesirable states. This means resource utilization as well as customer experience can be improved through improved decision making and selection of optimal solutions for intent fulfilment. Reduced cost, reduced energy consumption, and improved quality of solutions may all be expected as consequences of implementation of the methods disclosed herein. In addition, example methods disclosed herein allow for intent rejection for intents that have too restrictive compliance latency targets (as envisioned in TM Forum TR291 E).

[0123] The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

[0124] It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims or numbered embodiments. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim or embodiment, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims or numbered embodiments. Any reference signs in the claims or numbered embodiments shall not be construed so as to limit their scope.

Claims

CLAIMS1 . A computer implemented method (600) performed by an intent management node in a communications network, wherein the intent management node is operable to manage intents for an environment of the communication network, the method comprising: detecting occurrence of an event in relation to a subject intent, wherein the subject intent is managed by or is submitted for management by the intent management node (610); obtaining solution proposals to ensure compliance with the subject intent (620); for each solution proposal (680) performing the following steps: for the subject intent and intents managed by the IM node, evaluating, at each of a plurality of future time steps between the time of the event and a termination time, a predicted utility of the intent following implementation of the solution proposal (630); generating, at each of the plurality of future time steps and based on the evaluated predicted utilities, an aggregated utility of the subject intent and intents managed by the IM node (640); generating a solution proposal score based on the aggregated utilities at the future time steps (650); selecting a solution proposal according to the generated solution proposal scores (660); and performing at least one of implementing the selected solution, sending a notification that the subject intent cannot be fulfilled, accepting the subject intent, or rejecting the subject intent (670).

2. A method as claimed in claim 1 , wherein selecting a solution proposal according to the generated solution proposal scores comprises: evaluating the solution proposals according to an evaluation criterion (760a); and wherein performing at least one of implementing the selected solution, sending a notification that the subject intent cannot be fulfilled, accepting the subject intent, or rejecting the subject intent, comprises performing at least one of those steps according to a result of the evaluation (770a).3 A method as claimed in claim 2, wherein evaluating the solution proposals according to an evaluation criterion comprises comparing (760b), for the solution proposals, at least one of: a predicted final aggregated utility for the solution proposals; a time spent in an undesirable utility state; a minimum value of aggregated utility; the generated solution proposal score.

4. A method as claimed in claim 3, wherein, for the solution proposals, comparing a minimum value of aggregated utility (760b) comprises at least one of: comparing minimum values of aggregated utility between solution proposals; and / or comparing the minimum value of aggregated utility for each proposal to a threshold value of aggregated utility below which the environment is considered to be in an unacceptable state.

5. A method as claimed in any one of the preceding claims, wherein generating a solution proposal score based on the aggregated utilities at the future time steps comprises: calculating the aggregated utility over time for a solution proposal (750a)6. A method as claimed in any one of the preceding claims, wherein generating a solution proposal score based on the aggregated utilities at the future time steps comprises: calculating the area between a graph of aggregated utility over time for a solution proposal and a threshold value of aggregated utility, below which the environment is considered to be in an undesirable state (750b).

7. A method as claimed in any one of the preceding claims, wherein for the subject intent and intents managed by the IM node, evaluating, at each of the plurality of future time steps, a predicted utility of the intent following implementation of the solution proposal comprises: predicting, at each of the plurality of future time steps, a value of one or more metrics specified in the intent following implementation of the solution proposal (730a); andcalculating a utility of the intent at each of the plurality of future time steps based on the predicted metric values (730b).

8. A method as claimed in any one of the preceding claims, further comprising: for the subject intent and intents managed by the IM node, at each future time step, checking for fulfilment of a pruning criterion; and if the pruning criterion is fulfilled, pruning the current solution proposal (735).

9. A method as claimed in claim 8, when dependent on claim 7, wherein for the subject intent and intents managed by the IM node, at each future time step, checking for fulfilment of a pruning criterion comprises performing at least one of: comparing a predicted value of a metric specified in the intent following implementation of the solution proposal to a threshold value of the metric specified in the pruning condition (736a); comparing a time elapsed since occurrence of the event to a latency budget specified in the pruning criterion (736b); comparing a safety risk measure to a threshold safety risk specified in the pruning condition (736c).

10. A method as claimed in claim 8 or 9, further comprising: if all obtained solution proposals are pruned, performing at least one of: rejecting the subject intent or sending a notification that the subject intent cannot be fulfilled (735a).

11. A method as claimed in any one of the preceding claims, wherein the termination time comprises at least one of (730c): a time at which the solution has been fully implemented; a time at which the subject intent has been fulfilled; a predefined time after the time of the event; a predetermined time after the subject intent has been fulfilled.

12. A method as claimed in any one of the preceding claims, wherein an event in relation to a subject intent, wherein the subject intent is managed by or is submitted for management by the intent management node, comprises at least one of (710b): receipt of a new intent submitted for management by the intent management node;receipt of a new intent submitted for evaluation by the intent management node; receipt of an update to an intent managed by the intent management node; a change in environment state causing an intent managed by the intent management node to no longer be fulfilled.

13. A method as claimed in any one of the preceding claims, wherein a solution proposal comprises at least one of (720a): an action for implementation in the environment; a plurality of actions for implementation in the environment; a series of actions for sequential implementation in the environment an intent for implementation in the environment; a plurality of intents for implementation in the environment.

14. A method as claimed in any one of the preceding claims, wherein an intent comprises a specification of expectations for the environment, the expectations including a target value of at least one metric describing performance of the environment (710c).

15. A method as claimed in any one of the preceding claims, wherein the environment comprises at least one of a cell of a communication network, a cell sector of a communication network, at least a part of a core network or transport network of a communication network, a slice of a communication network, or one or more other intent management node (710a).

16. A computer program product comprising a computer readable medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform a method as claimed in any one of claims 1 to 15.

17. An intent management node (800) operable to manage intents for an environment of a communication network, the intent management node comprising processing circuitry (802) configured to cause the intent management node to: detect occurrence of an event in relation to a subject intent, wherein the subject intent is managed by or is submitted for management by the intent management node; obtain solution proposals to ensure compliance with the subject intent;for each solution proposal, perform the following steps: for the subject intent and intents managed by the IM node, evaluate, at each of a plurality of future time steps between the time of the event and a termination time, a predicted utility of the intent following implementation of the solution proposal; generate, at each of the plurality of future time steps and based on the evaluated predicted utilities, an aggregated utility of the subject intent and intents managed by the IM node; generate a solution proposal score based on the aggregated utilities at the future time steps; select a solution proposal according to the generated solution proposal scores; and perform at least one of implementing the selected solution, sending a notification that the subject intent cannot be fulfilled, accepting the subject intent, or rejecting the subject intent.

18. An intent management node (800) as claimed in claim 17, wherein the processing circuitry is further configured to cause the intent management node to perform the step of any one of claims 2 to 15.

Images