Methods and apparatuses for enabling fulfilment of an intent in an intent driven network

Abstract

Embodiments described herein relate to methods and apparatuses for enabling fulfilment of an intent in an intent driven network. A method performed by an intent handler comprises receiving an indication of a first subintent of the intent from an intent owner, responsive to detecting a violation of the first subintent in an environment: attempting to reassure the first subintent in the environment; and indicating to the intent owner that the intent handler is attempting to reassure the first subintent.

Description

[0001] METHODS AND APPARATUSES FOR ENABLING FULFILMENT OF AN INTENT IN AN INTENT DRIVEN NETWORK

[0002] TECHNICAL FIELD

[0003] Embodiments described herein relate to methods and apparatuses for enabling fulfilment of an intent in an intent driven network.

[0004] BACKGROUND

[0005] Intent-driven networking is an attractive approach to achieve self-* capability in 5G and 6G networking (and beyond). As opposed to classical policy-based systems, intent- driven networks promise to require less development and validation effort, to provide better flexibility and adaptivity towards dynamic environments and lead to better user experience. Intents specify the system requirements and constraints in a declarative way, relying on functions that ensure the automatic configuration of resources so that these intents are fulfilled and assured (e.g. guaranteed). These functions are called intent management functions (IMFs).

[0006] Figure 1 illustrates a typical architecture of an IMF. An IMF may interact with an environment 101 to actuate changes (via actuator agents 102) and receive data (via data grounding agent 103). The IMF may then use a reasoner 104 to determine how to ensure assurance of the received intent within the environment 101. It will be appreciated that the environment may comprise a network such as a radio access network and / or one or more further IMFs.

[0007] Autonomous, intent-driven network management may utilise a federation of intent manager functions (IMF)

[0008] Figure 2 (taken from TMF IG1253), illustrates a federation of IMFs. This federation may be used to handle scalability and separation of administrative domains (e.g. business operations, service operations and resource operations). Note that the federation need not be hierarchical in general.

[0009] IMFs may have the role of either intent handler, intent owner or both. According to TMF921A, “the intent owner that will create the intent object and its expectations (requirements, goals and constraints) and the intent handler which will consider the expectations of the intent and adapt them to the specific domain and infrastructure it is responsible for The intent handler is also responsible for keeping the intent owner updated of the status of the intent via the intent reports."

[0010] In the federation of IMFs, some IMFs control a set of resources through configuration actions ensuring that the resulting behaviour satisfies the intent <D that the respective IMF is handling. As illustrated in Figure 3, there are also IMFs such as IMF 300 that have the role of both intent handler and intent owner for certain intents i.e., when IMF 300 is handling an intent <D submitted to it by an intent owner IMF, IMF 300 may either transform or decompose the intent to subintents (say, <Di, <t>2, ..) and sets them for the receiver IMFs (301 , 302 and 303) to handle. In this case, the decomposition may be dependent upon the proposal agents, specifically decomposition proposing agents that are registered with the IMF 300.

[0011] TM Forum standards [IG1253C] defines a set of Application Programming Interfaces (APIs) that the IMFs in the federation may use to interact with each other. The APIs that may be relevant for embodiments described herein are:

[0012] 1. Intent owners can set new intent or modify existing intent objects. This is achieved with the “SET” Procedure: SET <intent>

[0013] 2. The intent owner can withdraw an intent using the “REMOVE” procedure : REMOVE <intent object URI>

[0014] 3. The intent handler will use the “REPORT” procedure to send reports to the intent owner : REPORT <intent report>

[0015] During operation, each IMF may detect the possible violation of the intent <D that it is handling. This is done through monitoring the target KPI’s using grounding agents and evaluating the intents, and through the reports obtained from the IMFs to which the IMF 300 has delegated the subintents, and evaluating the intent <D.

[0016] In the example of Figure 4, there are 4 IMF’s handling various intents (or subintents) at different levels. The Service IMF 401 handles intents at the Service level and transforms the service level expectations to an intent at the OSS level handled by the OSS IMF 402.

[0017] In this example, there are two domains, the radio access network (RAN) and the Transport Network, each handled by respective IMF’s (403 and 404). The OSS IMF 402 therefore decomposes the OSS intent (Intent A) into subintents (Intent B and Intent C) that can be handled by RAN IMF 403 and Transport IMF 404 respectively. The RAN and Transport IMF’s configure the RAN and Transport environments to ensure that the subintents are assured.

[0018] All the IMFs are responsible for the assurance (or guarantee) of the intents submitted to them. When the intent is violated (in other words one or more of the requirements of the intent is no longer met in the environment), the IMFs are responsible for reassuring the intent (in other words, attempting to address the issue in the environment such that the one or more requirements are again met)

[0019] For example, for the RAN IMF 403 and Transport IMF 404, they may reconfigure the RAN / Transport resources for to enable reassurance of a subintent e.g., by allocating a greater number of PRB’s (physical resource blocks) and / or selecting a different route for the packets. In the case of OSS IMF 402, it may assure the intent (intent A) by performing re-decomposition of the intent A, e.g., allowing the RAN latency to be larger and correspondingly reducing the Transport latency to keep the overall latency within the end-to-end limits. Note that the decomposition depends upon solution agents that are capable of decomposition.

[0020] The IMFs report the status of the intents they are handling to the intent owner through the REPORT API. The reports can contain information about whether the intent is violated or not, and if it is violated, then the possible reason(s) behind the violation, what is the estimated time for reassurance in case of violation etc. The report information depends upon the report metamodels implemented in the IMF’s.

[0021] Note that the violation of subintents does not necessarily lead to the violation of the intent, hence evaluation of whether the overall intent is violated may be necessary. For example, an end-to-end latency expectation in an intent (L < 20) can be decomposed into latency expectations of (Lr< 3, Lt< 7) in the subintents for the domains RAN and Transport respectively. What this means is when the subintents are satisfied, the intent is also satisfied. However, there might be times when the RAN latency expectation is violated (say, Lr== 5), but the end-to-end latency expectation is still not violated. The OSS IMF can mitigate the RAN intent violation by setting a less stringent decomposition (Lr<= 5, Lt< 7), for example.

[0022] Figure 5 taken from IG1253C (TM Forum), illustrates the State machine of intent handling and intent operational state. Initially, all intents are at the “start” state and transit to “Received” when the intent is admitted by an intent handler, in some cases after negotiations between the intent owner and the intent handler. The intent may not be assured as soon as it is received because the necessary configurations are not done yet. Hence the state may move to the “DegradedlnitialHandling” state from which it can move into the “compliant” state indicating the intent is assured by the intent handler, or continue in the “DegradedlnitialHandling” state indicating the handler is not able to assure the intent. While in the “compliant” state, the intent may transit to the “degraded” state (e.g. if one or more requirements of the intent are no longer met) prompting the intent handler to attempt reassurance of the intent. From any of the states (received, compliant, Degraded), the intent may move to the “end” state if it is removed or updated by the intent owner.

