ETSI GR ENI 015 V4.1.1 (2024-05)

Experiential Networked Intelligence (ENI); Processing and Management of Intent Policy

DGR/ENI-0025_Int_Policy_proces

General Information

• Status: Not Published
• Technical Committee: ENI - Experiential Networked Intelligence
• Current Stage: 12 - Completion
• Due Date: 18-Jun-2024
• Completion Date: 30-May-2024

Standards Content (Sample)

GROUP REPORT
Experiential Networked Intelligence (ENI);
Processing and Management of Intent Policy
Disclaimer
The present document has been produced and approved by the Experiential Networked Intelligence (ENI) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR ENI 015 V4.1.1 (2024-05)

Reference
DGR/ENI-0025_Int_Policy_proces
Keywords
artificial intelligence, network
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2024.
All rights reserved.
ETSI
3 ETSI GR ENI 015 V4.1.1 (2024-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 8
4 Background and Overview . 8
4.1 ENI Purpose . 8
4.2 Intent Work in ENI . 8
4.3 Introduction to Knowledge . 9
5 Procedures of Intent Policy Processing . 9
5.1 Introduction . 9
5.2 Intent Policy Processing Operation . 10
5.3 Conflict detection and resolution . 11
5.3.1 Overview . 11
5.3.2 Conflict detection . 12
5.3.3 Conflict resolution . 13
6 Knowledge management for Intent Policy . 14
6.1 Introduction to Knowledge Graphs . 14
6.1.1 Definition . 14
6.1.2 Motivation for Using Knowledge Graphs in ENI . 14
6.1.2.1 Motivation . 14
6.1.2.2 Requirement . 15
6.1.2.3 Location of the Knowledge Graph . 15
6.2 Constructing Knowledge Graphs in the ENI System . 16
6.2.1 Introduction. 16
6.2.2 Construction Procedures . 16
6.2.2.1 Data Processing . 16
6.2.2.2 Knowledge Representation . 17
6.2.2.3 Knowledge Generation . 17
6.2.2.4 Knowledge Verification . 18
6.2.2.5 Knowledge Graph Storage . 18
6.3 Using Knowledge Graphs to Manage Intent policies . 19
6.3.1 Intent Translation . 19
6.3.2 Intent Verification . 19
6.3.3 Intent Monitoring . 19
6.3.4 Intent Assurance . 20
6.3.5 Intent Optimization . 20
6.4 Lifecycle Management . 20
6.4.1 Lifecycle Management of Intent Policies . 20
6.4.1.1 States of Intent Policy management . 20
6.4.1.2 State machine of Intent Policy processing . 20
6.4.1.3 Lifecycle Management Roles of Intent Policy . 22
6.4.2 Lifecycle Management of Knowledge Used by Policies . 22
6.4.2.1 Previous Work . 22
6.4.2.2 Lifecycle Management Roles of Knowledge Used by Policies. 22
6.4.2.3 Lifecycle of Knowledge Used by Policies . 23
ETSI
4 ETSI GR ENI 015 V4.1.1 (2024-05)
7 Use Cases . 23
7.1 Use cases for operators' business . 23
7.1.1 Use Case #1-1: Intent-driven operation for user-centric cloud-network convergence services . 23
7.1.1.1 Use case context . 23
7.1.1.2 Description of the Use Case . 24
7.1.1.2.1 Overview . 24
7.1.1.2.2 Motivation . 24
7.1.1.2.3 Actors and Roles. 24
7.1.1.2.4 Initial context configuration . 24
7.1.1.2.5 Triggering conditions . 25
7.1.1.2.6 Operational flow of actions . 25
7.1.1.2.7 Post-conditions . 25
7.2 Use cases for vertical industry . 25
7.2.1 Use Case #2-1: Intent-Driven Home Intranet Management . 25
7.2.1.1 Use case context . 25
7.2.1.2 Description of the Use Case . 25
7.2.1.2.1 Overview . 25
7.2.1.2.2 Motivation . 26
7.2.1.2.3 Actors and Roles. 26
7.2.1.2.4 Initial context configuration . 27
7.2.1.2.5 Triggering conditions . 27
7.2.1.2.6 Operational flow of actions . 27
7.2.1.2.7 Post-conditions . 28
8 Conclusions and recommendations . 28
History . 29

ETSI
5 ETSI GR ENI 015 V4.1.1 (2024-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Experiential Networked
Intelligence (ENI).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GR ENI 015 V4.1.1 (2024-05)
1 Scope
The present document describes the following topics:
• Enhanced procedures for processing Intent Policy, e.g.:
- detail the Procedures of intent policy processing;
- conflict detection and resolution between different Intent Policies.
• Knowledge management for Intent Policy, including:
- how to use a Knowledge Graph to manage Intent policies;
- how to use a Knowledge Graph for managing Intent policy knowledge;
- procedures for lifecycle management of intent knowledge, e.g. import, update, delete, and query of the
intent knowledge.
• Typical use cases and requirements which can reduce the management complexity for Intent Users, e.g.:
- use cases for Business Users/Operational Users/Technical Users that are all users of Intent.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GS ENI 005 (V3.1.1): "Experiential Networked Intelligence (ENI); System Architecture".
[i.2] ETSI GR ENI 008 (V2.1.1): "Experiential Networked Intelligence (ENI); InTent Aware Network
Autonomicity (ITANA)".
[i.3] ETSI GR ENI 016 (V2.1.1): "Experiential Networked Intelligence (ENI); Functional Concepts for
Modular System Operation".
[i.4] ETSI GS ENI 030 (V4.1.1): "Experiential Networked Intelligence (ENI); Transformer
Architecture for Policy Translation".
[i.5] IEEE Access 8 (2020): "Knowledge graph completion: A review" 192435-192456, Chen Zhe et al.
[i.6] TM Forum IG1253 (V1.2.0): "Intent in Autonomous Networks".
[i.7] MEF 95: "MEF Policy Driven Orchestration", Strassner, J, editor, July 2021.
[i.8] ETSI GS ENI 019 (V3.1.1): "Experiential Networked Intelligence (ENI); Representing, Inferring,
and Proving Knowledge in ENI".
ETSI
7 ETSI GR ENI 015 V4.1.1 (2024-05)
[i.9] Stanford definition of "Propositional Logic".
[i.10] ETSI GS ENI 033 (V4.1.1): "Experiential Networked Intelligence (ENI); Definition,
Requirements and Procedure of Intent Policy Multi-Stage Translating".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
bag-of-words model: model which represents text data as a collection of words, regardless of the order of words
NOTE: The bag-of-words model can determine the important words in the text by counting the number of
occurrences of each word in the text data.
formal logic: study of propositions, statements, or assertively used sentences and of deductive arguments. Formal logic
is the basis of deductive reasoning, which is used to derive a conclusion from a set of premises with certainty
NOTE: Formal logic can also be used to prove the correctness of algorithms by reasoning formally or
mathematically about the algorithm.
graph database: database that uses graph structures to store and navigate relationships (i.e. edges) between entities (i.e.
nodes) in a graph
information extraction: process of identifying and extracting words and phrases with potential semantic information
from text data
knowledge fusion: integration of knowledge from different sources, forms, and structures
knowledge graph: directed cyclic graph that embeds semantics in the nodes and edges using a formal logic (RDF as a
minimum; types of Description Logics, such as or an OWL 2 Profile, are preferred)
named entity recognition: identification of entities with specific meanings in data such as text or images, such as
person names, organizational structures, place names, etc.
part of speech tagging: process of determining the part of speech of words to better understand the text
quality improvement: process of improving the accuracy, timeliness, completeness, reliability, and robustness of
knowledge graph through a series of technical means and algorithms
relationship extraction: process of extracting relationships between entities from raw data
NOTE: Relationship extraction includes character pattern based extraction methods, grammar pattern based
extraction methods, and semantic based extraction methods.
state machine: abstract mathematical model used to describe the patterns of transitions and behaviours of an object
between various states
topic model: model which is used to identify topics or keywords in text data, such as Latent Semantic Analysis (LSA)
based on probabilistic topic model
word embedding: technique used in natural language processing and machine learning to represent words as low
dimensional vectors that can be used for tasks such as text classification and sentiment analysis
NOTE: Word embedding can be obtained through neural network learning or manually compiled.
3.2 Symbols
Void.
ETSI
8 ETSI GR ENI 015 V4.1.1 (2024-05)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACLs Access Control Lists
API Application Programming Interface
BSS Business Support Systems
CPL Cloud Private Line
CSRUD Create-Store-Read-Update-Delete
DL Description Logic
DSL Domain Specific Language
GDB Graph Database
IDS Intrusion Detection Systems
IPFB Intent Parser Functional Block
KG Knowledge Graph
LSA Latent Semantic Analysis
NAS Network Attached Storage
NER Named Entity Recognition
NLP Natural Language Processing
O&M Operation and Maintenance
OPEX Operational Expenditure
OSS Operations Support System
OTN Optical Transport Network
OWL Web Ontology Language
PMFB Policy Management Functional Block
QoS Quality of Service
RAN Radio Access Network
RDF Resource Description Framework
SPO Subject-Predication-Object
UHD Ultra High Definition
URI Uniform Resource Identifier
VR Virtual Reality
W3C World Wide Web Consortium
XR Extended Reality
4 Background and Overview
4.1 ENI Purpose
Operational Expenditure (OPEX) for network management is one of the operators' biggest concerns. The use of intent
in ENI can help operators effectively reduce OPEX. Intent enables different constituencies to express intent policies
using a language that is natural to themselves. Hence, the associated business benefit is to understand business needs
and use them to determine offered services and resources. This means that offered services can dynamically adapt to
changing user needs, business goals, and environment conditions, which will greatly improve the efficiency of network
management and reduces the cost of network Operation and Maintenance (O&M).
4.2 Intent Work in ENI
Intent Policy expresses the goals to be accomplished by using a restricted natural language (e.g. an external DSL),
without focusing on how to achieve those goals. The definition and introduction about intent policy can be found in
clause 6.3.9.3 of ETSI GS ENI 005 [i.1], and a previous study in ETSI GR ENI 008 [i.2] further discussed the
architecture of intent policy (in clause 5.1.2), life cycle management (in clause 5.3) and the translation process of intent
policy (in clause 5.2.3), as well as related use cases (in clause 6).
ETSI
9 ETSI GR ENI 015 V4.1.1 (2024-05)
4.3 Introduction to Knowledge
Knowledge is defined in clause 6.3.4 of ETSI GS ENI 005 [i.1] and further detailed in clause 6.3.4 of ETSI
GS ENI 005 [i.1]. Briefly, knowledge analyses data and information, understands its meaning, and can predict what has
happened, is happening, or what is possible to happen in the future. Knowledge management is an essential part in
intent aware network, which is responsible for managing the life cycle of the knowledge in the Data and Knowledge
Repositories, including storage, assessment, use, sharing, and refinement of knowledge assets. ENI develops knowledge
and wisdom from observed, measured, and inferred data and information, as described in ETSI GR ENI 016 [i.3].
5 Procedures of Intent Policy Processing
5.1 Introduction
In ETSI GR ENI 008 [i.2] and ETSI GS ENI 005 [i.1], the procedures of intent policy translation are shown in different
detail. In general, the intent policy is created by the intent creator and sent to the ENI System. The ENI System
translates and processes the received intent policy and notifies the intent creator of any errors. If there are no errors,
then the intent policy is executed on the selected component(s) of the Assisted System.
Considering the complexity of user's goals, the intent policy can be separated into multiple intent policies to simplify
the general procedures of intent policy processing, such as translation and named entity recognition. The processed
intent policy has three main lifecycle phases (see clause 6.4 of the present document): Translation, Deployment, and
Execution.
The benefits of this process are as follows:
1) Ensure the realization of the intent creator's goals by performing two functions automatically:
a) Translating the intent creator's policy from natural language to a form that can be verified by the ENI
System. Subsequent translations could be performed to make the translated policy implementable by the
Assisted System. If the translation fails, then errors found will be sent to the intent creator, and
processing stops until the intent creator resubmits an edited intent policy.
b) Testing any new intent policies to ensure that they can be executed correctly. If the testing results are not
able to meet the goals defined by the intent creator, then information describing this will be sent to the
intent creator, and processing stops until the intent creator resubmits an edited intent policy.
2) Automate the entire process (all processes are triggered automatically, especially automatic testing), while still
providing flexibility to the intent creator. For example, the intent creator can have control on each state change
of the intent policy lifecycle (see clause 6.4).
3) Support the flexible use of intent policies that are managed by a knowledge process, such as the Knowledge
Management Functional Block of ETSI GS ENI 005 [i.1] (see clause 6.3.4 of ETSI GS ENI 005 [i.1]).
NOTE: A group of intent policies could also be managed as a unit (e.g. a high level intent with an associated set
of detailed policies on each resource).
ETSI
10 ETSI GR ENI 015 V4.1.1 (2024-05)
5.2 Intent Policy Processing Operation
The original Intent Policy, which is written in a restricted natural language, is sent to the ENI System. It is ingested by
the API Broker and sent to the Policy Management Functional Block (PMFB). The PMFB checks to see if the ingested
Intent Policy has been seen before (e.g. by matching the text of the newly ingested Intent Policy with the text of a
previously stored Intent Policy). If the original Intent Policy matches a previous Intent Policy that has been successfully
parsed, verified, and stored, then the ENI System checks to see if anything has changed in the ingested Intent Policy
(e.g. parameter values). If nothing has changed, then the PMFB retrieves the previously translated representation of the
matched Intent Policy and sends it to the API Broker. The API Broker transforms the translated Intent Policy to a form
(i.e. a set of objects and/or code) that the Assisted System can understand. The translated Intent Policy is then sent to
the Assisted System. If a change in the ingested Intent Policy is detected, then the PMFB will first verify the proper
operation of the Intent Policy by testing it before sending it to the Assisted System. If this test fails, then all errors and
warnings are collected and sent back to the Intent Creator. If it passes, then the PMFB sends the verified Intent Policy to
the API Broker as described above.

