[go: up one dir, main page]

WO2025063904A1 - Garanties dans un réseau basé sur l'intention - Google Patents

Garanties dans un réseau basé sur l'intention Download PDF

Info

Publication number
WO2025063904A1
WO2025063904A1 PCT/TR2023/050973 TR2023050973W WO2025063904A1 WO 2025063904 A1 WO2025063904 A1 WO 2025063904A1 TR 2023050973 W TR2023050973 W TR 2023050973W WO 2025063904 A1 WO2025063904 A1 WO 2025063904A1
Authority
WO
WIPO (PCT)
Prior art keywords
intent
node
guaranteed
requirement set
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/TR2023/050973
Other languages
English (en)
Inventor
Elham Dehghan Biyar
Snigdha DAS
Mirko D'ANGELO
Jörg NIEMÖLLER
Marin ORLIC
Nanjangud Chandrasekhara Swamy NARENDRA
Andrey José TORRES DA SILVA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to PCT/TR2023/050973 priority Critical patent/WO2025063904A1/fr
Publication of WO2025063904A1 publication Critical patent/WO2025063904A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • This disclosure relates to operating an intent owner node and an intent handler node in an intent based network, and in particular to techniques for improving intent based operation to provide a guarantee for an intent.
  • autonomous domains As outlined in the TM Forum’s Autonomous Networks Reference Architecture (IG1251), the need for intent-driven interfaces that can be used at all operational layers is imperative to achieve decoupled and autonomous functional blocks, termed autonomous domains.
  • TMForum defines the set of operations that should be offered to manage intent and intent-driven interactions in a consistent manner.
  • API Intent Application Programming Interface
  • Intent negotiation refers to communication between an intent owner and intent handler regarding the feasibility of requirements.
  • An intent may be sent for operation or for evaluation. Setting an intent means that it is sent for operation. This means that the intent handler node is expected to act and meet the requirements as specified in the intent with the resources it controls.
  • An intent may also be sent for exploration, which is also referred to as probing. This means that the intent handler node is not expected to meet the requirements specified in the intent, but it is expected to report on potential results if it were trying to meet the requirements. This is the basis for intent negotiation ahead of setting an intent for operation.
  • the BEST procedure is described in “TM Forum TR291 C - Proposal of Best Intent Model v1 .1 .0”.
  • the BEST procedure allows an intent owner to mark certain requirements in an intent, asking the intent handler node to report the most challenging requirement level for this requirement it would be able to successfully fulfil. This can be done for an intent that is probed as well as for an intent that is set and is actually being fulfilled.
  • the intent owner node uses the BEST procedure to explore what the intent handler node is able to do for these marked requirements given that all the other requirements of the intent also apply.
  • the intent handler node then communicates its proposals through an intent report.
  • an intent owner node can only explore the feasibility and outcome of an intent.
  • the intent handler node can only provide an answer that reflects a best effort estimate at the point in time that answer is calculated. There is no certainty provided that this answer holds at any later point in time, nor any certainty that the requirements negotiated are still feasible.
  • the problem in short, given the above discussion, is that there is no certainty provided in relation to the ability of an intent based network to fulfil a requirement of an intent.
  • Certain aspects of the disclosure and their embodiments may provide improvements or solutions to these or other challenges.
  • This disclosure provides techniques that enable an intent owner node to request an intent handler node for a guarantee that one or more requirements of an intent can be fulfilled. This disclosure also provides techniques that enable an intent handler node to provide a guarantee that one or more requirements of an intent can be fulfilled to an intent owner node.
  • a method of operating an intent owner node in an intent based network comprises transmitting, to an intent handler node, a first request indicating a first requirement set comprising one or more requirements for an intent to be guaranteed by the intent handler node.
  • the method further comprises receiving, from the intent handler node, a first message responsive to the first request, the first message indicating a second requirement set comprising one or more requirements that are guaranteed.
  • a method of operating an intent handler node in an intent based network comprises receiving, from an intent owner node, a first request indicating a first requirement set comprising one or more requirements for an intent to be guaranteed by the intent handler node.
  • the method further comprises transmitting, to the intent owner node, a first message responsive to the first request, the first message indicating a second requirement set comprising one or more requirements that are guaranteed.
  • a computer program product comprising a 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 the method of the first aspect, the second aspect, or any embodiment thereof.
  • an intent owner node for use in an intent based network.
  • the intent owner node is configured to: transmit, to an intent handler node, a first request indicating a first requirement set comprising one or more requirements for an intent to be guaranteed by the intent handler node; and receive, from the intent handler node, a first message responsive to the first request, the first message indicating a second requirement set comprising one or more requirements that are guaranteed.
  • an intent handler node for use in an intent based network.
  • the intent handler node is configured to: receive, from an intent owner node, a first request indicating a first requirement set comprising one or more requirements for an intent to be guaranteed by the intent handler node; and transmit, to the intent owner node, a first message responsive to the first request, the first message indicating a second requirement set comprising one or more requirements that are guaranteed.
  • an intent owner node for use in an intent based network.
  • the intent owner node comprises a processor and a memory, said memory containing instructions executable by said processor, whereby said intent owner node is operative to: transmit, to an intent handler node, a first request indicating a first requirement set comprising one or more requirements for an intent to be guaranteed by the intent handler node; and receive, from the intent handler node, a first message responsive to the first request, the first message indicating a second requirement set comprising one or more requirements that are guaranteed.
  • an intent handler node for use in an intent based network.
  • the intent handler node comprises a processor and a memory, said memory containing instructions executable by said processor, whereby said intent handler node is operative to: receive, from an intent owner node, a first request indicating a first requirement set comprising one or more requirements for an intent to be guaranteed by the intent handler node; and transmit, to the intent owner node, a first message responsive to the first request, the first message indicating a second requirement set comprising one or more requirements that are guaranteed.
  • Certain embodiments may provide one or more of the following technical advantage(s).
  • the techniques described herein allow an intent handler node and an intent owner node to negotiate and communicate guaranteed requirements. This elevates intent based operation and requirement assurance beyond best effort approaches.
  • the techniques described herein also allow for better use of and allocation of resources, increase reliability of services, and allow for better usage planning (as the guarantee provides certainty with regards to the ability of the intent based network to fulfil an intent), thereby improving service usage and usage of the intent based network.
  • This technique can allow guarantees to be provided to customers, for example as part of service level agreements (SLAs).
  • SLAs service level agreements
  • the techniques described herein also allow the determination and management of risks associated with service usage.
  • CSPs Cloud Solution Providers
  • Fig. 1 shows a signalling diagram illustrating communication between an intent owner node and an intent handler node
  • Fig. 2 shows a signalling diagram illustrating communication between an intent owner node and an intent handler node
  • Fig. 3 shows example vocabulary that enables a guarantee for an intent to be requested by an intent owner node
  • Fig. 4 shows example vocabulary that enables a guarantee for an intent to be provided by an intent handler node
  • Fig. 5 is a flow chart illustrating a computer-implemented method according to various embodiments performed by an intent owner node in an intent based network
  • Fig. 6 is a flow chart illustrating a computer-implemented method according to various embodiments performed by an intent handler node in an intent based network
  • Fig. 7 is a simplified block diagram of a network node according to various embodiments.
  • Fig. 8 is a block diagram illustrating a virtualization environment.
  • this disclosure provides improvements to intent based operation.
  • the techniques described herein enable an intent owner node to request an intent handler node for a guarantee that one or more requirements of an intent can be fulfilled.
  • the techniques described herein also enable an intent handler node to provide a guarantee that one or more requirements of an intent can be fulfilled to an intent owner node.
  • Certain aspects of this disclosure also provide communication vocabulary for requesting and providing requirement fulfilment guarantees in API and information models used in communication between an intent handler node and an intent owner node.
  • an intent may be interpreted as a formal specification of all expectations including requirements, goals, and constraints given to a technical system, as defined in the TMForum document IG1253. Furthermore, this definition excludes all imperative implementation and solution aspects from the intent itself. Intent is therefore purely 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. This understanding of intent implies 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.
  • the methods described herein are 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.
  • RANs radio access networks
  • OFDRANs Open RANs
  • 3GPP 3rd Generation Partnership Project
  • Fig 1 shows a signalling diagram illustrating communication between an intent owner node 102 and an intent handler node 104. This communication enables a guarantee for an intent to be requested by an intent owner node 102, and a guarantee related to the requested intent to be provided by the intent handler node 104.
  • the intent owner node 102 transmits a guarantee request 106 to the intent handler node 104.
  • This guarantee request 106 is also referred to herein as a “first request”.
  • the guarantee request 106 indicates a first requirement set for an intent to be guaranteed by the intent handler node 104.
  • the first requirement set expresses what needs to be achieved or avoided by the intent, or what outcome is more or less preferred by the intent.
  • the first requirement set expresses or represents the intent in terms of one or more requirements.
  • a “requirement” of a requirement set represents a type of expectation for the intent. It will be appreciated that the intent owner node 102 may request a guarantee for a subset of the requirements of the intent, or may request a guarantee for the entire intent.
  • the intent handler node 104 may then provide a guarantee for the subset of the requirements of the intent, or for the entire intent. It will be appreciated that the procedure of Fig. 1 may be performed as part as a procedure for exploring (or probing) an intent, or performed as part as a procedure for setting an intent. Alternatively, the procedure of Fig. 1 may be performed following the setting of the intent. In embodiments where the procedure of Fig. 1 is performed as part of a procedure for exploring (or probing) an intent, the guarantee request 106 may be a message that initiates a determination (by the intent handler node 104) of whether the intent handler node 104 has the ability to fulfil one or more requirements of the first requirement set.
  • the guarantee request 106 may initiate the intent hander node 104 to determine whether it has sufficient resources available, or whether sufficient resources can be allocated, to fulfil the first requirement set.
  • the guarantee request 106 may be a message that initiates the intent handler node 104 to fulfil one or more requirements of the first requirement set.
  • the intent owner node 102 may ask for a guarantee as part of intent negotiation, but also within and for intent that is already operated by the intent handler node 104.
  • a requirement may relate to a non-configurable parameter of the intent based network, or a measurable performance metric of the intent based network.
  • a requirement may relate to a key performance indicator (KPI) of the intent based network, such as a throughput of the intent based network, or a latency of the intent based network.
  • KPI key performance indicator
  • the one or more requirements for an intent may indicate one or more expectations that should be met, by one or more entities (such as servers, computers, network switches, routers, firewalls, base stations, etc.) of the intent based network, for the intent to be fulfilled.
  • the requirement may comprise a proposed value (or level), or a proposed range of values (or levels), of the requirement.
  • This proposed value (or level), or proposed range of values (or levels) may indicate a level at which the requirement is to be met, by one or more entities of the intent based network, in order for the intent to be fulfilled.
  • the requirement may comprise one of: a minimum value of the requirement, a maximum value of the requirement, a value of the requirement, or a range of values of the requirement.
  • the requirement may comprise a minimum value of a throughput parameter (for example, 10MBits/s).
  • a request for an intent can include an explicit indication that the intent owner node 102 requests a guarantee for the intent.
  • a request for an intent may be implicitly understood to be a request for a guarantee for that intent.
  • a request for a guarantee may be included in the intent.
  • the guarantee request 106 may indicate a period for which the first requirement set is to be guaranteed.
  • the intent owner node 102 may ask the intent handler node 104 for a timeframe in which the guarantee shall hold.
  • the intent handler node 104 may then provide a guarantee with a validity/expiration timeframe, as described in greater detail below.
  • the guarantee request 106 may indicate a request for a probability of the first requirement set being guaranteed.
  • the intent owner node 102 may ask the intent handler node 104 for a for a probability level that the guarantee would hold.
  • the intent handler node 104 may then provide a probability for the guarantee to hold in its replies, as described in greater detail below.
  • the guarantee request 106 may indicate a frequency with which a guarantee for the first requirement set is to be renewed.
  • the intent owner node 102 may ask that the intent handler node 104 renews the guarantee proactively and regularly.
  • the intent handler node 104 may then generate new reply with a new validity period accordingly, as described in greater detail below.
  • the intent handler node 104 transmits an acknowledgement message 108 that indicates to the intent owner node 102 that the guarantee request 106 has been received.
  • the intent handler node 104 processes the guarantee request 106.
  • the intent handler node 104 can process the guarantee request 106 to determine whether, or the extent to which, the requested intent can be delivered to the intent owner node 102. If requested in the guarantee request 106, or if otherwise configured, the intent handler node 104 may further determine one or more of: a period for which the second requirement set is guaranteed, a probability of the second requirement set being guaranteed, and an indication of whether the first requirement set is guaranteed (i.e. an indication of whether the requirements in the second requirement set match the requirements in the first requirement set).
  • the intent handler node 104 may process a received guarantee request 106.
  • the intent handler node 104 may request that one or more entities of the intent based network provide information relating to the requested guarantee and/or to provide the guarantee itself.
  • the intent handler node 104 may ask another intent handler node 104, or network resources, to provide information relating to the requested guarantee and/or to provide the guarantee itself.
  • the intent handler node 104 may determine if network slicing can be used to satisfy and/or provide the requested guarantee.
  • the intent handler node 104 may use a digital twin of the environment (e.g. a model of the intent based network) to provide and/or determine a guarantee.
  • the intent handler node 104 may use one or more policies to provide and/or determine a guarantee.
  • the intent handler node 104 may then form a second requirement set based on the determined one or more requirements that can be guaranteed.
  • the intent handler node 104 transmits, responsive to the guarantee request 106, a report notification 112 for the guarantee request 106 to the intent owner node 102.
  • a guarantee may provided back to the intent owner node 102 through an intent report.
  • the report notification 112 is also referred to herein as a “first message”.
  • the report notification 112 indicates the second requirement set comprising one or more requirements that are guaranteed.
  • the report notification 112 may further indicate one or more of: the period for which the second requirement set is guaranteed, the probability of the second requirement set being guaranteed, and the indication of whether the first requirement set is guaranteed.
  • the one or more requirements that are guaranteed are able to be fulfilled by the intent handler node 104 and/or one or more entities of the intent based network.
  • This guarantee provides the intent owner node 102 with increased certainty regarding the ability of the intent based network to fulfil the intent.
  • This information may then be utilized by the intent owner node 102 to either negotiate and/or set the intent.
  • the intent owner node 102 may determine to set the intent based on the receipt of the report notification 112 indicating that the one or more requirements of the first requirement set are guaranteed.
  • the requirement(s) that are guaranteed by the intent handler node 104 may not match the requirement(s) that the intent owner node 102 requested to be guaranteed. It will also be appreciated that the requirement set that is guaranteed by the intent handler node 104 may not match, or may not completely match, the requirement set that the intent owner node 102 requested to be guaranteed.
  • the guarantee request 106 may indicate that a value of the throughput parameter that is to be guaranteed is 10MBit/s, and the report notification 112 may indicate the guaranteed value of the throughput parameter is 8MBit/s.
  • the methods described herein enable an intent handler node 104, in situations where the intent handler node 104 cannot guarantee the one or more requirements comprised within the first requirement set, to still provide a guarantee for one or more of the requirements of the intent that can be met.
  • the intent handler node 104 may be able to provide a guarantee specifying a level at which a requirement comprised within the first requirement set is guaranteed.
  • the intent handler node 104 may not be able to provide a guarantee for a requested requirement, it may still be able to provide a guarantee for a more relaxed requirement.
  • the report notification 112 for the guarantee request 106 may referred to as “a report for the intent”, such as those described in “Intent Common Model - Intent Reporting v3.2.0 (TR290B)”.
  • the intent owner node 102 following receipt of the first message 112, may transmit, to the intent handler node104, a message (also referred to herein as a “third message”) that initiates the intent handler node to fulfil one or more requirements of the first requirement set, or initiates the intent handler node to fulfil one or more requirements of the second requirement set.
  • a message also referred to herein as a “third message”
  • the intent handler node 104 may, following transmission of the first message 112, determine a first time at which the guarantee for the first requirement set is to be renewed. The intent handler node 104 may, at the first time, update which of the one or more requirements in the first requirement set can be guaranteed. The intent handler node 104 may send, to the intent owner node, a further report notification (also referred to herein as a “second message”) responsive to the first request, the further report notification indicating a third requirement set comprising the updated one or more requirements. The further report notification may further indicate one or more of: a period for which the third requirement set is guaranteed, a probability of the third requirement set being guaranteed, and an updated indication of whether the first requirement set is guaranteed. The further report notification may also be referred to as “a report for the intent”.
  • the procedure of Fig. 1 therefore enables a guarantee for an intent, or a guarantee for one or more requirements of an intent, to be requested by, and provided to, an intent owner node 102. It will be appreciated that this enables the intent handler node 104, and the intent owner node 102, to negotiate and communicate guaranteed requirements, elevating intent based operation and requirement assurance beyond best effort approaches.
  • Fig. 2 shows a signalling diagram illustrating communication between an intent owner node 102 and an intent handler node 104 as part of a procedure for exploring (or probing) an intent. This communication enables a guarantee for an intent to be requested by an intent owner node 102, and a guarantee related to the requested intent to be provided by the intent handler node 104. It will be appreciated that, in other embodiments, the procedure of Fig. 2 may be performed as part of a procedure for setting an intent, or may be performed following the setting of an intent.
  • the intent owner node 102 transmits a guarantee request 202 to the intent handler node 104.
  • the guarantee request 202 is an example implementation of the guarantee request 106 described above.
  • the guarantee request 202 indicates/identifies the intent to which the guarantee relates (“intentl ”), and indicates the first requirement set to be guaranteed by the intent handler node 104.
  • the first requirement set includes a “Target: throughput/user requirement of 10Mbit/s”. That is, guarantee request 202 asks the intent handler node 104 for a guarantee for a proposed value of the throughput parameter, where the proposed value is 10MBit/s. This proposed value indicates the level at which the throughput is to be met, by one or more entities of the intent based network, in order for “intentl” to be fulfilled.
  • the guarantee request 202 comprises the message parameters “guaranteeTime” (which indicates a period for which the first requirement set is to be guaranteed), “guaranteeFrequency” (which indicates how often the guarantee for the first/second requirement set is to be updated or renewed), and “guaranteeprobability” (which indicates a probability of the guarantee for the second requirement set being delivered).
  • the value of the message parameter “guaranteeFrequency” indicates that the guarantee for the throughput parameter is to be renewed every 5 minutes (“guaranteeFrequency: 5 minutes”).
  • the value ‘x’ of message parameter “guaranteeprobability” indicates that a probability of the guaranteed requirements being fulfilled is to be provided to the intent owner node 102.
  • the intent handler node 104 responsive to receiving the guarantee request 202, transmits an acknowledgement message 204 that indicates to the intent owner node 102 that the guarantee request 202 has been received.
  • the acknowledgement message 204 may be referred to a “report for the intent”.
  • the acknowledgement message 204 can include an identifier for the intent (e.g. intentl) so that the intent owner node 102 is able to determine which requested intent the acknowledgement message 204 relates to.
  • the reception of the guarantee request 202 informs the intent handler node 104 that a guarantee for the proposed value of the throughput parameter is required.
  • the intent handler node 104 processes the guarantee request 202 and determines which requirement(s) in the guarantee request 202 can be guaranteed.
  • Step 206 is an example implementation of step 110 described above.
  • the intent handler node 104 responsive to the guarantee request 202, transmits a first report notification 208 for the guarantee request 202 to the intent owner node 102.
  • the first report notification 208 is an example implementation of the report notification 112 described above.
  • the first report notification 208 can include an identifier for the intent (e.g. intentl ) so that the intent owner node 102 is able to determine which requested intent the first report notification 208 relates to.
  • the first report notification 208 comprises a creation time, “dcterms:created”, specifying the time at which the intent handler node 104 created a report object for the intent owner node 102.
  • the first report notification 208 comprises the message parameters “guaranteevalue”, “guaranteeExpiry”, “guaranteeprobability” and “guaranteepossible”.
  • the value of the message parameter “guaranteevalue” indicates the value of the throughput parameter that is guaranteed (in this example, 10MBit/s).
  • the value of the message parameter “guaranteeExpiry” indicates that the guarantee for the throughput parameter will expire 15 minutes following the creation of the report object.
  • message parameter “guaranteeprobability” indicates that the probability of the guaranteed requirement being fulfilled is 0.8.
  • message parameter “guaranteepossible” indicates that the intent expressed in the first requirement set in guarantee request 202 can be guaranteed.
  • the first report notification 208 therefore informs the intent owner node 102 that the intent based network can maintain the throughput requirement of at least 10 Mbit/s with a probability of 0.8 until “2023-08-16T21 :53: 10+05:30” (which, in this example, is 15 minutes from the first report notification 208 generation time).
  • Step 210 as the guarantee request 202 requested the guarantee be updated/renewed every 5 minutes, the intent handler node 104 performs processing to renew the guarantee for the first requirement set. Step 210 is therefore executed 5 minutes after the execution of step 206.
  • Step 210 may comprise, at the first time, updating which of the one or more requirements in the first requirement set can be guaranteed.
  • the intent handler node 104 determines that the intent based network can maintain the throughput requirement of at least 10 Mbit/s with a probability of 0.95 until “2023-08-16T21 :58: 10+05:30”.
  • the intent handler node 104 then transmits a second report notification 212 to the intent owner node 102.
  • the second report notification 212 can include an identifier for the intent (e.g. intentl) so that the intent owner node 102 is able to determine which requested intent the second report notification 212 relates to.
  • the second report notification 212 informs the intent owner node 102 that the intent based network can maintain the throughput requirement of at least 10 Mbit/s with a probability of 0.95 (an improvement) until “2023-08-16T21 :58:10- )5:30”.
  • This process of renewing the guarantee and providing a report comprising the renewed (or updated) guarantee can repeat until the intent owner node 102 transmits, to the intent handler node 104, a guarantee removal request 214.
  • the guarantee removal request 214 can identify the intent (e.g. intentl) to which the removal request 214 relates.
  • the intent handler node 104 transmits, to the intent owner node 102, a message 216 acknowledging that the guarantee removal request 214 has been received.
  • new parameters may be introduced in the intent API, the intent expression model and/or the intent report expression model to enable the requesting and provision of guarantees for requirements. It will be appreciated that these new parameters may be introduced into the existing intent API, or a new API may be created that utilises these parameters. In both cases, the vocabulary and parameters for the requesting of, and the provision of, guarantees can be the same. These vocabulary and parameters may be utilized in the procedures of Fig. 1 and Fig. 2 described above.
  • Fig. 3 shows example vocabulary that enables a guarantee for an intent to be requested by an intent owner node 102, for example in guarantee request 106/202.
  • Fig 3. shows a new class of expectation, a guarantee expectation 302, in the intent expression 304.
  • This enables the intent expression 304 to request a guarantee for the intent.
  • the scope of the guarantee is expressed by the target 306 of the guarantee expectation 302. That is, in the intent expression 304, the target 306 points to a requirement for a guarantee is required.
  • the target 306 may comprise the intent as a whole, an instance of another expectation (such as a property expectation), or an instance of a condition.
  • the parameter “guaranteeTime” 308 specifies the timeframe the guarantee shall be valid for.
  • the value of the parameter “guaranteeTime” 308 is a duration.
  • the parameter “guaranteeFrequency” 310 specifies how often the guarantee shall be renewed.
  • the value of the parameter “guaranteeFrequency” 310 is a duration or a frequency value.
  • the guarantee frequency may be modelled through a timer that generates a new guarantee specific report trigger (in a similar manner to a reporting frequency in a reporting expectation). The modelling may change depending on the version of the intent model being used as a base.
  • the parameter “guaranteeprobability” 312 specifies the likelihood of the guarantee being held. That is, it indicates a measure of how confident an intent handler node 104 is in a provided guarantee.
  • Fig. 4 shows example vocabulary that enables a guarantee for an intent to be provided by an intent handler node 104, for example in report notification 112/212.
  • An intent handler node 104 may provide a guarantee as requested in the guarantee expectation 302 described above.
  • the intent handler node 104 may report a guarantee in one or more expectation report objects associated with the guarantee expectation 302. It will be appreciated that, if a guarantee is requested for several requirements, separate expectation reports 402 may be created for each of these requirements.
  • the parameter “guaranteeExpiry” 404 specifies the time at which the guarantee is no longer valid.
  • the parameter “guaranteedValue” 406 provides the requirement expression that is guaranteed, such as a KPI value that is guaranteed.
  • the parameter “guaranteepossible” 408 has a boolean value that specifies if it is possible to provide a guarantee as requested.
  • the parameter “guaranteeprobability” 410 specifies the confidence level that the guarantee will be held.
  • the target 412 of an expectation report 402 (that provides a guarantee) is the object in the intent that specifies the requirement that the guarantee is provided for.
  • the “guaranteelD” 414 in the intent report 416 specifies the guarantee report serial number/identity.
  • Fig. 5 is a flow chart illustrating a computer-implemented method according to various embodiments performed by an intent owner node in an intent based network.
  • the intent owner node may perform the method in response to executing suitably formulated computer readable code.
  • the computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium.
  • the computer readable medium may be part of a computer program product.
  • the intent owner node transmits, to an intent handler node, a first request indicating a first requirement set comprising one or more requirements for an intent to be guaranteed by the intent handler node.
  • the intent owner node receives, from the intent handler node, a first message responsive to the first request, the first message indicating a second requirement set comprising one or more requirements that are guaranteed.
  • Fig. 6 is a flow chart illustrating a computer-implemented method according to various embodiments performed by an intent handler node in an intent based network.
  • the intent handler node may perform the method in response to executing suitably formulated computer readable code.
  • the computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium.
  • the computer readable medium may be part of a computer program product.
  • the intent handler node receives, from an intent owner node, a first request indicating a first requirement set comprising one or more requirements for an intent to be guaranteed by the intent handler node.
  • the intent handler node transmits, to the intent owner node, a first message responsive to the first request, the first message indicating a second requirement set comprising one or more requirements that are guaranteed.
  • Fig. 7 is a simplified block diagram of a network node 700 according to various embodiments that can be used to implement the techniques described herein. It will be appreciated that the network node 700 may comprise one or more virtual machines running different software and/or processes. The network node 700 may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes. The network node 700 described herein may be an intent owner node 102, or an intent handler node 104.
  • the processing circuitry 701 controls the operation of the network node 700 and can implement the methods described herein in relation to the network node 700.
  • the processing circuitry 701 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the network node 700 in the manner described herein.
  • the processing circuitry 701 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 methods described herein in relation to the network node 700.
  • the network node 700 may optionally comprise a communications interface 702.
  • the communications interface 702 can be for use in communicating with wireless devices and/or other network nodes.
  • the communications interface 702 can be configured to transmit to and/or receive from wireless devices and/or other network nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 701 may be configured to control the communications interface 702 of the network node 700 to transmit to and/or receive from wireless devices and/or other network nodes requests, resources, information, data, signals, or similar.
  • the network node 700 may comprise a memory 703.
  • the memory 703 can be configured to store program code that can be executed by the processing circuitry 701 to perform the method described herein in relation to the network node 700.
  • the memory 703 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 701 may be configured to control the memory 703 to store any requests, resources, information, data, signals, or similar that are described herein.
  • Fig. 8 is a block diagram illustrating a virtualization environment 800 in which functions implemented by some embodiments may be virtualized.
  • the virtualization environment 800 can be used to implement part or all of the functions of the intent owner node 102 and/or the intent handler node 104 described herein.
  • virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources.
  • virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components.
  • Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 800 hosted by one or more of hardware nodes, such as a hardware computing device that operates as an intent owner node 102 or an intent handler node 104 as described herein.
  • the node may be entirely virtualized.
  • Applications 802 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 800 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.
  • Hardware 804 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth.
  • Software may be executed by the processing circuitry to instantiate one or more virtualization layers 806 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 808a and 808b (one or more of which may be generally referred to as VMs 808), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein.
  • the virtualization layer 806 may present a virtual operating platform that appears like networking hardware to the VMs 808.
  • the VMs 808 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 806.
  • a virtualization layer 806 Different embodiments of the instance of a virtual appliance 802 may be implemented on one or more of VMs 808, and the implementations may be made in different ways.
  • Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.
  • NFV network function virtualization
  • a VM 808 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine.
  • Each of the VMs 808, and that part of hardware 804 that executes that VM be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements.
  • a virtual network function is responsible for handling specific network functions that run in one or more VMs 808 on top of the hardware 804 and corresponds to the application 802.
  • Hardware 804 may be implemented in a standalone network node with generic or specific components. Hardware 804 may implement some functions via virtualization. Alternatively, hardware 804 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 810, which, among others, oversees lifecycle management of applications 802. In some embodiments, hardware 804 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station.
  • radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station.
  • some signalling can be provided with the use of a control system 812 which may alternatively be used for communication between hardware nodes and radio units.
  • a control system 812 which may alternatively be used for communication between hardware nodes and radio units.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Selon un aspect, l'invention concerne un procédé de fonctionnement d'un nœud propriétaire d'intention (102) dans un réseau basé sur l'intention. Le procédé consiste à : transmettre (501), à un nœud gestionnaire d'intention (104), une première demande (106, 202) indiquant un premier ensemble d'exigences comprenant une ou plusieurs exigences pour une intention devant être garantie par le nœud gestionnaire d'intention (104); et recevoir (502), de la part du nœud gestionnaire d'intention (104), un premier message (112, 208) en réponse à la première demande (106, 202), le premier message (112, 208) indiquant un second ensemble d'exigences comprenant une ou plusieurs exigences qui sont garanties.