[0023] SUMMARY

[0024] In some examples, a problem may arise during the standard operation of IMFs in a federation that can lead to suboptimal handling of intents.

[0025] The problem is exemplified in the following utilising the system of Figure 4 as an example. In the example of Figure 4 Intent A is owned by a service IMF 401 , and is handled by an OSS IMF 402. The OSS IMF 402 decomposes intent A into subintents Intent B and Intent C and delegates these subintents to the RAN IMF 403 and the Transport IMF 404 respectively.

[0026] Here, the OSS IMF 402 is the handler of Intent A and the owner of Intents B and C. the RAN IMF 403 and the Transport IMF 404 are the intent handlers of Intent B and Intent C respectively. When monitoring the status of Intent B, the RAN IMF 403 detects a violation of Intent B, and reports it to the intent owner, the OSS IMF 402. Further, it is assumed that when evaluating for violation of Intent A, the OSS IMF 402 finds a violation.

[0027] In Figure 4, when the Intent B is violated, leading to the violation of the Intent A as well, the RAN IMF 403 will try to reconfigure the PRBs (physical resource blocks) and scheduling methods to address the violation of intent B. Once intent B is assured, intent A will be assured. However, at the same time, the OSS IMF 402 may try to re-decompose intent A (leading to say, RAN latency <= 6, Transport Latency <= 4) which could be assured by the RAN IMF 403 and Transport IMF 404 in the current state of the network. So, if the new decomposition is set for RAN IMF 403, earlier reconfigurations done by RAN IMF 403 for intent B will be overridden. So even if the RAN IMF had found a good reconfiguration, it would be wasted and moreover, because of the re-decomposition, other parts of the network (in this case, Transport) would also be reconfigured which would be unnecessary and costly. On the other hand, if the RAN IMF 403 was allowed to find a reconfiguration with indefinite time, the RAN IMF 403 may not be able to find a valid reconfiguration to assure intent B and this may affect the performance of the network because intent A would also remain violated, which can cascade and ultimately affect the service level intent.

[0028] Currently therefore, in federated IMFs such as depicted in Figure 4 there may be a race between IMFs to assure an intent and a subintent which can lead to suboptimal handling of the intent.

[0029] According to some embodiments there is therefore provided a method, performed by an intent handler for enabling fulfilment of an intent in an intent driven network. The method comprises receiving an indication of a first subintent of the intent from an intent owner, responsive to detecting a violation of the first subintent in an environment: attempting to reassure the first subintent in the environment; and indicating to the intent owner that the intent handler is attempting to reassure the first subintent.

[0030] According to some embodiments there is provided a method, performed by an intent owner, for enabling fulfillment of an intent in an intent driven network. The method comprises transmitting an indication of a first subintent of the intent to an intent handler and receiving an indication that the first subintent has been violated from the intent handler. The method further comprises determining that the violation of the first subintent leads to violation of the intent; and responsive to receiving an indication from the intent handler that the intent handler is attempting to reassure the violation of the first subintent, refraining from attempting to reassure the intent.

[0031] According to some embodiments there is provided an intent handler for enabling fulfilment of an intent in an intent driven network. The intent handler comprises processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the intent handler is operable to: receive an indication of a first subintent of the intent from an intent owner, and responsive to detecting a violation of the first subintent in an environment: attempt to reassure the first subintent in the environment; and indicate to the intent owner that the intent handler is attempting to reassure the first subintent. According to some embodiments there is provided an intent owner for enabling fulfilment of an intent in an intent driven network. The intent owner comprises processing circuitry and a memory. The memory contains instructions executable by the processing circuitry whereby the intent owner is operable to: transmit an indication of a first subintent of the intent to an intent handler; receive an indication that the first subintent has been violated form the intent handler; determine that the violation of the first subintent leads to violation of the intent; and responsive to receiving an indication from the intent handler that the intent handler is attempting to reassure the violation of the first subintent, refrain from attempting to reassure the intent.

[0032] According to some embodiments there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods described above.

[0033] According to some embodiments there is provided a computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods described above.

[0034] According to some embodiments there is provided a computer program product comprising non transitory computer readable media having stored thereon a computer program as described above.

[0035] BRIEF DESCRIPTION OF THE DRAWINGS

[0036] For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0037] Figure 1 illustrates a typical architecture of an IMF;

[0038] Figure 2 illustrates a federation of IMFs;

[0039] Figure 3 illustrates a federation of IMFs;

[0040] Figure 4 illustrates an example of a federation of IMFs interacting with the radio access network and the transport network; Figure 5 illustrates the State machine of intent handling and intent operational state;

[0041] Figure 6 a flowchart illustrating a method performed by an intent handler for enabling fulfilment of an intent in an intent driven network;

[0042] Figure 7 illustrates a state machine of intent handling and intent operational state;

[0043] Figure 8 a flowchart illustrating a method performed by an intent owner, for enabling fulfillment of an intent in an intent driven network;

[0044] Figure 9 there is a chain of IMF’s A, B and C handling the intents 2,3respectively;

[0045] Figure 10 is a signalling diagram illustrating an example implementation of the method of Figures 6 and 8;

[0046] Figure 11 is a signalling diagram illustrating an example implementation of the method of Figures 6 and 8;

[0047] Figure 12 illustrates an exemplary Open Radio Access Network (O-RAN) compliant network 1200, according to some embodiments

[0048] Figure 13 illustrates an apparatus comprising processing circuitry or logic.

[0049] Figure 14 illustrates an intent handler according to some embodiments;

[0050] Figure 15 illustrates an intent owner according to some embodiments.

[0051] DETAILED DESCRIPTION

[0052] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0053] The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface may have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer- readable memory, such as (ROM, EEPROM, Flash memory, a memory disc, RAM etc.) solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0054] Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and / or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

[0055] Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. Particular embodiments are described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0056] As used herein, an intent may be interpreted as a formal specification of expectations including requirements, goals, and constraints given to a technical system, for example, as defined in the TMForum document IG1253. An intent may therefore purely be an expression of what needs to be achieved or avoided or what outcome is more or less preferred, rather than indicating how and by which strategies and actions this can be realized. In this respect, artifacts such as policies, workflows, rules, decision trees and other ways to express and implement a solution strategy, make decisions and execute actions are still very much-needed to realize intent driven autonomous systems. They are however strictly separated from the intent expression itself. This understanding of intent drives implementation of intent driven operation that strengthens important system design concepts such as a strong separation of concerns between sub-systems with full encapsulation of solution implementations.

