ETSI GR ENI 008 V2.1.1 (2021-03)

Experiential Networked Intelligence (ENI); InTent Aware Network Autonomicity (ITANA)

DGR/ENI-0013_Net_Autonomicity

General Information

• Status: Not Published
• Technical Committee: ENI - Experiential Networked Intelligence
• Current Stage: 12 - Completion
• Due Date: 23-Mar-2021
• Completion Date: 25-Mar-2021

Standards Content (Sample)

GROUP REPORT
Experiential Networked Intelligence (ENI);
InTent Aware Network Autonomicity (ITANA)
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 008 V2.1.1 (2021-03)

Reference
DGR/ENI-0013_Net_Autonomicity
Keywords
artificial intelligence, management
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://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
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 2021.
All rights reserved.
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.
ETSI
3 ETSI GR ENI 008 V2.1.1 (2021-03)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 5
3.1 Terms . 5
3.2 Symbols . 6
3.3 Abbreviations . 6
4 Introduction . 6
5 Impact of Intent Policies on the System Architecture . 7
5.1 Architecture Enhancement for Intent Policies . 7
5.1.1 Scope of Intent Policies . 7
5.1.2 Adding an Intent Translation Functional Block . 7
5.1.3 Reference Points for Intent Policies Imple me ntation . 9
5.2 Translation of Intent Policies. 9
5.2.1 Introduction. 9
5.2.2 Intent Policy Translation Functional Block Architecture . 9
5.2.3 Procedure for Translating DSL Intent Policies . 11
5.2.3.1 Introduction . 11
5.2.3.2 Translation Overview . 11
5.2.3.3 Translation Detailed Description . 13
5.2.3.3.1 Interactions of Intent Policy via External Reference Points . 13
5.2.3.3.2 Flux Diagram of the Intent Policy Translation Process and steps between actors . 13
5.3 Lifecycle Management of Intent Policy . 17
5.3.1 General . 17
5.3.2 State of Intent Policy. 17
5.3.3 Operations of State Management . 17
5.4 Absorb environment and vendor difference for intent-enabled autonomous system . 18
6 Use Cases of Intent Awareness . 19
6.1 Introduction . 19
6.2 VoLTE Service Experience Optimization . 19
6.2.1 Overview . 19
6.2.2 Motivation. 19
6.2.3 Operational communications . 20
6.3 Use Cases in NFV Domains . 21
6.3.1 Overview . 21
6.3.2 Use of Intent for NFV Service Fulfilment Tasks . 21
6.3.3 Use of Intent for NFV Service Tasks in order to guarantee SLAs . 21
6.3.4 Actors and Roles . 21
6.3.5 Operational communications . 21
6.4 Intent based energy saving for radio networks . 22
6.4.1 Overview . 22
6.4.2 Motivation. 22
6.4.3 Actors and Roles . 22
6.4.4 Operational communications . 23
7 Conclusions and recommendations . 24
Annex A: Change History . 25
History . 26

