ETSI GR ENI 013 V1.1.1 (2023-01)

Experiential Networked Intelligence (ENI); Intent Policy Model Gap Analysis

DGR/ENI-0023_Int_Policy_Model

General Information

• Status: Not Published
• Technical Committee: ENI - Experiential Networked Intelligence
• Current Stage: 12 - Completion
• Due Date: 02-Jan-2023
• Completion Date: 17-Jan-2023

Standards Content (Sample)

GROUP REPORT
Experiential Networked Intelligence (ENI);
Intent Policy Model Gap Analysis
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 013 V1.1.1 (2023-01)

Reference
DGR/ENI-0023_Int_Policy_Model
Keywords
information model, policies, policy management

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:
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
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
arranty is made of merchantability or fitness
and/or governmental rule and/or regulation and further, no representation or w
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 2023.
All rights reserved.
ETSI
3 ETSI GR ENI 013 V1.1.1 (2023-01)
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 . 7
4 Background and Overview . 8
5 Survey on Existing Areas of Work . 8
5.1 ETSI ENI . 8
5.1.1 Targeted Use Cases and Intent Definitions . 8
5.1.1.1 Use Cases from ENI Specifications . 8
5.1.1.2 Use Case types from ETSI GS ENI 005. 9
5.1.1.3 Use Cases from ETSI GS ENI 001 . 9
5.1.1.4 Intent Definition from ETSI GS ENI 005 . 9
5.1.2 Extracted Requirements from ETSI GS ENI 005 . 10
5.1.3 Intent Information Model . 12
5.1.4 Intent Management as is in ETSI GS ENI 005 . 13
5.1.4.1 Management Roles . 13
5.1.4.2 Management Operations and life cycle . 13
5.2 3GPP SA5 . 14
5.2.1 Targeted Use Case and Intent Definition . 14
5.2.2 SA5 Requirements . 14
5.2.3 Intent Information Model . 16
5.2.4 Intent Management . 17
5.2.4.1 Management Roles . 17
5.2.4.2 Management Operations . 17
5.2.4.3 Life Cycle . 18
5.3 ETSI NFV . 18
5.3.1 Targeted Use-case and Intent Definition . 18
5.3.2 Requirements . 18
5.3.3 Intent Information Model . 20
5.3.4 Intent Management . 20
5.3.4.1 Management Roles . 20
5.3.4.2 Management Operations . 20
5.3.4.3 Life Cycle . 21
5.4 ETSI ZSM . 21
5.4.1 Targeted Use Case and Intent Definition . 21
5.4.2 Requirements . 22
5.4.3 Intent Information Model . 23
5.4.4 Intent Management . 23
5.4.4.1 Management Roles . 23
5.4.4.2 Management Operations . 23
5.4.4.3 Life Cycle . 23
5.5 TM Forum ANP . 24
5.5.1 Targeted Use Case and Intent Definition . 24
5.5.2 Requirements . 24
5.5.3 Model Federation of Intent . 27
5.5.4 Intent Management . 28
5.5.4.1 Management Roles . 28
ETSI
4 ETSI GR ENI 013 V1.1.1 (2023-01)
5.5.4.2 Management Operations and intent Life Cycle . 28
5.6 IRTF NMRG . 28
5.6.1 Targeted Use Case and Intent Definition . 28
5.6.2 IRTF Requirements. 31
5.6.3 Intent Information Model . 32
5.6.4 Intent Management . 32
5.6.4.1 Management Roles . 32
5.6.4.2 Management Operations and Life Cycle . 33
6 Analysis . 33
6.1 Analysis summary . 33
7 Recommendations . 36
7.1 Recommendations on general guidelines . 36
7.1.1 General guidelines . 36
7.1.2 Proposed recommendations . 37
Annex A: Change History . 38
History . 39