[0057] An intent or subintent may be considered as a container for a set of expectations (or requirements) defined over certain measurable targets. When an intent owner delegates an intent to an intent handler e.g. via SET / PROBE API in TMF921A, the intent handler starts handling the intent after possibly certain negotiations as described in the standards.

[0058] An example of an intent as described in IG1253 (TM Forum) is given below. It will be appreciated that the syntax utilised to described intents may evolve and should not be considered limiting. The example below contains several expectations (e.g. requirements), including a SliceExpectation which specifies the requirement of having a Slice, a PropertyExpectation which specifies that the Slice should be either available or working (up), and MaxMetricExpectation specifying that the same slice should have a latency < 25 and a packet loss rate < 0.1 %. ope : Appl icationl ntentO O O l a imm : Intent ; rdfs : comment "Example intent with cus tomer app in telco cloud imm : has Expectation

[0059] [ a imm : SliceExpectation ; imm:target _:slice ; imm:params [ tel:useSlice cat : SliceOOOl ]

[0060] ] ,

[0061] [ a imm : PropertyExpectation ; imm:target _:slice ; imm:params [ sli : deploymentstate

[0062] [ a imm:oneOff rdf:value sli:up, s li : available ] ]

[0063] ] ,

[0064] [ a imm : SharingExpectation ; imm:target _:slice ; imm:params [ tel : sharingRestriction tel : sameCustomer ]

[0065] ] ,

[0066] [ a imm:MaxMetricExpectation ; imm:target _:slice ; imm:params [ tel: latency 25 ; tel : packetLoss 0.0001 ]

[0067] ] , . .

[0068] Intent extension models as in TR291 of TMF specifies additional optional information along with the intents that can be utilized by the IMFs for handling of intents. According to TR291,

[0069] “Extending the intent model means introducing new vocabulary to be used for the expression of intent and defining its semantics. The following tasks would be typical when creating intent extension models:

[0070] • New subclasses of expectation

[0071] • New parameters with typical properties

[0072] • New properties to be used in parameters as atomic compliance details

[0073] • New properties that qualify as compliance details

[0074] New properties introduce additional compliance qualifiers New Context classes

[0075] • New Information classes

[0076] • New properties of existing information classes. For example, extension intent management information

[0077] • New metrics classes as objects in icnrmetric statements

[0078] • New degradation reasons imo

[0079] • New rejection reasons imo “

[0080] In some embodiments, as will be described in more detail below with reference to Figures 6 and 7, new extensions are proposed to help coordinate the intent handling in federated IMFs. For example, the proposed extensions may be defined as a subclass of the Context (icm:Context) referred to herein as “CoordinationReq”.

[0081] The “CoordinationReq” subclass may, for example, comprise one or more of the following properties two properties:

[0082] 1) An atemptDuration A, which defines the time that can be taken by the intent handler to reassure intent in case of violation. When the attempt duration expires, the intent handler may autonomously stop attempting to reassure the intent and the intent owner may start taking a decision regarding possible redecomposition leading to a possibly different O.

[0083] 2) A set of conditions named attemptcondition, which define the conditions under which the intent handler is allowed to attempt to reassure the intent and inform the intent owner (e.g. through a report) if the current condition is not in the allowed set. This set of conditions may be updated by the intent owner depending upon the changing capability of the intent handlers. These conditions are similar to expectations (e.g. requirements) and are defined over certain targets that should be observable by the intent handler.

[0084] A possible syntax for the extensions described above is given below (assuming the default namespace and the namespaces co, icm and app). In this the intent: Intentl has expectations: E1 and E2, but also a new object: C1 of CoordinationReq which is a subclass of the Context class. C1 specifies the attempt duration and attempt conditions that are to be used by the IMF that is delegated to handle to Intentl .

[0085] : Intentl co : hasCoordinationReq : C1 hasExpectation : E1 j :E2 ;

[0086] :C1 a icm:CoordinationReq ; icm:AttemptDuration 20; icm: Attemptcondition :Cond1 , :Cond2,

[0087] The coordination requirements (attemptDuration and attemptcondition) can be modified statically or dynamically. For example, IG1253C allows dynamic modification of these requirements through the SET API. The modification may be triggered in different events such as the ones mentioned below:

[0088] 1 . Manual intervention because of expert knowledge.

[0089] 2. Automatic learning of estimates for reassurance.

[0090] 3. Change in handling capabilities of the IMF

[0091] The methods described herein may be performed by entities of an intent based network. Many types of network, or parts of a network, can be operated as intent based networks, including computer / server networks, telecommunication networks, such as radio access networks (RANs), Open RANs (O-RANs), 3rd Generation Partnership Project (3GPP) networks, etc.

[0092] Embodiments described herein provide extensions to the intent metamodel with new context information. These extensions may, for example, be implemented as a new subclass of the Context class in the TMF specification. The new subclass may define new properties, for example, a duration and a set of conditions specifying when reassurance may be carried out by an intent handler. These properties may be exploited through a protocol to ensure proper coordination between federated IMFs.

[0093] Some embodiments may implement two new states to manage the intent lifecycle: “Degraded&trying-to-reassure” and “Degraded&waiting-for-reassurance”. In the “Degraded&trying-to-reassure” state, the IMF may look for new solutions and may execute these solutions to try to reassure the violated intent. In the “Degraded&waiting- for-reassurance” state, the IMF knows that the intent is violated but also that another IMF is trying to reassure a subintent which might lead to the reassurance of the intent, hence the IMF may wait for a Report (success / failure / timeout) before taking appropriate actions.

[0094] Some embodiments described herein also utilise a protocol that exchanges state information between the IMFs using, for example, the Report API. The receipt of the messages causes the transition of the state of the intents and impacts the consequent handling of the intent by the intent handler IMF.

[0095] Figure 6 is a flowchart illustrating a method performed by an intent handler for enabling fulfilment of an intent in an intent driven network. The intent may be owned by an intent owner.

[0096] The method of Figure 6 will be described with reference to the state machine illustrated in Figure 7. It will however be appreciated that a different state machine may be utilized to implement the method of Figure 6.

[0097] The method of Figure 6 may be performed by an intent handler, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. An intent handler may comprise or be comprised within, for example, any suitable network node.

[0098] For example, the intent handler may comprise or be comprised within one of: a Management layer network node, a core network node, a transport network node, a network node in an O-RAN architecture; and an Service Management and Orchestration (SMO) - intent handler. The intent owner may comprise another intent handler or a network operator.