ETSI
4 ETSI GR ENI 008 V2.1.1 (2021-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
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
5 ETSI GR ENI 008 V2.1.1 (2021-03)
1 Scope
The present document will discuss various design options, in terms of a set of new stand-alone and/or nested Functional
Blocks, for using intent with the ENI System Architecture. This includes accepting, translating and validating intent
statements, determining how intent affects the goals and operation of the ENI system, and how it is used by business
users, application developers and network administrators.
The present document provides a set of recommendations and conclusions whose main scope is ETSI GS ENI 005 [i.2]
Release 2. However, the contents of the present document also affect other GSs & GRs (e.g. ETSI GS ENI 001 [i.1],
ETSI GS ENI 002 [i.4] and ETSI GR ENI 004 [i.3]).
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 001 (V3.1.1): "Experiential Networked Intelligence (ENI); ENI use cases".
[i.2] ETSI GS ENI 005 (V2.1.1): "Experiential Networked Intelligence (ENI); System Architecture".
[i.3] ETSI GR ENI 004 (V3.1.1): "Experiential Networked Intelligence (ENI); Terminology for Main
Concepts in ENI".
[i.4] ETSI GS ENI 002 (V3.1.1): "Experiential Networked Intelligence (ENI); ENI requirements".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
compiler: computer program that translates computer code written in one programming language (the source language)
into another language (the target language) (see ETSI GS ENI 005 [i.2])
NOTE: The term "compiler" is primarily used for programs that translate source code from a high-level
programming language to a lower level language.
intent creator: set of authorized entities that is able to create an Intent Policy including the User, APP, OSS, BSS and
Orchestrator
NOTE: The Intent Creator submits the Intent Policy to the ENI system through dedicated External Reference
Points.
ETSI
6 ETSI GR ENI 008 V2.1.1 (2021-03)
intent policy target: entity whose behaviour is affected by the Intent Policy
NOTE: For the purposes of the present document, this is either the Assisted System (or its Designated Entity) or
the ENI System itself.
interpreter: computer program that directly executes instructions written in a programming or scripting language,
without requiring them previously to have been compiled into a machine language program (see ETSI
GS ENI 005 [i.2])
policyMetadata: data that describes and prescribes policy characteristics and behaviour (see ETSI GS ENI 005 [i.2])
NOTE: Examples of policyMetadata include a time period that this intent policy is valid, as well as version
information, including a minimum version that will be used.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
APP Application (Functional Block)
BS Base Station
BSS Business Support Systems
CRUD Create Read Update Delete
DPI Deep Packet Inspection
DSL Domain-Specific Language
EMS Element Management System
ENI Experiential Networked Intelligence
EPC Evolved Packet Core
FB Functional Block
IDMS Intent-Driven Management System
IMS IP Multimedia Subsystem
IP Internet Protocol
ITANA InTent Aware Network Autonomicity
NFV Network Functions Virtualisation
NR New Radio
OAM Operating and Maintenance
OPEX OPeration EXpediture
OSS Operations Support System
RAN Radio Access Network
SDO Standard Developing Organization
SFC Service Function Chain
SLA Service Level Agreement
SON Self-Organizing Network
UID Unique IDentifier
VNF Virtual Network Function
4 Introduction
Intent Policy is introduced and defined in clause 6.3.9.3.2 of ETSI GS ENI 005 [i.2], which uses a restricted natural
language (e.g. external DSL) to express the goals of the policy, without describing how to accomplish the goals. The
Intent Policy concept could be applied in various network domains, such as a wireless network and a data centre.
Intent policies enable different users of the ENI System to author policies in a form that a particular constituency of
users understands. For example, business users are able to write Intent Policies using business terms without having to
use a language that they do not normally use, such as a general-purpose programming language like Java or Python.
ETSI
7 ETSI GR ENI 008 V2.1.1 (2021-03)
The Policy Continuum (see clause 6.3.9.6.2 of ETSI GS ENI 005 [i.2]) is used to formally differentiate between the
needs of different constituencies in defining and expressing policy. Each constituency defines a common set of concepts
and terminology. Hence, an Intent Policy Rule for one constituency may be different in structure and content than an
Intent Policy Rule for a different constituency. More importantly, since an Intent statement does not specify how it
should be implemented, every intent statement needs to be translated to a more concrete form for validation and
processing. For example, Business needs are generated from many types of users, such as business users and application
developers. Hence, the ENI system uses the Policy Continuum to represent the different constituencies served and to
translate an intent policy at a higher level of abstraction to a policy at a lower level of translation. Such a translation is
performed one or more times (e.g. to go from a business view to a system view to an administrator view).
5 Impact of Intent Policies on the System Architecture
5.1 Architecture Enhancement for Intent Policies
5.1.1 Scope of Intent Policies
There are two different ways that Intent Policies can be used:
1) An External Entity (e.g. an Operator) sends an Intent Policy to the ENI System that affects the behaviour of
the Assisted System (or its Designated Entity).
2) An External Entity sends a Policy (of any type) to the ENI System that affects the behaviour of the ENI
System.
In each case, the External Entity sends an Intent Policy. The ENI System will translate the Intent Policy, process it, and
then produces a set of recommendations and/or commands that realize the Intent Policy. This is done by the Policy
Management Functional Block of the ENI System. The difference is the target of the Intent Policy:
1) If the target is the Assisted System (or its Designated Entity), then the set of recommendations and/or
commands produced are sent to the Denormalisation and Output Generation Functional Blocks, where they are
denormalised and formatted. They are then sent to the API Broker, which transmits them to the Assisted
System (or its Designated Entity).
2) If the target is the ENI System, then the set of recommendations and/or commands produced are sent to the set
of affected Functional Blocks of the ENI System.
5.1.2 Adding an Intent Translation Functional Block
A new Functional Block named Intent Translation is introduced to support the use of an Intent Policy process that
includes intent translation, intent assurance and the lifecycle management of Intent Policy.
ETSI
8 ETSI GR ENI 008 V2.1.1 (2021-03)