PCT/TR2023/050973 2023-09-18 2023-09-18 Garanties dans un réseau basé sur l'intention Pending WO2025063904A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/TR2023/050973 WO2025063904A1 (fr) 2023-09-18 2023-09-18 Garanties dans un réseau basé sur l'intention

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/TR2023/050973 WO2025063904A1 (fr) 2023-09-18 2023-09-18 Garanties dans un réseau basé sur l'intention

Publications (1)

Publication Number Publication Date
WO2025063904A1 true WO2025063904A1 (fr) 2025-03-27

Family

ID=88206886

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/TR2023/050973 Pending WO2025063904A1 (fr) 2023-09-18 2023-09-18 Garanties dans un réseau basé sur l'intention

Country Status (1)

Country Link
WO (1) WO2025063904A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220022015A1 (en) * 2019-04-01 2022-01-20 Huawei Technologies Co., Ltd. Intent-based network configuration method, apparatus, and system
WO2023011735A1 (fr) * 2021-08-06 2023-02-09 Telefonaktiebolaget Lm Ericsson (Publ) Communication entre une hiérarchie de systèmes de gestion

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220022015A1 (en) * 2019-04-01 2022-01-20 Huawei Technologies Co., Ltd. Intent-based network configuration method, apparatus, and system
WO2023011735A1 (fr) * 2021-08-06 2023-02-09 Telefonaktiebolaget Lm Ericsson (Publ) Communication entre une hiérarchie de systèmes de gestion

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Network Functions Virtualisation (NFV) Release 4; Management and Orchestration; Intent Management Service Interface and Information Model Specification", no. V0.4.0, 15 August 2023 (2023-08-15), pages 1 - 36, XP014475211, Retrieved from the Internet <URL:ftp://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA050/NFV-IFA050v040.zip ETSI GS NFV-IFA 050 v0.4.0-cleaned-Intent Management Service Interface and Intent Information Model Specification.docx> [retrieved on 20230815] *
"Zero-touch network and Service Management (ZSM); Intent-driven autonomous networks; Generic aspects", no. V0.2.7, 24 November 2022 (2022-11-24), pages 1 - 57, XP014457740, Retrieved from the Internet <URL:ftp://docbox.etsi.org/ISG/ZSM/Open/Drafts/011_IntentDrv/ZSM-011_IntentDrvv027.zip ZSM-011_IntentDrvv027_clean.docx> [retrieved on 20221124] *
QUANG-TRUNG LUU ET AL: "Admission Control and Resource Reservation for Prioritized Slice Requests with Guaranteed SLA under Uncertainties", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 17 March 2022 (2022-03-17), XP091203278 *
TM FORUM: "Intent in Autonomous Networks - IG1253, v1.3.0", 29 September 2022 (2022-09-29), XP093105283, Retrieved from the Internet <URL:https://www.tmforum.org/resources/how-to-guide/ig1253-intent-in-autonomous-networks-v1-3-0/> [retrieved on 20231124] *
TM FORUM: "Intent Temporal Validity - Intent Extension Model - TR291B v1.1.0", 4 July 2022 (2022-07-04), Parsippany, NJ 07054, USA, pages 1 - 17, XP093141726, Retrieved from the Internet <URL:https://www.tmforum.org/resources/introductory-guide/tr291b-intent-temporal-validity-intent-extension-model-v1-1-0/> [retrieved on 20240315] *