[0099] In step 601 the method comprises receiving an indication of a first subintent of the intent from an intent owner. It will be appreciated that an intent (or a subintent) may define the intent (or subintent), for example, in terms of one or more goal(s), objective(s), expectation(s), requirement(s) and / or constraint(s). As used herein, a “requirement” is considered to be any of a goal, objective, requirement, expectation, constraint etc. of an intent (or subintent). Similar to as described above with reference to the state machine in Figure 5, initially, all intents (or subintents) are initialised in the “start” state of the state machine of Figure 7, and the state machine moves to “received” when the (sub)intent is admitted by an intent handler (e.g. at step 601), potentially after certain negotiations between the intent handler and the intent owner.

[0100] In some embodiments, the method of Figure 6 comprises step 602 in which it is determined whether or not the first subintent is assured in the environment. It will be appreciated that the intent may not be assured as soon as it is received because the necessary configurations may not yet have been performed in the environment.

[0101] If the first subintent is not assured, the method passes to step 603 which comprises assuring the first subintent. In other words, the method of Figure 6 may comprise performing one or more actions in the environment to ensure that the one or more requirements of the first subintent are met. If step 603 is successful, the method may pass to step 604. If step 603 is unsuccessful, the method may pass to step 613 which comprises indicating to the intent owner than assurance of the first subintent has failed.

[0102] For example, the state machine of Figure 7 may move to the “DegradedlnitialHandling” state from which it can move to the “compliant” state once the first subintent is assured by the intent handler, or continue in the “DegradedlnitialHandling” state indicating the intent handler is not able to assure the first subintent.

[0103] If in step 602 it is determined that the first subintent is assured, the method may pass straight to step 604.

[0104] When the first subintent is assured, the state machine of Figure 7 may move to the “compliant”.

[0105] In step 604 the method may, for example, comprise detecting a violation of the first subintent in an environment. For example, the intent handler may detect that a requirement of the first subintent is no longer met in the environment. When violation of the first subintent is detected, the intent handler may indicate that the first subintent has been violated to the intent owner. Responsive to step 604, the method of Figure 6 may comprise performing one or more of steps 606, 607, 608 609.

[0106] In step 606, the method of Figure 6 comprises indicating to the intent owner that the intent handler is attempting to reassure the first subintent. By indicating to the intent owner that the intent handler is attempting to reassure the first subintent, this allows the intent owner to wait whilst the intent handler attempts to reassure the first subintent, before the intent owner starts attempting to reassure the intent.

[0107] In step 607 the method of Figure 6 comprises attempting to reassure the first subintent in the environment. For example, if the intent handler comprises a RAN IMF, step 607 may comprise reconfiguring the radio access network allocation of resources or scheduling in order to attempt to reassure the one or more requirements of the first subintent.

[0108] In some embodiments the method of Figure 6 may comprise receiving an indication of at least one first attempt condition from the intent owner. The at least one first attempt condition may comprise a property of the “CoordinationReq” subclass as described above. For example, the first attempt condition may comprise a condition that an observable parameter in the environment meets a threshold condition.

[0109] In these examples, the method of Figure 6 may only pass to step 606 if the at least one first attempt condition is met. The first attempt condition may be of two types: initial and during. An initial condition may be checked only at the beginning of the process (e.g. to enable the method to pass to step 606) but “during” conditions may be kept under supervision throughout the process of Figure 6. Any violation of a “during” condition may be immediately reported, and the method may cease attempting to reassure the first subintent. The at least one first attempt condition may also be dynamic. For example, depending upon the changing capability of the IMFs, the conditions can be updated by the intent owner.

[0110] For example, the method of Figure 6 may comprise step 608 in which it is determined whether or not the at least one attempt condition is met. If the at least one attempt condition is not met, the method may pass to step 609 which comprises responsive to the first attempt condition not being met, refraining from attempting to reassure the violation and indicating to the intent owner that the intent handler is not attempting to reassure the first subintent. In this example, the state machine of Figure 7 passes straight from the “compliant” state to the “end” state after the violation is detected.

[0111] In some embodiments (although not all embodiments), the intent handler may only attempt to reassure the first subintent for a particular period of time. For example, the method of Figure 6 may in some examples, further comprise receiving an indication of a first attempt duration from the intent owner.

[0112] In some examples, the method of Figure 6 may only pass to step 606 if the received first attempt duration meets a duration condition. For example, the first attempt duration may be required to be greater than 0 s.

[0113] For example, the method of Figure 6 may comprise step 610 in which it is determined whether or not the first attempt duration meets the duration condition. If the first attempt duration does not meet the duration condition (e.g. first attempt duration ==0), the method may pass to step 609 which, as described above comprises refraining from attempting to reassure the violation and indicating to the intent owner that the intent handler is not attempting to reassure the first subintent. In this example, the state machine of Figure 7 passes straight from the “compliant” state to the “end” state after the violation is detected.

[0114] In some examples, where a first attempt duration is received from the intent owner, if the attempt to reassure in step 607 is not successful, the method may also comprise step 611 in which it is determined whether or not the first attempt duration has expired. If the first attempt duration has not expired, the method may perform step 607 again, and in some examples may return to 608 to confirm that the one or more conditions are still met. .

[0115] However, responsive to the first attempt duration expiring whilst attempting to reassure the first subintent, the method of Figure 6 may pass to step 613. In this example, step 613 comprises one or more of ceasing attempting to reassure the violation and transmitting a time out indication to the intent owner indicating that the first attempt duration expired whilst attempting to reassure the first subintent.

[0116] For example, at step 604 the state machine of Figure 7, instead of moving to the “degraded” state illustrated in Figure 5, may move to the “Degraded&&trying-to- reassure” state in which the intent handler performs at least steps 606 and 607 (and optionally steps 608 to 613).

[0117] Responsive to successfully reassuring the first subintent in step 607, the method passes to step 612 which comprises transmitting a success indication to the intent owner indicating that the violation has been successfully reassured. For example, once the first subintent has been successfully reassured, may return to the “compliant” state.

[0118] Responsive to failing to reassure the first subintent in step 607 (or the first attempt duration expiring in step 611), the method passes to step 613 which comprises transmitting a failure indication to the intent owner indicating that the violation has not been reassured. For example, if reassurance of the first subintent fails, the state machine of Figure 7 may move to the “end” state. In the end state, the intent handler essentially discards the current first subintent and waits for a new solution.

[0119] In some examples, the intent handler performing the method of Figure 6 may have the role of both intent handler and intent owner. For example, the intent handler may handler the first subintent by generating further subintents as owner of the first subintent for subsequent IMFs.