Figure 5-1: Architecture Enhancement for Intent Policy with its Input Reference Points
In this context, the following definitions and considerations apply:
• Intent Translation Functional Block: a Functional Block recommended to be added within the Policy
Management Functional Block that takes part in the process of Intent Translation. It performs lexical analysis,
syntactic analysis, semantic analysis and augmentation, either parsing or compiling and, optionally,
interpretation of the Intent Policy.
• Process of Intent Translation: the procedure to translate the Intent Policy to the desired format executed
internally by the ENI System or transformed into recommendations/commands sent to the Assisted System.
This process is discussed in more detail in clause 5.2.
• Process of Intent Assurance: the procedure to maintain and monitor the execution of an Intent Policy,
including detecting and reporting any conflicts and failures. The use of statistics and possibly analytics to
summarize these aspects of Policy will ensure that the requirements of the Intent Creator (e.g. User/APP/OSS-/
and BSS-like Functionality), see clause 5.2.2 regarding its definition, are satisfied. This process is discussed in
more detail in clause 5.3.
• Operational management of Intent Policy: Create Read Update Delete (CRUD) commands are operations
that affect the state of Intent Policies. Intent policies are sent from an External Entity or the Intent Creator (see
clause 5.4 for more information) to the ENI System. CRUD Intent Policies are used to manage the Assisted
System (or its Designated Entity) or the ENI System itself.
• Intent knowledge: knowledge that is used in the process of Intent Translation. It contains the relevant
policyMetadata (e.g. a time period that this intent policy is valid, as well as version information, including a
minimum version that can be used) and the generated new knowledge (e.g. word and phrase processing and
substitution to translate the original Intent Policy into a form understood by the ENI System for a specific
domain). Metadata and knowledge are stored in the model repository and knowledge repository defined in
ETSI GS ENI 005 [i.2] within the Repository Management Functional Block, respectively.
NOTE: The original form of an Intent Policy uses a restricted natural language. This is likely to contain both
ambiguities in the meaning of the Intent Policy as well as terms familiar to the Intent Creator that need to
be translated to a form that can be understood by the entities affected by this Intent Policy. This is done
by the ENI System. Recommendations and/or commands are produced by the Model-Driven Engineering
FB, which are then packaged as ENI Policies by the Policy Management FB. If the target of the Intent
Policy was the ENI System itself, then no further processing is required, and the ENI System will execute
those recommendations and/or commands. If the target of the Intent Policy was the Assisted System (or
its Designated Entity), then the transformed Intent Policy is denormalised and formatted, and then sent to
the API Broker. The API Broker sends the Intent Policy to the Assisted System (or its Designated Entity).
ETSI
9 ETSI GR ENI 008 V2.1.1 (2021-03)
5.1.3 Reference Points for Intent Policies Implementation
The internal reference points involved in the Intent Policies process are shown in Figure 5-2.