Figure 5.1: Detailed Procedures of Intent Policy Processing
Alternatively, if the original Intent Policy is not found, then it needs to be parsed, optionally compiled and translated,
and subsequently verified. This is shown in the rest of Figure 5.1, starting with the "Send to Intent Parser" block. The
steps shown in Figure 5.1 are summarized as follows:
1) The input Intent Policy is parsed by the Intent Parser, which is part of the Intent Parser Functional Block
(IPFB). The parsing process is described in detail in ETSI GS ENI 005 [i.1], translator architecture in ETSI
GS ENI 030 [i.4] and ETSI GR ENI 008 [i.2]:
a) If the Intent Parser fails to generate a parse tree, then all errors and warnings are collected and sent to the
Intent Creator for correction.
b) Otherwise, the parse tree is generated and sent to the Intent Translation function, which is another
Functional Block that resides in the IPFB.
ETSI
11 ETSI GR ENI 015 V4.1.1 (2024-05)
2) The Intent Translation function checks to see if the Intent Policy has been previously used. Conceptually, the
Translation function is matching the newly translated object form of the ingested Intent Policy with the object
form of the stored Intent Policy, The purpose of this check is to catch grammatical differences that resolve to
the same Policy. For example, if Intent Policy 1 says "Give Ray Gold Service" and Intent Policy 2 says "Give
Gold Service to the user whose IP Address is 10.10.10.1", and the user of that IP address is Ray, then Intent
Policy 1 and Intent Policy 2 are the same. The translation process is specified in ETSI GS ENI 005 [i.1],
translator architecture in ETSI GS ENI 030 [i.4] and described as intent translation in ETSI GR ENI 008 [i.2]:
a) If it has, then the Intent Translation function notifies the Intent Creator and the Intent Policy is ready to
be deployed by the Assisted System (step 4).
b) If not, then the Intent Translation function passes the translated Intent Policy to the PMFB to verify the
Intent Policy (step 3).
3) The Intent Policy is verified by testing it (either by simulation or in a closed sandbox). In either case, testing
consists of a set of test inputs, execution conditions and expected results prepared for a specific objective,
which is used to verify whether the goals of the Intent Policy are met:
a) If the Intent Policy fails verification, then all errors and warnings are collected and sent to the Intent
Creator for correction.
b) Otherwise, the Intent Policy is ready to be deployed by the Assisted System.
4) The Intent Policy is deployed when either the Intent Creator or the ENI System give the Intent Policy
Processing system permission to do so. (The ENI System allows either the Intent Creator to have direct control
over the deployment of the Intent Policy, or alternatively, to tell the ENI System to automatically deploy it
when ready; this latter is a configurable setting):
a) If the Intent Policy fails to be deployed, then all errors and warnings are collected and sent to the Intent
Creator for correction.
b) Otherwise, the Intent Policy is ready to be executed.
5) The Intent Policy is executed when either the Intent Creator or the ENI System give the Intent Policy
Processing system permission to do so. (The ENI System allows either the Intent Creator to have direct control
over the execution of the intent policy, or alternatively, to tell the ENI System to automatically execute it when
ready; this latter is a configurable setting):
a) If the Intent Policy fails to execute, then all errors and warnings are collected and sent to the Intent
Creator for correction.
b) Otherwise, the Intent Policy executes.
The Intent Policy will continue to execute until either the Intent Creator or the ENI System stop its execution.
The above process does not include policy conflict detection and remediation. This is detailed in clause 5.3.
5.3 Conflict detection and resolution
5.3.1 Overview
Conflicts of policies are a well-known challenge to any policy management. The ENI System usually receives intent
policies from multiple sources (OSS, BSS, application, end-user, orchestrator, etc.). The ENI System will detect
whether there is a conflict between the new Intent Policy and other Intent Policies in Policy Management Functional
Block. If the conflict is detected, then the ENI System and Intent Creator try to resolve the conflict. Conflict detection
and resolution between different Intent Policies will be discussed in this clause.
NOTE: The present document will only discuss conflict detection and resolution between intent policies. Conflict
detection and resolution between intent policies and other types of policies will be done in a future
version of the present document.
ETSI
12 ETSI GR ENI 015 V4.1.1 (2024-05)
5.3.2 Conflict detection
When a new intent policy comes, the ENI System needs to consider the possible conflict between it and any existing
intent policies that are currently running. If any conflict is detected, the conflict message will be sent to the intent
creator, and the knowledge management function block records the conflict information for further reasoning and
analysis. The policy conflict is defined in ETSI GS ENI 005 [i.1] as follows: Policy conflict means two policies that,
when executed, cause contradictory and otherwise incompatible results within a given execution time window.
From the perspective of detection, there are two levels of conflicts (refer to ETSI GS ENI 005 [i.1] and TM Forum
IG1253 [i.6]):
Direct conflict
Direct conflict means that Intent Policies are expressing explicitly opposing or incompatible requirement with each
other. The most important thing in this case is to confirm the execution domains and time.
The first example is the following:
EXAMPLE 1: Intent Policy A: All network links are encrypted.
Intent Policy B: All network links are not encrypted.
As written, and with no other information, Intent Policy A and Intent Policy B conflict. However,
for example, as long as the user groups do not overlap, there is no explicit contradiction. This can
for example be a non-overlapping scope such as requiring encrypted links for one user group and
no encryption for another user group, so they can coexist.
Another example:
EXAMPLE 2: Intent Policy C: Set the value of an attribute named numErrors to "2" during 08:00:00 to 08:30:00.
Intent Policy D: Set the value of an attribute named numErrors to "3" during 08:45:00 to 09:00:00.
In this case, Intent Policy C and Intent Policy D do not conflict because their execution times do
not overlap, while they will conflict when the execution time overlaps.
Indirect conflict
In many cases, conflicts can not be obviously seen from the Intent Policy itself, but originate from conflicting actions
being proposed in their handling process, which is generally caused by common infrastructure and limited resources.
EXAMPLE 3: Intent Policy E: Increase RAN coverage delivered to users.
Intent Policy F: Increase throughput delivered to users.
On the surface, they do not involve the same indicator and there seems no conflict. However, both
Intent Policies imply opposing reconfiguration and actions of RAN cells. This is like a seesaw.
When the fulfilment of one Intent Policy is improved, the other will be degraded.
EXAMPLE 4: Intent Policy G: Allocate 10 M bandwidth to user A.
Intent Policy H: Allocate 5 M bandwidth to user B.
When there is only 10 M available bandwidth in the network, the two Intent Policy cannot be
satisfied at the same time, so conflicts occur.
Based on above, Figure 5.2 shows the procedure of conflict detection, which includes:
1) Translate the new Intent Policy;
2) Detect whether the execution domain of new Intent Policy overlaps with other Intent Policies.
3) If the answer of Step 2 is yes, then detect whether the execution time of new Intent Policy overlaps with other
Intent Policies.
4) If the answer of Step 3 is yes, then determine whether execution of the new Intent Policy conflicts with the
actions of other active Intent Policies.
NOTE: The detection content in step 4 is not limited to configuration parameters and network resources. It can be
multiple aspects that may conflict during the execution process of the Intent Policy.
5) If the answer of Step 4 is yes, the new Intent Policy is judged to conflict with the existing policy, and conflict
resolution is needed.
ETSI
13 ETSI GR ENI 015 V4.1.1 (2024-05)
Translate the new
Intent Policy
Whether the execution domains No
overlaps with existing Intent
Policies?
Yes
No
Whether the execution time
overlaps with existing Intent
Policies?
Yes
Whether execution of the new
No
Intent Policy conflicts with the Execution the new
actions of other active Intent
Intent Policy
Policies？
Yes
Conflict resolution
Figure 5.2: The procedure of conflict detection
5.3.3 Conflict resolution
The ENI System needs to resolve conflicting Intent Policies, helping users to properly choose between Intent Policy
alternatives that may have different ramifications.
In some conditions, conflict can be easily resolved (for example, the requirement of one Intent Policy includes another).
In this case, it is supposed that one Intent Policy requires a maximum delay of 10 ms and another one for the same
target requires a maximum delay of 5 ms. As written, the policies conflict, because they apply to all applications, and
the system does not know whether to set the maximum delay to 5 ms or 10 ms. There are at least two different solutions
to resolving this conflict. The first specifies which applications receive the 5 ms delay and which receive the 10 ms
delay. The second is to simply choose the 5 ms delay as long as all applications can support this more stringent
requirement.
For more complicated situations, priority is an efficient way to resolve conflicts as described in MEF 95 [i.7]. This
indicates that an ENI System should be able to prioritize actions and therefore find the set of operational states that is
globally preferential even if it means to degrade some Intent Policies.
Factors affecting priority setting may include:
• Task type. For example, network failure, business configuration, engineering change, security events, etc.
• Impact on network. The tasks that have a great impact on the stability of the network will be processed first,
and the tasks that have a small impact on the stability will be processed when they are idle.
• Task deadline. Prioritize tasks with deadlines approaching.
ETSI
14 ETSI GR ENI 015 V4.1.1 (2024-05)
A proper scheduling algorithm should be adopted and used for priority setting and conflict resolution. The specific
scheduling algorithm is beyond the scope of the present document.
6 Knowledge management for Intent Policy
6.1 Introduction to Knowledge Graphs
6.1.1 Definition
A Knowledge Graph is a directed cyclic graph that embeds semantics in the nodes and edges using a formal logic (RDF
as a minimum; types of Description Logics, such as an OWL 2 Profile, are preferred).
6.1.2 Motivation for Using Knowledge Graphs in ENI
6.1.2.1 Motivation
Knowledge graph technology is a typical cross-field technology. It is integrated with artificial intelligence,
mathematics, graphics, database, and other disciplines. Based on graph theory and the probability graph model in [i.5],
it can identify, discover and infer the complex relationships between concepts and how they relate to collected data. In
terms of using a knowledge graph for intent policy management, it is necessary to transform intent policies constructed
using a restricted natural language into a structured knowledge representation, and then select Intent Policies in the
knowledge graph to analyse for various management purposes. This process can help an ENI System understand the
meaning of the ingested intent policy by using procedures such as named entity recognition and removing any
ambiguities found in the translation process. This in turn can help translate abstract intent policies to more concrete
intent policies that can be understood by the target(s) of the intent policy. The following provides examples of how a
Knowledge Graph can be used to find intent conflicts:
1) Ingested intent policies can be examined in terms of their nodes and relationships to find conflicts. In addition,
Metadata could be generated to automatically categorize ingested intent policies according to their nodes and
relationships.
2) Knowledge Graphs (KGs) are a way of structuring information in a graph form by representing entities (e.g.
customers, services, and places) as nodes, and relationships between those entities (e.g. a customer has a
service located at his home) as edges. This inherent capability enables KGs to travel relationships much more
efficiently than other technologies, such as directories or relational databases. When a new intent policy is
ingested, the KG can verify whether there is a conflict relationship between the new intent policy and existing
active intent policies. A KG can help locate and verify the cause of the conflict by using its formal reasoning
capabilities. This information can then be supplied to other Functional Blocks in the Policy Management
Functional Block to provide detailed information to the ENI System and to the intent creator for further
conflict resolution. Conflict detection and resolution capabilities vary, and are dependent on the particular
description logic used.
3) An i
...