[0120] For example, the method of Figure 6 may further comprise delegating at least part of the first subintent to a second intent handler. Here a part of the first subintent may be considered a further subintent of the first subintent. For example, the delegating may comprise transmitting an indication of the part of the first subintent, thiA.i , to the second intent handler. It will be appreciated, that as owner of the part of the first subintent, thiA.i , the intent handler may perform the method of Figure 8 for the first subintent, where the part of the first subintent is the “subintent” of the first subintent.

[0121] In this case, the intent handler may obey certain additional constraints for generating the parts of the first subintent (e.g. further subintents) so that the coordination protocol works in a coherent manner.

[0122] Similarly to as described above, the intent handler may transmit an indication of a second attempt duration to the second intent handler. The second attempt duration may be how long the second intent handler is allowed to attempt to reassure the part of the first subintent for. The second attempt duration may be shorter than the first attempt duration. By having the second attempt duration be shorter than the first attempt duration the situation illustrated in Figure 9 may be avoided.

[0123] In Figure 9, there is a chain of IMF’s A, B and C handling the intents1,2,3respectively. The intent2is associated with an attempt duration of 5s and the intent3is associated with an attempt duration of 10s.

[0124] If this happened scenario were to occur, then while the IMF C is trying to reassure the intent3, after the expiry of 6s, the attempt duration associated with2times out, which triggers IMF A to reassure This leads to a race between IMFs A and C. By constraining the durations to be progressively lesser, this situation is avoided.

[0125] In some examples, when the first attempt duration is set to 0 for the first subintent, the second attempt duration for the subsequent part of the first subintent is also set to 0. This implies that the protocol forces Report(failure) upwards to the intent owner of the first subintent as soon as the first subintent or the part of the first subintent fails.

[0126] In some examples, the method of Figure 6 further comprises transmitting at least one second attempt condition to the second intent handler, wherein each at least one second attempt corresponds to one of the at least one first attempt condition.

[0127] In other words, any second attempt conditions (attemptconditions) that are attached to the parts of the first subintent are dependent upon the logic and knowledge related to intent handling in the intent handler. However, similar to attemptDuration, attemptconditions AC_s attached to the parts of subintents should be such that every AC_s must imply at least one condition in AC_i of the first subintent. This implies that if AC_i is empty, then the attemptconditions for the subintents also must be empty.

[0128] When the attemptcondition is Empty, the subintent handlers are not allowed to handle the failure of the subintent. At a failure of the subintent , the handler immediately sends the failure report to the subintent owner.

[0129] Figure 8 is a flowchart illustrating a method performed by an intent owner, for enabling fulfillment of an intent in an intent driven network. The intent may be owned by the intent owner. The method of Figure 8 will be described with reference to the state machine illustrated in Figure 7. It will however be appreciated that a different state machine may be utilized to implement the method of Figure 8.

[0130] The method of Figure 8 may be performed by an intent owner, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. An intent owner may comprise or be comprised within, for example, any suitable network node.

[0131] For example, the intent owner may comprise or be comprised within one of: a Management layer network node, a core network node, a transport network node, a network node in an O-RAN architecture; and an SMO - intent handler. The intent owner may comprise an intent handler or a network operator.

[0132] In step 801 the method comprises transmitting an indication of a first subintent of the intent to an intent handler. It will be appreciated that the intent owner may have decomposed or transformed the intent into a plurality of subintents, each to be handled by different intent handlers. Step 801 may be considered to correspond to step 601 of Figure 6.

[0133] In some examples, step 801 may further comprise transmitting an indication of at least one first attempt condition to the intent handler and / or a first attempt duration to the attempt hander.

[0134] Similarly to as described above with reference to the state machine in Figure 5, initially, all intents (or subintents) are initialised in the “start” state of the state machine of Figure 7, and the sate machine moves to “received” when the (sub)intents are admitted by intent handlers (e.g. at step 601), potentially after certain negotiations between the intent handlers and the intent owner. Once the subintents are assured, this may be indicated to the intent owner. If all subintents of the intent are assured, the intent as a whole is assured, and therefore the state machine of Figure 7 moves to the “compliant” state.

[0135] In step 802 the method comprises receiving an indication that the first subintent has been violated form the intent handler. In step 803, the method may then comprise determining whether the violation of the first subintent leads to violation of the intent (for example as described above). If the intent is not violated, the method may pass to step 804 in which it is determined that the intent remains assured. In this example, the state machine of Figure 7 may remain in the “compliant” state.

[0136] If it is determined that the violation of the first subintent leads to violation of the intent the method may pass to step 805 in which it may be determined whether the intent handler is attempting to reassure the first subintent. The determination of step 805 may be made based on the receipt of an indication from the intent handler, for example the indications of steps 609 or 606.

[0137] Responsive to receiving an indication from the intent handler that the intent handler is not attempting to reassure the first subintent (e.g. an indication that at least one first attempt condition is not met, or an indication that the first attempt duration did not meet a duration criterion) the method may pass to step 806 in which the intent owner attempts to reassure the intent. In this example, the state machine of Figure 7 may pass straight from “compliant” to “Degraded&attempting-to-reassure”.

[0138] It will be appreciated that in reassuring the intent, the intent owner may reconfigure how the plurality of subintents are determined and may therefore re-decompose the intent and re-issue new subintents to the intent handlers.

[0139] Responsive to receiving an indication from the intent handler that the intent handler is attempting to reassure the violation of the first subintent, the method of Figure 8 may pass to step 807 which comprises refraining from attempting to reassure the intent. In this example, the state machine of Figure 7 may pass from “compliant” to “Degraded&waiting-for-reassurance”.

[0140] The method then passes to step 808 in which it may be determined whether the first attempt duration has expired, or a failure indication has been received. In some examples, the intent owner may itself keep track of the expiry of the first attempt duration, for example from receive of the indication that the first subintent has been violated. In other examples, the intent owner may be told, e.g. in a time out indication, that the first attempt duration has expired whilst the intent handler was attempting to reassure the first subintent, for example, as in step 613 of Figure 11 after having performed step 611. In other examples, the intent handler may be able to determine that it will not be able to reassure the first subintent and may then transmit a failure indication.

[0141] Responsive to receiving a failure indication from the intent handler indicating that the violation of the first subintent has not been reassured or responsive to the first attempt duration expiring, the method may pass to step 806 which comprises attempting to reassure the intent.

[0142] If no failure indication has been received, and the first attempt duration has not expired, the method may pass to step 809 in which it is determined whether a success indication that the first subintent has been successfully reassured has been received. If no success indication has been received, the method may return to step 808.