Figure 5-2: Overview of the ENI Internal Reference Points
Table 5-1, depicted further down in clause 5.2.3.2, provides brief descriptions of the Intent Policy and associated
information and/or metadata exchanged during the translation process.
5.2 Translation of Intent Policies
5.2.1 Introduction
Intent Policy is first translated to an intermediate form (a.k.a intermediate representation), which is typically a set of
data structures (and possibly code) that is used to further analyse and transform the original entry. For example, human-
readable text could be transformed into a graph. This type of processing is performed by the Intent Translation
Functional Block, as shown in Figure 5-3. The translation process possibly will use more than one intermediate forms
(e.g. if more than one intent abstraction level needs to be processed).
The second step is to further analyse the Intent Policy, both syntactically and semantically. At this stage, the Intent
Policy is modified to correct errors, remove ambiguities, and transformed into a form that is more conducive for
changing the intermediate form into recommendations and/or commands that the Policy Intent Target is able to
understand. At this point, the Intent Policy is ready to be executed. The data processing may then continue recursively
with Functional Blocks interacting with each other.
In the existing operation of a network, Intent Policy translation is done by experienced operational staff. The use of this
knowledge in an ENI system for Intent Policy translation is for further study.
5.2.2 Intent Policy Translation Functional Block Architecture
The Intent Translation Functional Block is a part of the Policy Management Functional Block, and is responsible for
translating and transforming the original Intent Policy submitted to a set of recommendations and/or commands that can
be applied to the Intent Policy Target. Figure 5-3 shows the Functional Blocks that make up the Intent Translation
Functional Block, as shown inside the dotted light blue rectangle. The outer green rectangle shows the Policy
Management Function Block (which contains the Intent Translation Functional Block). The outer dashed rectangle
denotes the ENI System.
The Intent Translation Functional Block includes the Intent Parser, Syntax Analyser, Semantic Analyser, Local Conflict
Resolution, Intent Abstraction Translator and Intent Policy Compiler. The Policy Decision Engine, Policy Execution
Engine, and Policy Verification Engine are embedded Functional Blocks that perform runtime processing of ENI
Policies within the Policy Management Functional Block. The following parts of this clause will introduce the roles and
tasks allocated to each Functional Block, and then a detailed interaction of flows with other ENI Functional Blocks will
be introduced in clause 5.2.3.
ETSI
10 ETSI GR ENI 008 V2.1.1 (2021-03)
Figure 5-3 shows the involved Functional Blocks to translate Intent Policies. The Functional Blocks interactions inside
the black-dotted box illustrate the process to translate Intent Policies inside the Policy Management Function Block.
The blue box illustrates the import Functional Blocks that are required for the processing of Intent Policies, which
consists of the nested Intent Translation Functional Block.