ETSI
5 ETSI GR ENI 013 V1.1.1 (2023-01)
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 013 V1.1.1 (2023-01)
1 Scope
The present document contains:
1) work on a gap analysis report on intent information model based on existing SDO work, including the policy
management model as specified by ETSI ISG ENI in the system architecture deliverables; and
2) a list of recommendations on general guidelines addressing the high-level policy model of a number of each
SDO's intent policy model (i.e. 3GPP SA5, NFV, TM Forum, IRTF, and ZSM), and how these guidelines
compare with those stated in the ETSI ENI system architecture.
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.13): "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 GS ENI 019 (V3.1.1): "Experiential Networked Intelligence (ENI); Representing, Inferring,
and Proving Knowledge in ENI".
[i.4] ETSI TS 128 312 (V17.1.1): "LTE; 5G; Management and orchestration; Intent driven management
services for mobile networks (3GPP TS 28.312 version 17.1.1 Release 17)".
[i.5] ETSI GR NFV-IFA 041 (V4.1.1): "Network Functions Virtualisation (NFV); Release 4
Management and Orchestration; Report on Enabling Autonomous Management in NFV-MANO".
[i.6] ETSI GS NFV-IFA 005 (V4.3.1):"Network Functions Virtualisation (NFV) Release 4;
Management and Orchestration; Or-Vi reference point - Interface and Information Model
Specification".
rd
[i.7] 3GPP TR 28.812: "3 Generation Partnership Project; Technical Specification Group Services and
System Aspects; Telecommunication management; Study on scenarios for Intent driven
management services for mobile networks (Release 17)".
[i.8] ETSI GR ZSM 011 (V1.1.1): "Zero-Touch Network and Service Management (ZSM);
Intent-driven autonomous networks; Generic aspects".
[i.9] TM Forum IG1253 (V1.3.0): "Intent in Autonomous Networks".
[i.10] TM Forum IG1253A (V1.1.0): "Intent Common Model".
[i.11] TM Forum IG1253C (V1.1.0): "Intent Life Cycle Management and Interface".
ETSI
7 ETSI GR ENI 013 V1.1.1 (2023-01)
[i.12] IRTF draft-irtf-nmrg-ibn-concepts-definitions-09: "Intent-Based Networking - Concepts and
Definitions", March 2022.
[i.13] IRTF draft-irtf-nmrg-ibn-intent-classification-08: "Intent Classification", May 18, 2022.
[i.14] ETSI GS NFV-IFA 050: "Network Functions Virtualisation (NFV) Release 4; Management and
Orchestration; Intent Management Service Interface and Intent Information Model Specification".
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
API Application Programming Interface
ATTR Attribute
CRUD Create Read Update and Delete
CSC Communication Service Customer
CSP Communication Service Provider
DB Database
DC Data Center
DDOS Distributed Denial of Service Attack
DHCP Dynamic Host Configuration Protocol
DSL Domain Specific Language
ENI Experiential Networked Intelligence
GEN General
GPU Graphics Processing Unit
HD High Definition
IBS Intent-Based Systems
IDA Intent Driven Action
IDO Intent Driven Object
IFA Interface and Architecture
IM Intent Management
INF Information
IPv4 Internet Protocol version 4
IRI Internationalized Resource Identifiers
IRTF Internet Research Task Force
KPI Key Performance Indicator
MEF MEF (a Standards body)
MnS Management Service
MOD Model
MPM MEF Policy Model
NFV Network Functions Virtualisation
NFV-MANO Network Functions Virtualisation Management and Orchestration
NFVO Network Functions Virtualisation Orchestrator
NMRG Network Management
NOP Network Operator
NS Network Service
ETSI
8 ETSI GR ENI 013 V1.1.1 (2023-01)
NSD Network Service Descriptor
OCL Object Constraint Language
OPEX Operating Expense
OSS/BSS Operation Support Systems/Business Support System
QoE Quality of Experience
RAN Radio Access Network
RAT Radio Access Type
RDF Resource Description Framework
REC Recommendation
REQ Requirement
SA5 Service and System Aspects Working Group 5
SDO Standard Development Organization
SD-WAN Software Defined Wide Area Network
UE User Equipment
UML Unified Modeling Language
URI Uniform Resource Identifier
VDI Virtual Desktop Interface
VM Virtual Machine
VNF Virtual Network Function
VPN Virtual Private Network
ZSM Zero touch network & Service Management
4 Background and Overview
With the development of intelligent networks, the requirements for network management are stricter. To improve the
performance of connectivity, bandwidth, latency and reliability, and reduce operational expenditure, the concept of
intent is introduced as a key enabling technology.
Some SDOs have worked on intent, but the concept of intent is still defined differently. However, there are still some
gaps in intent information model, intent management and other aspects are specified requirements to deploy intent in
real world situations is other documents.
In ETSI ISG ENI, intent policy is regarded as a key deliverable to help improve the operator experience. Considering
the gaps in the different definitions and modelling by SDOs, a gap analysis is necessary for the ENI system. The gaps
include but not limited to the following items:
• The definition of intent.
• The targeted use cases.
• The intent information models designed in other SDOs.
• The management of intent, including management roles, life cycles and operations.
The present document is targeted to recognize the gaps on intent information model and provide guidelines for ETSI
ISG ENI.
5 Survey on Existing Areas of Work
5.1 ETSI ENI
5.1.1 Targeted Use Cases and Intent Definitions
5.1.1.1 Use Cases from ENI Specifications
The following ENI use cases are described in ETSI GS ENI 001 [i.1]. There are several use cases that use intent, and
are summarized as follows.
ETSI
9 ETSI GR ENI 013 V1.1.1 (2023-01)
Use Case #3-3: "Intelligent carrier-managed SD-WAN". It is possible for ENI to expose an intent-based interface that
allows enterprises to customize their SD-WAN service using natural language with a terminology that is familiar to
them.
Use Case #3-6, "Intent-based Cloud Management for VDI Service". The Intent-Based Cloud Manager is able to
determine the optimal resource configuration for various user QoE requirements, and present them as intent.
Use Case #5-2: "Limiting profit in cyber-attacks". This use case has a goal of defining an ENI entity that uses machine
learning to detect ransomware and cryptojacking attacks. Once detected, another ENI entity, which uses an intent based
policy language, will propose a set of new security policies to the OSS to mitigate the attack.
5.1.1.2 Use Case types from ETSI GS ENI 005
The ENI System Architecture [i.2] describes two specific use cases for Policies processed by an ENI System. The first
use case type is when an External Entity (e.g. an Operator) sends a Policy (of any type) to the ENI System that affects
the behaviour of the Assisted System (or its Designated Entity). This means that the ENI System will translate the Policy
if needed, process it, and send recommendations and/or commands back to the Assisted System (or its Designated
Entity). Note that an Intent Policy will always require translation as specified in ETSI GS ENI 005 [i.2].
The second use case type is when an External Entity sends a Policy (of any type) to the ENI System that affects the
behaviour of the ENI System. This means that the ENI System will translate the Policy if needed, process it, and act on
it to affect its own behaviour (e.g. add or remove knowledge from the Knowledge Management Functional Block, or
define new goals that it should try and achieve). Note that an Intent Policy will always require translation.
5.1.1.3 Use Cases from ETSI GS ENI 001
Clause 5.1.1.2 describes two types of use cases in ENI. In Table 5.1.1.3-1, the use cases from ETSI GS ENI 001 [i.1]
are listed. In addition, ETSI GS ENI 001 [i.1] uses cases are mapped into ETSI GS ENI 005 [i.2] use case types as
follows:
1) Affect the behaviour of the system being managed.
2) Affect the behaviour of the ENI System.
Table 5.1.1.3-1: The related information of targeted use cases
Creator of Targeted use cases Corresponding clause in Corresponding management layer
intent ETSI GS ENI 001 [i.1] (Business/Service/Resource)
Intelligent carrier-managed 5.4.3 of [i.1]; affects system
CSP Service
SD-WAN being managed
Intent-based Cloud 5.4.6 of [i.1]; affects system
CSP Service
Management for VDI service being managed
5.6.2 of [i.1]; affects system
CSP Limiting profit in cyber-attacks Service
being managed
5.1.1.4 Intent Definition from ETSI GS ENI 005
ETSI GS ENI 005 [i.2] provides the following definitions that involve intent.
policy: set of rules that is used to manage and control the changing and/or maintaining of the state of one or more
managed objects:
• ENI Policy Rules: set of imperative, declarative, and/or intent policy rules.
• intent policy: type of policy that uses statements from a restricted natural language (e.g. an external DSL) to
express the goals of the policy, but does not specify how to accomplish those goals. In particular, Intent Policy
will refer to policies that do not execute as theories of a formal logic.
Hence, an intent policy is one type of policy. This enables other types of policies to interwork with an intent policy.
This is realized using the ENI Extended Policy Model [i.3].
ETSI
10 ETSI GR ENI 013 V1.1.1 (2023-01)
5.1.2 Extracted Requirements from ETSI GS ENI 005
According to the definition and other modelling related content, Table 5.1.2-1 provides the general requirements for
ENI intent policy model.
Table 5.1.2-1: General requirements for ENI intent policy model
Req Number ENI Requirement Description Comments
Intent policy can be used to express the
ENI. INTENT. MODEL. ENI intent policy model is recommended to goals of the policy, but does not specify how
GEN. 001 express the goals of the policy. to accomplish those goals. Based on the
content of clause 6.3.9.3.4 of [i.2].
ENI intent policy model enables intent policies
ENI. INTENT. MODEL Based on the content of clause 6.3.9.3.4 of
to interoperate with imperative and declarative
GEN.002 [i.2].
policies, as well as the combination of these.
ENI intent policy model is able to be used to
ENI. INTENT. MODEL
specify the behaviour of a Domain and entities Based on clause 5.2 of [i.2].
GEN.003
within a Domain.
ENI. INTENT. MODEL ENI intent policy model is able to represent ENI
Based on clause 5.8.3 of [i.2].
GEN.004 recommendations and/or commands.
ENI intent policy model provides model
ENI. INTENT. MODEL
elements to define all or part of a grammar of Based on clause 5.8.3 of [i.2].
GEN.005
one or more Domain Specific Languages.
ENI intent policy model is able to equate goals
ENI. INTENT. MODEL to recommendations or commands (depending
Based on clause 5.8.3 of [i.2].
GEN.006 on operational mode) that result in desired
behavioural changes to the Assisted System.
ENI intent policy model is able to represent
ENI. INTENT. MODEL
context information and incorporate any Based on clause 5.8.3 of [i.2].
GEN.007
contextual changes at runtime.
ENI intent policy model is able to incorporate
situationally aware information and how those
ENI. INTENT. MODEL
information relate to goals to be achieved as a Based on clause 5.8.3 of [i.2].
GEN.008
function of changing situational information at
runtime.
ENI intent policy model is able to provide model
elements to represent the negotiation of how
ENI. INTENT. MODEL
intent policies are defined and executed. The Based on clause 5.8.3 of [i.2].
GEN.009
actual negotiation is done by other mechanisms
using the intent policy model.
It is recommended that the ENI intent policy
ENI. INTENT. MODEL
model have descriptive and/or prescriptive Based on clause 5.8.3 of [i.2].
GEN.010
metadata (in the form of classes or attributes).
ENI intent policy model is recommended to use
ENI. INTENT. MODEL the Policy Continuum to differentiate between
Based on clause 6.3.9.6.2 of [i.2].
GEN.011 the needs of different constituencies in defining
and expressing an Intent Policy.
It is recommended that the ENI intent policy
model contains model elements that represent
ENI. INTENT. MODEL the administrative and operational status of ENI
Based on clause 6.3.9.6.6 of [i.2].
GEN.012 Policies. (ENI Policies are continuously
monitored and updated throughout the life cycle
of the ENI System).
ETSI
11 ETSI GR ENI 013 V1.1.1 (2023-01)
Table 5.1.2-2 provides the general requirements for ENI intent policy model information elements.
Table 5.1.2-2: General requirements for ENI intent policy model information elements
Req Number ENI Requirement Description Comments
The design of information elements of the ENI
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 001 in
intent policy model are recommended to
INFO. 001 Table 5.1.2-1.
express the goals of the policy.
The design of information elements of the ENI
ENI. INTENT. MODEL. intent policy model are recommended to Based on ENI. INTENT. MODEL. GEN. 002 in
INFO. 002 interact with imperative and declarative Table 5.1.2-1.
policies as well as their combination.
The design of information elements of the ENI
intent policy model is recommended to
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 003 in
include model elements that define the
INFO. 003
Table 5.1.2-1.
characteristics and behaviour of a Domain
and entities within a Domain.
The design of information elements of the ENI
intent policy model is recommended to
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 004 in
include model elements that represent ENI
INFO. 004 Table 5.1.2-1.
recommendations and/or commands (as
different classes).
The design of information elements of the ENI
intent policy model is recommended to
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 005 in
include model elements that are able to define
INFO. 005
Table 5.1.2-1.
all or part of a grammar of one or more
Domain Specific Languages.
The design of information elements of the ENI
intent policy model is recommended to
include model elements that are able to
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 006 in
equate goals to recommendations or
INFO. 006 Table 5.1.2-1.
commands (depending on operational mode)
that result in desired behavioural changes to
the Assisted System.
The design of information elements of the ENI
intent policy model is recommended to
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 007 in
include model elements that are able to
INFO. 007 Table 5.1.2-1.
represent context information and incorporate
any contextual changes at runtime.
The design of information elements of the ENI
intent policy model is recommended to
include model elements that are able to
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 008 in
incorporate situationally aware information
INFO. 008 Table 5.1.2-1.
and how those information relate to goals to
be achieved as a function of changing
situational information at runtime.
The design of information elements of the ENI
intent policy model is recommended to
include model elements that are able to
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 009 in
represent the negotiation of how intent
INFO. 009 Table 5.1.2-1.
policies are defined and executed. The actual
negotiation is done by other mechanisms
using the intent policy model.
The design of information elements of the ENI
intent policy model is recommended to
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 010 in
include model elements that are able to
INFO. 010 Table 5.1.2-1.
provide descriptive and/or prescriptive
metadata (in the form of classes or attributes).
The design of information elements of the ENI
intent policy model is recommended to use
ENI. INTENT. MODEL. Based on ENI. INTENT. MODEL. GEN. 011 in
the Policy Continuum to differentiate between
INFO. 011 Table 5.1.2-1.
the needs of different constituencies in
defining and expressing an Intent Policy.
The design of information elements of the ENI
ENI. INTENT. MODEL.
intent policy model is recommended to Based on ENI. INTENT. MODEL. GEN. 012 in
INFO. 012 represent the administrative and operational Table 5.1.2-1.
status of ENI Policies.
ETSI
12 ETSI GR ENI 013 V1.1.1 (2023-01)
Table 5.1.2-3 provides the general requirements for ENI intent policy model attributes.
Table 5.1.2-3: General requirements for ENI intent policy model attributes
Req Number ENI Requirement Description Comments
The design of attributes of ENI intent policy
ENI. INTENT. MODEL. model is recommended to support the log
Based on clause 5.4.6.3.2 of [i.1].
ATTR. 001 data about VDI resource, workload and
performance data.
The design of attributes of ENI intent policy
ENI. INTENT. MODEL.
model is recommended to support the VDI Based on clause 5.4.6.3.2 of [i.1].
ATTR. 002
QoE requirements.
5.1.3 Intent Information Model
The ENI Policy Model is subclassed from the MEF Core Model. Both of these models are being extended by ETSI
GS ENI 019 [i.3]. This enables any set of managed entities defined in the MEF Core Model to be used as the target of
an ENI Policy (i.e. the set of managed entities whose behaviour will be affected by the ENI Policy). It also enables ENI
Policies to make use of other model elements defined in the MEF Core Model, such as Role objects and MetaData.
The ENI Policy Model defines a unified policy model. A unified policy model provides three benefits:
1) It enables different types of policies to be used to accomplish tasks independent of the type or structure of
policy.
2) It enables one type of policy to call any other types of policy.
3) It serves as a common language that enables concepts used by different policy authors to be mapped to
equivalent concepts in other levels.
The ENI Policy Model defines three types of policies from the same information model (i.e. its unified Policy Model).
These three types of policies (i.e. imperative, declarative, and intent) are examples of deriving different types of policies
from a unified policy information model. Clause 6.3.9.6.3.5 of ETSI GS ENI 005 [i.2] describes how to use a unified
model to represent different types of policies.
The unified policy information model is made up of two parts. One of the parts is used to represent the type of policy,
and the other part is used to represent the contents of policy. The type of policy determines the allowed set of policy
components that it can contain.
The MPM uses five important abstractions that collectively enable it to model multiple types of policies:
1) The first is the concept of a policy container. This means that any type of policy will be structured as an object
that is made up of policy components.
2) The second defines two fundamental types of objects, a policy (called MPMPolicyStructure) and a policy
component (called MPMPolicyComponentStructure). Hence, any policy consists of one instance of
MPMPolicyStructure and one or more instances of MPMPolicyComponentStructure.
3) Third, the content of any policy will be made up of one or more statements (called MPMPolicyStatement).
4) Fourth, any MPMPolicyStatement may be made up of one or more clauses (called MPMPolicyClause).
5) Fifth, the type of policy will determine the set of statements that it can contain. This is enforced by a novel
software pattern.
ETSI
13 ETSI GR ENI 013 V1.1.1 (2023-01)
Figure 5.1.3-1 shows a simplified functional diagram of the foundation of the ENI Policy Model.