[0143] However, responsive to receiving a success indication, the method may pass to step 810 in which it is determined that the intent is reassured. In this example, the state machine of Figure 7 may return to the “Compliant” state.

[0144] Figure 10 is a signalling diagram illustrating an example implementation of the method of Figures 6 and 8.

[0145] In this example, the intent handler 1000 outputs configuration actions for the underlying resource layer and detects the violation of the intent (say, intent B) based on data collected from the grounding agent 1050, e.g. values of the target APIs.

[0146] In step 1001 the intent owner 1100 indicates the subintent, Intent B, to the intent handler 1000. Intent B is a subintent of the intent, Intent A. Step 1001 may comprise an example implementation of step 601 of Figure 6 and 801 of Figure 8. In this example in step 1001 the intent owner 1100 also indicates the coordination context properties attemptDuration and attemptcondition associated with the Intent B to the intent handler 1000.

[0147] In step 1002, the intent handler 1000 stores the coordination context properties attemptDuration and attemptcondition in the knowledge base.

[0148] In step 1003, the intent handler 1000 receives data from or via the grounding agent 1050. It will be appreciated that in some examples, the grounding agent 1050 forms part of the intent handler 1000. It will be appreciated that the data may comprise any information (e.g. measurements associated with relevant KPIs) relevant to determining whether or not one or more requirements of the Intent B are being met in the environment.