Figure 5-3: Translation of Intent Policies
Intent Creator: This is a set of authorized entities including the User/APP/OSS/BSS and Orchestrator external entities
that is able to create an Intent Policy. The Intent Creator submits the Intent Policy to the ENI System through dedicated
External Reference Points.
Intent Parser: The Intent Parser is responsible for the initial parsing of the submitted Intent Policy. This typically
consists of lexical analysis, token generation, and syntactic analysis (though other functions can also be included).
Lexical analysis is the first phase, and takes an input (pre-processed to be a sentence), compares it to a grammar, and
then breaks the sentence into sets of characters. The next phase generates tokens from the set of characters that are
defined using the grammar rules of the Intent Policy language (e.g. the identification of nouns and verbs). The final
phase is syntactical analysis, which ensures that the analysed sentence is grammatically correct. For example, the
sentence "Send Host Computer to the Notifications" contains legal tokens, but is grammatically incorrect (it should be
"Send Notifications to the Host Computer"). The output of the Syntactical Analyser is either a Concrete or an Abstract
Syntax Tree. If any error happens during the parsing process, appropriate error messages are sent to the Intent Creator,
and the Knowledge Management Functional Block records the errors for further analysis.
Semantic Analyser: The purpose of the Semantic Analyser is to provide meaning to the output of the Syntax Analyser.
Examples include datatype checking, array bounds checking, proper declaration of variables, and scope resolution. For
example, the expression "int x = "aValue" will pass lexical and syntactic analysis, as it is structurally correct. However,
it will generate a semantic analysis error, since the datatype of the variable does not match the datatype of the value.
The Semantic Analyser in ENI generates gists and keywords to provide additional knowledge to other Functional
Blocks. If any error happens during this process, error messages are sent to the Intent Creator, and the Knowledge
Management Functional Block records the errors for further analysis.
ETSI
11 ETSI GR ENI 008 V2.1.1 (2021-03)
Local Conflict Resolution: This module interacts with the Knowledge Repository and checks if the current Intent
Policy conflicts with any existing Policies. For the purposes of the present document, a policy conflict is defined as two
policies that, when executed, cause contradictory and otherwise incompatible results within a given policy execution
time window. For example, if Intent Policy 1 sets the value of an attribute named numErrors to "2" at 08:00:00, and
intent Policy 2 then sets the value of the numErrors attribute to 3 at 08:00:01, that is a policy conflict. If any conflict is
detected during this process, conflict messages and error information are sent to the Intent Creator, and Knowledge
Management Functional Block records the errors for further analysis.
NOTE 1: While the above definition of a policy conflict applies to imperative policies, there are additional
problems for intent policies. This is for further study.
Intent Abstraction Translator: The Intent Abstraction Translator retrieves knowledge from the Knowledge
Management FB to identify the abstraction level of the input Intent Policy. It then defines the target output abstraction
level, as well as the types of output configuration parameters, based on the semantics of the Intent Policy, the gist and
keywords, and the input abstraction level. Other information, including Intent Policy metadata, could also be used to
help to identify the abstraction levels. The abstraction level refers to the different views of Policy Continuum [i.2]. For
instance, an end user authors an Intent Policy to improve video streaming quality without supplying any technical
details The Intent Abstraction Translator identifies the abstraction level of the input Intent Policy as the business view
level. Similarly, in order to be enforced, the target output abstraction level needs to be at the Instance view level. It is up
to the Intent Translation Functional Block to decide if one or more translations are required between the input and
output abstraction levels. Once the current abstraction level has successfully completed, this module then determines if
another abstraction level translation is required, or if it is finished. If the former, control returns to the Intent parser with
new instructions; if the latter, the completed Intent Policy is sent to the Intent Policy Compiler.
NOTE 2: An alternative would be for the Intent Translation Functional Block to simply map this intent to a known
SLA, such as Gold or Platinum Service.
Intent Policy Compiler: The Intent Policy Complier compiles the finalized Intent Policy output into a form that can be
processed by the Model Driven Engineering Functional Block.
All other Functional Blocks are defined in ETSI GS ENI 005 [i.2] where the policy continuum is specified.
5.2.3 Procedure for Translating DSL Intent Policies
5.2.3.1 Introduction
This clause describes the procedure for intent policy translation when the intent policy is expressed by a DSL, and it is
based on the architecture described in clause 5.1.
5.2.3.2 Translation Overview
Figure 5-4 is a simplified message sequence diagram that illustrates the steps between the visible actors (i.e. the entity
that authors the policy, the ENI System Functional Blocks, and the Assisted System, thus excluding the ENI System
Internal Functional Blocks as well as the ENI System Internal Interfaces). These steps help to describe the Intent
Translation process. Figure 5-5, depicted further down, consists of a more detailed message flow sequence diagram
where interaction amongst all involved ENI Functional Blocks is shown.
ETSI
12 ETSI GR ENI 008 V2.1.1 (2021-03)