Figure 5.1.3-1: Simplified Functional Diagram of the ENI Policy Model
Conceptually, the "left side" of Figure 5.1.3-1 represents the type of policy, and the "right side" represents the contents
of the policy. When a given policy is defined on the left side, the set of components that can be used to populate its
content are then defined on the right side.
Figure 5.1.3-1 shows that different types of policies are represented by different subclasses of MPMPolicyStructure.
Once a particular subclass of MPMPolicyStructure is chosen, this choice restricts the types of MPMPolicyStatements
that can be used to define its content. The restriction should be implemented using a combination of the attributes,
methods, and relationships of the MPMPolicyHasMPMPolicyStatementDetail association class. In addition, OCL may
be used for formal specification of these restrictions.
The content of any policy is defined as a set of one or more statements. Any statement can be decorated by subclasses
of the MPMPolicyComponentDecorator class.
For further details of this model, and ENI extensions to it, see ETSI GS ENI 019 [i.3].
5.1.4 Intent Management as is in ETSI GS ENI 005
5.1.4.1 Management Roles
In ETSI GS ENI 005 [i.2] here are two roles within policy management, which are external entity (Assisted System
and/or its Designated Entity and infrastructure, OSS-like functionality, BSS-like functionality, application, orchestrator
and user) and the ENI system (policy management is a functional block within an ENI system). ENI system functions as
the intent handler, and an external entity (except for infrastructure) functions as intent creator.
5.1.4.2 Management Operations and life cycle
ETSI GS ENI 005 [i.2] does not provide a formal life cycle model. However, it does describe the following
management operations:
• Create (see clause 6.3.9.6.5)
• Edit (see clause 6.3.9.6.5)
• Deploy (see clause 6.3.9.6.5)
• Activate (see clause 6.3.9.6.5)
• Meta policies (see clause 6.3.9.6.6)
ETSI
14 ETSI GR ENI 013 V1.1.1 (2023-01)
• Deactivate (see clause 6.3.9.6.5)
• Remove (see clause 6.3.9.6.5)
NOTE: A Metapolicy is a policy that governs the life cycle of another policy.
In addition, clause 6.3.9.6.6 specifies four additional types of policy-specific operations:
• continuously monitoring the working set of policies for correct execution;
• continuously monitoring the working set of policies for possible conflicts;
• continuously look to improve the accuracy of its active knowledge repositories;
• support goal-orientated tasks (i.e. enable the system to focus on dynamic procedures, rather than static,
pre-defined tasks) to reflect the changing prioritization of user needs, business goals, and environmental
conditions.
5.2 3GPP SA5
5.2.1 Targeted Use Case and Intent Definition
The definition of intent is "expectations including requirements, goals and constraints given to a 3GPP system, without
specifying how to achieve them" in ETSI TS 128 312 [i.4]. intent is recommended to be understandable for humans and
needs to be interpreted by machines unambiguously.
The detailed information of targeted use-cases in ETSI TS 128 312 [i.4] is found in Table 5.2.1-1.
Table 5.2.1-1: The related information of targeted use-cases
Creator of Targeted use-cases Corresponding clause in Corresponding management layer
intent ETSI TS 128 312 [i.4] (Business/Service/Resource)
Intent containing an
expectation for delivering 5.1.1.1 Service
radio network
Intent containing an
CSP expectation for delivering a 5.1.2.1 Service
radio service
Intent containing an
expectation for delivering a 5.1.3.1 Service
service
Intent containing an
expectation on coverage 5.1.4.1 Resource
performance to be assured
NOP Intent containing an
expectation on RAN UE
5.1.5.1 Resource
throughput performance to
be assured
5.2.2 SA5 Requirements
According to the use cases, definition and other modelling related content, Table 5.2.2-1 provides the general
requirements for 3GPP management system intent model.
ETSI
15 ETSI GR ENI 013 V1.1.1 (2023-01)
Table 5.2.2-1: General requirements for 3GPP management system intent model
Req Number SA5 Requirement Description Comments
The 3GPP management system intent model
Based on the definition of intent, an intent is
3GPP. INTENT. supports one or more intent expectations that
made up of requirements, goals and
MODEL. GEN. 001 express the requirements, goals and
constraints given to a 3GPP system.
constraints of the intent creator.
Among all the use cases (except "Intent
containing an expectation for delivering a
3GPP. INTENT. The 3GPP management system intent model
service"), the MnS producer is recommended
MODEL. GEN. 002 supports the reporting of intent.
to notify the MnS consumer about the
fulfillment information.
The intent model of 3GPP management
system is not defined separately and thus is
The 3GPP management system intent model
expected to leverage the semantics and
aligns with the semantics and structure of the
3GPP. INTENT. requirements expressed in 3GPP
existing 3GPP Model (e.g. network resource
MODEL. GEN. 003 documentation.
model) and is capable of using the specified
For example, the
3GPP design and information.
<> Intent inherits
from <> TOP.

Table 5.2.2-2 provides the general requirements for 3GPP management system intent model information elements.
Table 5.2.2-2: General requirements for 3GPP management system intent model
information elements
Req Number SA5 Requirement Description Comments
The designing of information elements of
3GPP management system intent model
3GPP. INTENT. Corresponding to the 3GPP. INTENT.
supports one or more intent expectations to
MODEL. INFO. 001 MODEL. GEN. 001 in Table 5.2.2-1.
express the requirements, goals and
constraints of intent creator.
The designing of information elements of
3GPP. INTENT. Corresponding to the 3GPP. INTENT.
3GPP management system intent model
MODEL. INFO. 002 MODEL. GEN. 002 in Table 5.2.2-1.
supports the reporting of intent.
The designing of information elements of
3GPP management system intent model
3GPP. INTENT. aligns
...