[0149] During the assurance loop, if the intent B remains satisfied (e.g. according to the grounding data received in step 1003), there is nothing to be done (as indicated in step 1004.

[0150] If, however, the Intent B is violated, the intent handler 1000 determines, in step 1005, whether the attemptDuration meets the duration condition and the attemptcondition is met. Step 1005 comprises an example implementation of steps 608 and 610.

[0151] If both the duration condition and the attemptcondition are met, the intent handler indicates, in step 1006, to the intent owner 1100 that the intent handler 1000 is attempting to reassure the Intent B. Step 1006 comprises an example implementation of step 606 of Figure 6 or step 805 of Figure 8. In response to receiving the indication of step 1006, the intent owner 1100 will refrain from attempting to reassure the intent (e.g. as described with respect to step 807 of Figure 8.

[0152] In step 1007 the intent handler 1000 attempts to reassure the Intent B. Step 1007 comprises an example implementation of step 607 of Figure 6.

[0153] If step 1007 is successful, the intent handler 1000 transmits a success indication to the intent owner in step 1008. Step 1008 comprises an example implementation of step 612 of Figure 6 or step 809 of Figure 8.

[0154] If step 1007 is unsuccessful (e.g. the Intent B cannot be reassured or the attemptDuration expires), the intent handler 1000 transmits a failure indication to the intent owner in step 1009. Step 1009 comprises an example implementation of step 613 of Figure 6 or step 808 of Figure 8.

[0155] When the intent owner 1100 receives the failure indication, the intent owner 1100 attempts to reassure intent A in step 1010. Step 1010 comprises an example implementation of step 806 of Figure 8. In this example, the intent owner 1100 succeeds in reassuring Intent A in step 1010, and indicates a new subintent, Intent B’ to the intent handler in step 1011. If either of the duration condition or the attemptcondition is not met, in step 1005, the intent handler, in step 1012 enters the end state and indicates to the intent owner 1100 that it is not attempting to reassure the Intent B. Step 1012 comprises an example implementation of step 609.

[0156] When the intent owner 1100 receives the indication of step 1012, the intent owner 1100 attempts to reassure intent A in step 1013. Step 1013 comprises an example implementation of step 806 of Figure 8. In this example, the intent owner 1100 succeeds in reassuring Intent A in step 1013, and indicates a new subintent, Intent B’ to the intent handler in step 1014.

[0157] Figure 11 is a signalling diagram illustrating an example implementation of the method of Figures 6 and 8.

[0158] In this example, the intent handler 1000 either transforms or decomposes the subintent (intent B) and the further subintents (e.g. intent B1 , Intent B2 etc) are handled and reported by subsequent IMFs (1150).

[0159] In step 1101 the intent owner 1100 indicates the subintent, Intent B, to the intent handler 1000. Intent B is a subintent of the intent, Intent A. Step 1001 may comprise an example implementation of step 601 of Figure 6 and 801 of Figure 8. In this example in step 1101 the intent owner 1100 also indicates the coordination context properties attemptDuration and attemptcondition associated with the Intent B to the intent handler 1000.

[0160] In step 1102, the intent handler 1000 stores the coordination context properties attemptDuration and attemptcondition in the knowledge base.

[0161] In step 1103, the intent handler 1000 indicates the further subintents of Intent B (e.g. Intent B1 , Intent B2, etc) to the subsequent IMFs 1150 respectively.

[0162] In step 1104, the intent handler 1000 receives an indication that at least one further subintent has been violated. If the subsequent IMF for the at least one further subintent has indicated that it is trying to reassure the further subintent, then the intent handler 1000 will wait until either a success indication or a failure indication has been received from the subsequent IMF before proceeding. If all a success indication is received for the at least one further subintent that was violated, the intent handler 1000 may indicate in step 1106 that the Intent B is successfully maintained to the intent owner 1100.

[0163] However, if at least one report for the at least one further subintent is a failure indication, the intent handler 1000 determines, in step 1106, whether the attemptDuration meets the duration condition and the attemptcondition is met. Step 1106 comprises an example implementation of steps 608 and 610.

[0164] If both the duration condition and the attemptcondition are met, the intent handler indicates, in step 1107, to the intent owner 1100 that the intent handler 1000 is attempting to reassure the Intent B. Step 1107 comprises an example implementation of step 606 of Figure 6 or step 805 of Figure 8. In response to receiving the indication of step 1107, the intent owner 1100 will refrain from attempting to reassure the intent (e.g. as described with respect to step 807 of Figure 8).

[0165] In step 1108 the intent handler 1000 attempts to reassure Intent B. In this example step 1108 may comprise re-decomposing or transforming Intent B into different further subintents. Step 1108 comprises an example implementation of step 607 of Figure 6.

[0166] If step 1108 is successful, the intent handler 1000 transmits a success indication to the intent owner in step 1109. Step 1008 comprises an example implementation of step 612 of Figure 6 or step 809 of Figure 8.

[0167] If step 1108 is unsuccessful (e.g. the Intent B cannot be reassured or the attemptDuration expires), the intent handler 1000 transmits a failure indication to the intent owner in step 1110. Step 1110 comprises an example implementation of step 613 of Figure 6 or step 808 of Figure 8.

[0168] When the intent owner 1100 receives the failure indication, the intent owner 1100 attempts to reassure intent A in step 1011. Step 1011 comprises an example implementation of step 806 of Figure 8. In this example, the intent owner 1100 succeeds in reassuring Intent A in step 1011 , and indicates a new subintent, Intent B’ to the intent handler in step 1012. If either of the duration condition or the attemptcondition is not met, in step 1106, the intent handler, in step 1113 enters the end state and indicates to the intent owner 1100 that it is not attempting to reassure the Intent B. Step 1113 comprises an example implementation of step 609.

[0169] When the intent owner 1100 receives the indication of step 1113, the intent owner 1100 attempts to reassure intent A in step 1114. Step 1114 comprises an example implementation of step 806 of Figure 8. In this example, the intent owner 1100 succeeds in reassuring Intent A in step 1114, and indicates a new subintent, Intent B’ to the intent handler in step 1115.

[0170] Figure 12 illustrates an exemplary Open Radio Access Network (O-RAN) compliant network 1200, according to some embodiments. As shown in Figure 12, O-RAN compliant network 1200 includes intent owner 1205 and service management and orchestration (SMO) component 1210. Intent owner 1205 is coupled to SMO component 1210 through intent interface (l / F) 1202 to network node 1215. In some embodiments, intent owner 1205 communicates intents to network node 1215 through intent interface 1202.

[0171] In some embodiments, as shown in Figure 12, O-RAN compliant network 1200 includes a near real-time RAN intelligent controller (RIC) 1220 coupled to one or more nodes that can operate an open interface between two end points (e.g., E2 interface). For example, near real-time RIC 1220 is coupled to O-RAN E2 nodes O-eNB 1222, CLI-CP 1224, CU- UP 1226 and DU 1225. In some embodiments, O-RAN E2 nodes O-eNB 1222, CU-CP 1224, CU-UP 1226 and DU 1225 are implemented in a virtualization environment (described in further detail below) in which one or more network functions for O-RAN compliant network 1200 are virtualized. In one embodiment, the virtualization environment (e.g., O-RAN compliant network 1200) includes O-Cloud computing platform 1235. In some embodiments, O-Cloud computing platform 1235 is implemented by SMO component 1210 via an O-2 interface defined by the O-RAN Alliance or comparable technologies.

[0172] In some embodiments, near real-time RIC 1220 separates functions of the O-RAN compliant network 1200 into a centralized unit (e.g., CU-CP 1224 and CU-UP 1226) and a distributed unit (e.g., DU 1225 and RU 1230). In some embodiments, the physical layer for O-RAN compliant network 1200 is split with the lower part of the physical layer running in a radio unit (e.g., RU 1230) and the upper part of the physical layer running in a distributed unit (e.g., DU 1225). In some embodiments, as shown in Figure 12, the centralized unit (CU) is split into a centralized unit control plane (CU-CP 1224) and a centralized unit user place (CU-UP 1226). In some embodiments, RU 1230 is a physical appliance and O-eNb 1222, CU-UP 1224, CU-UP 1226, and / or DU 1225 are either physical appliances or virtualized instances running over an O-cloud layer (e.g., O-cloud 1235). In some embodiments, a next generation (NG) core is communicatively connected to CU-UP 1224, CU-CP 1226, DU 1225, and RU 1230.

[0173] In some embodiments, O-RAN compliant network 1200 includes interfaces 01 , A1 , 02, Xn (e.g., Xn-c and XN-u), and NG (e.g., NG-c and NG-u) interfaces as shown. Although intent interface 1202 is illustrated as communicating only with SMO component 1210, examples herein are not so limited. For example, in some embodiments, network node 1215 of SMO component 1210 is coupled with near real-time RIC 1220 via an intent interface (e.g., intent interface 1202). In some embodiments, network node 1215 is a part of near real-time RIC 1220. For example, network node 1215 is located inside near real-time RIC 1220 and coupled with CU-CP 1224, CU-UP 1226, DU 1225, and / or RU 1230 via an intent interface (e.g., intent interface 1202).

[0174] It will be appreciated that the network node 1215 may comprise an intent handler for intents provided by the intent owner 1205. However, the network node 1215 may also act as an intent owner for subintents handlers by for example, the O-eNB 1222, or the CU-CP 1224 or the CU-UP 1226.

[0175] Figure 13 illustrates an apparatus 1300 comprising processing circuitry (or logic) 1301. The processing circuitry 1301 controls the operation of the apparatus 1300 and can implement the method described herein in relation to an apparatus 1300. The processing circuitry 1301 can comprise one or more processors, processing units, multicore processors or modules that are configured or programmed to control the apparatus 1300 in the manner described herein. In particular implementations, the processing circuitry 1301 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the apparatus 1300. It will be appreciated that the apparatus 1300 may comprise one or more virtual machines running different software and / or processes. The apparatus 1300 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes. Optionally, the apparatus 1300 may comprise a memory 1303. In some embodiments, the memory 1303 of the apparatus 1300 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1301 of the apparatus 1300 whereby the apparatus is operable to perform the method as described with reference to any one or more of Figures 6 and 8.

[0176] Alternatively or in addition, the memory 1303 of the apparatus 1300, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1301 of the apparatus 1300 may be configured to control the memory 1303 of the apparatus 1300 to store any requests, resources, information, data, signals, or similar that are described herein

[0177] In some embodiments, the apparatus 1300 may optionally comprise a communications interface 1302. The communications interface 1302 of the apparatus 1300 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1302 of the apparatus 1300 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1301 of apparatus 1300 may be configured to control the communications interface 1302 of the apparatus 1300 to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 1302 can use any suitable communication technology.

[0178] The apparatus 1300 may be configured operate in the manner described herein in respect of an intent handler and / or an intent owner.

[0179] Figure 14 is a block diagram illustrating an intent handler 1400 according to some embodiments. The intent handler 1400 comprises a receiving module 1402 configured to receive an indication of a first subintent of the intent from an intent owner. The intent handler 1400 further comprises an attempting module 1404 configured to responsive to detecting a violation of the first subintent in an environment, attempt to reassure the first subintent in the environment. The intent handler 1400 further comprises an indicating module 1406 configured to indicate to the intent owner that the intent handler is attempting to reassure the first subintent. The intent handler 1400 may operate in the manner described herein in respect of an intent handler.

[0180] Figure 15 is a block diagram illustrating an intent owner 1500 according to some embodiments. The intent owner 1500 comprises a transmitting module 1502 configured to transmit an indication of a first subintent of the intent to an intent handler. The intent owner 1500 further comprises a receiving module 1504 configured to receive an indication that the first subintent has been violated form the intent handler. The intent owner 1500 further comprises a determining module 1506 configured to determine that the violation of the first subintent leads to violation of the intent. The intent owner 1500 further comprises a refraining module 1508 configured to responsive to receiving an indication from the intent handler that the intent handler is attempting to reassure the violation of the first subintent, refrain from attempting to reassure the intent.

[0181] The intent owner 1500 may operate in the manner described herein in respect of an intent owner.

[0182] There is also provided a computer program comprising instructions which, when executed on a least one processor (such as the processing circuitry 1301 of the apparatus 1300 described earlier), cause the processor to carry out at least part of the method(s) described herein. According to some embodiments there is provided a carrier containing the computer program. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable medium. There is also provided a (for example, tangible and / or non-transient) computer-readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to perform at least part of the method(s) described herein.

[0183] Embodiments described herein enable efficient coordination of IMFs (e.g. intent owners and handlers) to handle the assigned intents and rectify the violations. In particular, embodiments described herein may be utilised to address the race condition that can lead to either costly reconfigurations or delays in handling the intents in the IMF federation.

[0184] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “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. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1 . A method, performed by an intent handler for enabling fulfilment of an intent in an intent driven network, the method comprising: receiving an indication of a first subintent of the intent from an intent owner, responsive to detecting a violation of the first subintent in an environment: attempting to reassure the first subintent in the environment; and indicating to the intent owner that the intent handler is attempting to reassure the first subintent.

2. The method as claimed in claim 1 further comprising, responsive to successfully reassuring the first subintent, transmitting a success indication to the intent owner indicating that the first subintent has been successfully reassured.

3. The method as claimed in claim 1 or 2 further comprising: responsive to failing to reassure the first subintent, transmitting a failure indication to the intent owner indicating that the first subintent has not been reassured.

4. The method as claimed in any previous claim further comprising: receiving an indication of a first attempt duration from the intent owner, and responsive to the first attempt duration expiring whilst attempting to reassure the first subintent, ceasing attempting to reassure the first subintent.

5. The method as claimed in claim 4 further comprising: responsive to the first attempt duration expiring whilst attempting to reassure the first subintent, transmitting a time out indication to the intent owner indicating that the first attempt duration expired whilst attempting to reassure the first subintent.

6. The method as claimed in claim 4 or 5 further comprising: responsive to determining that the first attempt duration does not meet a duration condition, refraining from attempting to reassure the firstsubintent and indicating to the intent owner that the intent handler is not attempting to reassure the first subintent.

7. The method as claimed in any preceding claim further comprising: receiving an indication of at least one first attempt condition from the intent owner; and performing attempting to reassure the first subintent responsive to the at least one first attempt condition being met.

8. The method as claimed in claim 7 wherein the first attempt condition comprises a condition that an observable parameter in the environment meets a threshold condition.

9. The method as claimed in claim 7 or 8 further comprising: responsive to the first attempt condition not being met, refraining from attempting to reassure the first subintent and indicating to the intent owner that the intent handler is not attempting to reassure the first subintent.

10. The method as claimed in any preceding claim further comprising: delegating at least part of the first subintent to a second intent handler.

11. The method as claimed in claim 10 wherein delegating comprises: transmitting an indication of the part of the first subintent to the second intent handler.

12. The method as claimed in claim 11 when dependent on claim 4, wherein delegating further comprises: transmitting an indication of a second attempt duration to the second intent handler, wherein the second attempt duration is shorter than the first attempt duration.

13. The method as claimed in claim 11 or 12 when dependent on claim 7 further comprising: transmitting at least one second attempt condition to the second intent handler, wherein each at least one second attempt corresponds to one of the at least one first attempt condition.

14. A method, performed by an intent owner, for enabling fulfillment of an intent in an intent driven network, the method comprising: transmitting an indication of a first subintent of the intent to an intent handler; receiving an indication that the first subintent has been violated from the intent handler; determining that the violation of the first subintent leads to violation of the intent; and responsive to receiving an indication from the intent handler that the intent handler is attempting to reassure the violation of the first subintent, refraining from attempting to reassure the intent.

15. The method as claimed in claim 14 further comprising: responsive to receiving a failure indication from the intent handler indicating that the violation of the first subintent has not been reassured, attempting to reassure the intent.

16. The method as claimed in claim 15 further comprising, responsive to the intent handler successfully reassuring the first subintent, receiving a success indication indicating that the first subintent has been successfully reassured.

17. The method as claimed in claim 16 further comprising: responsive to receiving the success indication, determining that the intent has been reassured.

18. The method as claimed in any one of claims 14 to 17, further comprising: transmitting an indication of a first attempt duration to the intent handler.

19. The method as claimed in claim 18 further comprising: responsive to the first attempt duration expiring, attempting to reassure the intent.

20. The method as claimed in claim 18 or 19, further comprising:responsive to receiving a time out indication indicating that the first attempt duration expired whilst the intent handler was attempting to reassure the first subintent, attempting to reassure the intent.

21. The method as claimed in any one of claims 18 to 20 further comprising: responsive to receiving an indication that the first attempt duration did not meet a duration criterion, attempting to reassure the intent.

22. The method as claimed in any one of claims 14 to 21 , further comprising: transmitting an indication of at least one first attempt condition to the intent handler.

23. The method as claimed in claim 22 wherein the at least one first attempt condition comprises a condition that an observable parameter in the environment meets a threshold condition.

24. The method as claimed in claim 22 or 23, further comprising: responsive to receiving an indication that the at least one first attempt condition is not met, attempting to reassure the intent.

25. An intent handler for enabling fulfilment of an intent in an intent driven network, the intent handler comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the intent handler is operable to: receive an indication of a first subintent of the intent from an intent owner, responsive to detecting a violation of the first subintent in an environment: attempt to reassure the first subintent in the environment; and indicate to the intent owner that the intent handler is attempting to reassure the first subintent.

26. The intent handler as claimed in claim 25 wherein the memory further contains instructions executable by the processing circuitry whereby the intent handler is operable to perform the method as claimed in any one of claims 2 to 13.

27. An intent owner for enabling fulfilment of an intent in an intent driven network, the intent owner comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the intent owner is operable to: transmit an indication of a first subintent of the intent to an intent handler; receive an indication that the first subintent has been violated form the intent handler; determine that the violation of the first subintent leads to violation of the intent; and responsive to receiving an indication from the intent handler that the intent handler is attempting to reassure the violation of the first subintent, refrain from attempting to reassure the intent.

28. The intent owner as claimed in claim 27 wherein the memory further contains instructions executable by the processing circuitry whereby the intent handler is operable to perform the method as claimed in any one of claims 15 to 24.

29. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of claims 1 to 24.

30. A computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 24.

31. A computer program product comprising non transitory computer readable media having stored thereon a computer program according to claim 29.

Images