Figure 5-4: Simplified Message Sequence Diagram of the
Intent Policy Translation Process excluding Internal Interfaces
The steps are shown from left-to-right, and proceed top-to-bottom, in Figure 5-4. The related activities performed in
each task are the same as those performed by the corresponding Functional Blocks of Figure 5-5. However, the text in
this clause is abbreviated, as it is an overview. These steps assume that the target of the Intent Policy is the Assisted
System (if the target is the ENI System, then the flow is different), and are described as follows:
Step 1. The Intent Creator sends a "1. newPolicy" message to the Data Ingestion and Normalisation FB using
an appropriate External Reference Point. This message consists of three parameters, called
policyRefPoint, policyContent and policyMetadata. The policyRefPoint parameter records the specific
External Reference Point through which this Policy was received. The policyContent parameter
defines the policy, and the policyMetadata parameter contains optional descriptive and/or prescriptive
metadata.
Steps 2-5. The input policy is normalised, enhanced, and given a PolicyID by the Internal Functional Block of
the ENI System. These steps are neither seen by the entity that authored the Intent Policy nor by the
Assisted System.
Step 6a. A response is prepared to the Intent Creator, and sent to the Denormalisation and Output Generation
FB. This step is neither seen by the entity that authored the Intent Policy nor by the Assisted System.
Step 6b. An acknowledgement of the Intent Policy is sent to the entity that authored the Intent Policy (shown
as "6b. ackPolicy") by using an appropriate External Reference Point.
Step 7-13b. The Intent Policy is compiled and augmented with semantic, context, and situation aware information.
The terms in the Intent Policy are then replaced with appropriate information that can be understood
by the entities affected by this Policy, and transformed to an output Policy of the desired type. These
steps are neither seen by the entity that authored the Intent Policy nor by the Assisted System.
Step 13c. The final Intent Policy is sent in a "genPolicyOutput" message via the Semantic Bus to the
Denormalisation and Output Generation FB. This step is neither seen by the entity that authored the
Intent Policy nor by the Assisted System.
Step 14a. The Denormalisation and Output Generation FB denormalises and reformats the Intent Policy (if
necessary).
Step 14b. The Denormalisation and Output Generation FB sends the Intent Policy to the appropriate target
entities in the Assisted System (shown as "14b. applyPolicy") via an appropriate External
Reference Point.
ETSI
13 ETSI GR ENI 008 V2.1.1 (2021-03)
5.2.3.3 Translation Detailed Description
5.2.3.3.1 Interactions of Intent Policy via External Reference Points
Intent Translation FB is a new functional block, which takes part in the process of Intent Translation and is a part of the
Policy Management Functional Block (see clause 5.1.1).
Table 5-1 provides brief descriptions of how an Intent Policy interacts with the External Reference Points of an ENI
System. For each External Entity (e.g. User, BSS, OSS, APP or Orchestrator) the information and metadata that can be
sent to or received from the ENI system during the processing of the Intent Policy is described using the appropriate
External Reference Points (which are defined in ETSI GS ENI 005 [i.2]).
Table 5-1: Information and Data Exchanged for an Intent Policy via an External Reference Point
Name Publishes to External Reference Point Receives from External Reference Point
Intent Policies and associated information and/or
Information, policies, and metadata sent by the
metadata sent from the OSS-like Functionality to
ENI System when processing Intent Policy. This
OSS-like the ENI System that control behaviour of the Intent
can also include notifications and
Functionality Policy Target using E . This can also include
oss-eni-pol
acknowledgements sent to the OSS-like
notifications and acknowledgements sent from the
Functionality.
OSS-like Functionality.
Intent Policies and associated information and/or
metadata sent from the Application to the ENI Information, policies, and metadata sent by the
System that control behaviour of the Intent Policy ENI System when processing Intent Policy. This
Application
Target using Eapp-eni-pol. This can also include can also include notifications and
notifications and acknowledgements sent from the acknowledgements sent to the Application.
Application.
Intent Policies and associated information and/or
Information, policies, and metadata sent by the
metadata sent from the BSS-like Functionality to the
ENI System when processing Intent Policy. This
BSS-like ENI System that control behaviour of the Intent
can also include notifications and
Functionality Policy Target using E . This can also include
bss-eni-pol
acknowledgements sent to the BSS-like
notifications and acknowledgements sent from the
Functionality.
BSS-like Functionality.
Intent Policies and associated information and/or Information, policies, and metadata sent
metadata sent from the User to the ENI System that acknowledged or notified by the ENI System
User control behaviour of the Intent Policy Target using when processing Intent Policy. This can also
Eusr-eni-pol. This can also include notifications and include notifications and acknowledgements sent
acknowledgements sent from the User. to the User.
Intent Policies and associated information and/or
Information, policies, and metadata sent
metadata sent from the Orchestrator to the ENI
acknowledged or notified by the ENI System
System that control behaviour of the Intent Policy
Orchestrator when processing Intent Policy. This can also
Target using E . This can also include
or-eni-pol
include notifications and acknowledgements sent
notifications and acknowledgements sent from the
to the Orchestrator.
Orchestrator.
5.2.3.3.2 Flux Diagram of the Intent Policy Translation Process and steps between actors
Figure 5-5 illustrates the steps between all actors (i.e. the entity that authors the policy, the ENI System Functional
Blocks, and the Assisted System). These steps are part of a detailed message sequence diagram, depicted below, that
helps to describe the Intent Translation process.
ETSI
14 ETSI GR ENI 008 V2.1.1 (2021-03)