Similar Documents

Publication Publication Date Title
US12175298B1 (en) Dynamic consolidation of virtual machines
CN107534570B (zh) 用于虚拟化网络功能监控的计算机系统、方法和介质
EP2849064B1 (fr) Procédé et appareil pour virtualisation en réseau
US9201644B2 (en) Distributed update service
KR101998012B1 (ko) 네트워크 서비스 기술자를 업데이트하기 위한 방법 및 장치
US10911333B2 (en) Network service life cycle management grant method and apparatus
US10567196B2 (en) Decision coordination method, execution apparatus, and decision coordinator
CN108011846B (zh) 网络功能虚拟化架构中管理业务的方法及装置
US10360068B1 (en) Dynamic configuration of virtual machines
CN107005452B (zh) 一种网络功能虚拟化资源处理方法及虚拟网络功能管理器
CN108028827B (zh) 网络功能虚拟化架构中证书的管理方法及装置
US20190034219A1 (en) Application management method and apparatus in network functions virtualization environment
US20170063645A1 (en) Method, Computer Program and Node for Management of Resources
US20190268213A1 (en) Network function management method, management unit, and system
US12004076B2 (en) Evaluating a hosting device for installation of a virtualized function within a network infrastructure
CN118476274A (zh) 在空闲时间关闭o-cloud节点以节省能耗的系统和方法
KR20180006971A (ko) 하드웨어 가속 방법 및 관련 장치
CN110912726B (zh) 服务的提供方法、装置、系统、存储介质及电子装置
WO2025063904A1 (fr) Garanties dans un réseau basé sur l&#39;intention
US8433877B2 (en) Storage scalability management
US20090183172A1 (en) Middleware Bridge System And Method
US20240056810A1 (en) Trust Level in Network Slices
EP4378136A1 (fr) Structure destinée à la fiabilité
CN112889247A (zh) Vnf服务实例化方法及装置
WO2025238266A1 (fr) Apprentissage fédéré vertical pour analyse de données de réseau dans un réseau de communication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23782311

Country of ref document: EP

Kind code of ref document: A1