Figure 5-5: Detailed Message Sequence Diagram of the
Intent Policy Translation Process including Internal Interfaces
The steps are shown from left-to-right, and proceed top-to-bottom, in Figure 5-5. They are described as follows:
Step 1 Submitting a New Policy
The Intent Creator sends a "1. newPolicy" message to the Data Ingestion and Normalisation FB using an appropriate
External Reference Point (i.e. E , E , E , E , or E ). This message consists of three
oss-eni-pol bss-eni-pol app-eni-pol or-eni-pol usr-eni-pol
parameters, called policyRefPoint, policyContent and policyMetadata. The policyRefPoint parameter records the
specific External Reference Point through which this Policy was received, along with other related information, such as
time and date. The policyContent parameter defines the content of the Intent Policy submitted by the Policy Intent
Creator, and the policyMetadata parameter contains optional descriptive and/or prescriptive metadata. Examples of
descriptive metadata include a description of best current practices and additional purpose information or keywords;
examples of prescriptive metadata include a time period that this intent policy is valid, as well as version information,
including a minimum version that can be used.
Step 2 Normalising the Intent Policy Input
a) The Data Ingestion and Normalisation FB sends the normalised information in "2a. normalisedPolicy"
message to the Knowledge Management FB via the Semantic Bus (see Figure 6-3 in ETSI GS ENI 005 [i.2]).
b) The Knowledge Management FB stores the normalised information in its Policy Repository (shown as "2b").
Step 3 Knowledge Management Internal Process (all 4 steps below are shown as a single step "3" for simplicity)
a) The Knowledge Management FB then examines the policyRefPoint data of the normalisedPolicy message to
determine which external entity has sent this Policy.
b) Once this is determined, it consults a list of agreements between the ENI System and that external entity
describing the operational procedures for processing Policies (e.g. if negotiation is allowed or required for
certain parameters).
c) It then updates the received Policy instance with this information.
d) The Knowledge Management FB also updates the Policy Repository.
ETSI
15 ETSI GR ENI 008 V2.1.1 (2021-03)
Step 4 Begin Translation of the Intent Policy
If the received Policy is an Intent Policy, then the Knowledge Management FB sends a "4. translatePolicy" message to
the Intent Translation FB via the Semantic Bus. Otherwise, the Knowledge Management FB follows the procedures for
a non-Intent Policy.
NOTE: Procedures for I policies that are not Intent Policy are outside the scope of the present document.
Step 5 Intent Translation Internal Process
a) The Intent Translation FB generates a policy identifier (policyID) for the received Intent Policy (shown as
message "5a").
b) The Intent Translation FB updates the Policy Repository by sending a "5b. updPolID" message via the
Semantic Bus.
Step 6 Inform the Entity that Authored the Intent Policy
a) The Intent Translation FB then sends a "6a. prepareAckPolicy" message to the Denormalisation and Output
Generation FB via the Semantic Bus.
b) The Denormalisation and Output Generation FB then sends a "6b. ackPolicy" message to the Intent Creator
via an appropriate External Reference Point; this informs that entity that its Policy has been received and the
ENI System is starting to process it.
Step 7 Intent Translation FB Attempts to Parse the Intent Policy
a) A parser lexical analyser processes the input Policy and attempts to generate tokens. The tokens are then
processed by a syntactic analyser. This process may build an abstract syntax tree (or an equivalent data
structure). This is shown as "7a".
b) IF ERROR:
i) If at any time during the overall parsing and syntactic analysis processes an error is produced the Intent
Translation FB creates a "policyTranslationError" data structure containing at least three parameters
(the type of error, any keywords that have been generated, and as much context and other relevant
information as possible (e.g. line number and word(s) that are not recognized or invalid in this context).
A "genPolTransError" message is sent to the Denormalisation and Output Generation FB (shown as
"7b1") via the Semantic Bus.
ii) A "polTransError" message is sent to the entity that authored the Policy (shown as "7b2") via an
appropriate External Reference Point.
iii) A "polErrorUpd" message is sent to the Policy Repository in the Knowledge Management FB
...