Zero-touch network and Service Management (ZSM); ZSM Framework for NaaS

DGR/ZSM-019_GRonNaas

General Information

Status
Not Published
Current Stage
12 - Citation in the OJ (auto-insert)
Due Date
04-Feb-2026
Completion Date
27-Jan-2026
Standard

ETSI GR ZSM 019 V1.1.1 (2026-01) - Zero-touch network and Service Management (ZSM); ZSM Framework for NaaS

English language
19 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ETSI GR ZSM 019 V1.1.1 (2026-01) is a standard published by the European Telecommunications Standards Institute (ETSI). Its full title is "Zero-touch network and Service Management (ZSM); ZSM Framework for NaaS". This standard covers: DGR/ZSM-019_GRonNaas

DGR/ZSM-019_GRonNaas

ETSI GR ZSM 019 V1.1.1 (2026-01) is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.

Standards Content (Sample)


GROUP REPORT
Zero-touch network and Service Management (ZSM);
ZSM Framework for NaaS
2 ETSI GR ZSM 019 V1.1.1 (2026-01)

Reference
DGR/ZSM-019_GRonNaas
Keywords
abstracted network information, automation

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

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 the
ETSI Search & Browse Standards application.
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 on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
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
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
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 2026.
All rights reserved.
ETSI
3 ETSI GR ZSM 019 V1.1.1 (2026-01)

Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Executive summary . 4
Introduction . 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 Description of NaaS . 7
5 Identity management . 8
5.1 Background . 8
5.2 Supporting framework capabilities and services . 9
6 Variable abstraction management . 10
6.1 Background . 10
6.2 Supporting framework capabilities and services . 10
7 Economic information management . 11
7.1 Background . 11
7.2 Supporting framework capabilities and services . 13
8 Summary and recommendations . 13
Annex A: Application description . 15
Annex B: Change history . 18
History . 19

ETSI
4 ETSI GR ZSM 019 V1.1.1 (2026-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 IPR online database.
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™, LTE™ and 5G™ logo 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) Zero-touch network and
Service Management (ZSM).
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.
Executive summary
The present document examines the ZSM framework in the context of Network-as-a-Service (NaaS), wherein demands
for customer-facing services delivered by ZSM-managed network resources, and related ZSM framework consumer
demands for ZSM framework management services, may originate with entities that are operated by or on behalf of
different organizations, while ZSM management domains may themselves be operated by or on behalf of different
organizations. Information, authority, permissions, data privacy or security requirements, etc. may align with or be
determined or constrained by such organizational differences; implications of this on the ZSM framework and its
components and services are considered. Further, the ZSM framework may leverage abstraction in the operation of
management services. However, not all interactions between a ZSM framework and ZSM framework consumers, or
among ZSM management domains, will or can be equally abstracted. "Variable abstraction management" thus needs to
be accommodated functionally by the ZSM framework. Finally, ZSM management domains and management services
may be sources, and/or consumers, of information related to resource use or scarcity, patterns of resource use on behalf
of different consuming entities, etc. Such information, how it might be used, and how it might be provided or usefully
consumed by ZSM management domains and management services, are considered.
ETSI
5 ETSI GR ZSM 019 V1.1.1 (2026-01)

Introduction
ETSI ISG ZSM defines an architecture and a set of services that together provide capabilities for automatic network and
service management. Collectively, this architecture and set of services is referred to as the ZSM framework [i.1]. ETSI
ISG ZSM has not so far considered, in detail, interactions between the ZSM framework and ZSM framework
consumers. This is somewhat natural in the sense that the focus of ISG ZSM lies within the ZSM framework. However,
the ZSM framework exists to provide services to ZSM framework consumers. It is therefore logical to consider the
ZSM framework in inter-operation with ZSM framework consumers. Consider, for example, a context wherein many
different entities - that differ from one another organizationally, legally and/or administratively - are consuming
services from a given ZSM framework instance. This particular context arises in the Network-as-a-Service (NaaS)
environment, as that term is broadly used. It might require, or benefit from, generating, handling or using information
differently among consuming entities, for functional, data privacy or other reasons. This fact might influence
consideration of detailed functional requirements on certain ZSM data services.
The present document focuses on several aspects of this context-based examination of the ZSM framework:
• As one aspect: as suggested above, demands for customer-facing services delivered by ZSM-managed network
resources, and related ZSM framework consumer demands for ZSM framework management services, may
originate with entities that are operated by or on behalf of different organizations. Further, ZSM management
domains may themselves be operated by or on behalf of different organizations. Information, authority,
permissions, data privacy or security requirements, etc. may align with or be determined or constrained by
such organizational differences. How should the ZSM framework be equipped to deal with this? This aspect is
the subject of clause 5.
• As a second aspect: the ZSM framework may leverage abstraction in the operation of management services.
Abstraction reduces complexity, promotes scalability and facilitates separation of roles and concerns. Intent, as
considered in ETSI GR ZSM 011 [i.2] and ETSI GS ZSM 016 [i.3], represents a highly abstracted mode of
interaction between ZSM framework consumers and a ZSM framework, or among ZSM management
domains. However, not all interactions between a ZSM framework and ZSM framework consumers, or among
ZSM management domains, will or can be equally abstracted. For example, while network service
commissioning might be based on intent and thus use highly abstracted management service interfaces, other
processes - such as auditing and reporting of intent compliance - might require the ZSM framework to
assemble and report much less abstracted information to ZSM framework consumers, or among ZSM
management domains. "Variable abstraction management" thus needs to be accommodated functionally by the
ZSM framework. This aspect is considered in clause 6.
• As a third aspect: ZSM management domains and management services may be sources, and/or consumers, of
information related to resource use or scarcity, patterns of resource use on behalf of different consuming
entities, etc. Such information might be relevant to revenue management operations - including market
segmentation, pricing optimization, dynamic pricing and similar - by ZSM framework consumers or
management domains, or entities associated with them, as well as cost optimization processes. Clause 7
considers such information, how it might be used, and how it might be provided or usefully consumed by ZSM
management domains and management services.

ETSI
6 ETSI GR ZSM 019 V1.1.1 (2026-01)

1 Scope
The present document considers operation of the ZSM framework within a NaaS - Network-as-a-Service - context.
Particular functional requirements on the ZSM framework, and its components or supporting technologies, that are
identified or accentuated by this contextual examination, are described.
The present document is of relevance to IRTF NMRG and IETF NMOP and will be reported to those groups.
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 the present clause were valid at the time of publication, ETSI cannot
guarantee their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI GS ZSM 007: "Zero-touch network and Service Management (ZSM); Terminology for
concepts in ZSM".
[i.2] ETSI GR ZSM 011: "Zero-touch network and Service Management (ZSM); Intent-driven
autonomous networks; Generic aspects".
[i.3] ETSI GS ZSM 016: "Zero-touch network and Service Management (ZSM); Intent-driven Closed
Loops".
[i.4] ETSI GS ZSM 002: "Zero-touch network and Service Management (ZSM); Reference
Architecture".
[i.5] IETF Internet Draft: NASR Use Case and Requirements, version 03 updated 2025-04-23, draft-liu-
nasr-requirements.
[i.6] IETF Internet Draft: Zero-Trust Sovereign AI: Verifiable Geofencing & Residency Proofs for
Cybersecure Workloads, version 03 updated 2025-10-19, draft-lkspa-wimse-verifiable-geo-fence-
03/.
[i.7] IETF Internet Draft: Applicability of Abstraction and Control of Traffic Engineered Networks
(ACTN) to IETF Network Slicing, version 10 updated 2024-08-29, draft-ietf-teas-applicability-
actn-slicing.
[i.8] IETF Internet Draft: SIMAP: Concept, Requirements, and Use Cases, version 07 updated 2025-
11-17, draft-ietf-nmop-simap-concept.
[i.9] ETSI GR ZSM 015: "Zero-touch network and Service Management (ZSM); Network Digital
Twin".
[i.10] ETSI GS ZSM 018: "Zero-touch network and Service Management (ZSM); Network Digital Twin
for enhanced zero-touch network and service management".
ETSI
7 ETSI GR ZSM 019 V1.1.1 (2026-01)

3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
economic information management: generation and consumption, by ZSM framework entities, of information
relevant to revenue management and cost optimization processes, by or on behalf of organizations associated with ZSM
framework consumers and components
identity management: management, within the ZSM framework, of requirements created by the diversity of
organizations associated with ZSM framework consumers and components in a NaaS environment
variable abstraction management: ability of an E2E SMD or MD to tailor abstractions - views of information - as
required for various purposes and interactions with diverse components and entities, through controlled pruning or
addition and refactoring of information
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
BSS Business Support System
E2E SMD E2E Service Management Domain
NOTE: As defined in ETSI GS ZSM 002 [i.4].
MD Management Domain
NOTE: As defined in ETSI GS ZSM 002 [i.4].
NaaS Network-as-a-Service
4 Description of NaaS
Network as a Service - NaaS - is a term that has been used for some time by industry organizations, in marketing
materials and press reports, and to describe some operator products. In different contexts and at different times it has
taken on various detailed meanings. In general, however, the term has implied three categories of characteristics: these
are described below. All are relevant to a view of NaaS for purposes of the present document. As suggested in the
Introduction, that purpose is to create an overall context for use of the ZSM framework that will, ideally, illuminate
most or all detailed requirements or constraints on the ZSM framework.
Potential complexity of network service composition: A network service may comprise connectivity only, or both
connectivity and non-connectivity components (e.g. firewalls). Connectivity services may be of arbitrary topological
complexity, including e.g. point-to-point and multipoint-to-multipoint, and may be based on any network layer
technology or combination of layer technologies. Connectivity service components may be individually customized
with respect to performance targets or constraints such as bandwidth, latency and availability.
Dynamic network service composition: Network services, network service components and their characteristics may
be dynamically created, modified and deleted.
Fragmentation of network service demand sources: Demands for various network services may originate from
multiple sources in parallel, and may pass through multiple stages of collection and management in entities (e.g. BSSs)
that may be under different ownership and/or administrative responsibility. For example, some network services may
originate with retail demands, from enterprises or consumers, provided to a NaaS operator.
ETSI
8 ETSI GR ZSM 019 V1.1.1 (2026-01)

Demands aggregated by that NaaS operator may be presented, in parallel with demands from other sources, to a further
operator, which assembles and manages all demands for presentation to one or more ZSM frameworks that manage the
resources used for network service delivery. See Figure 1: as automation is of interest, network demand sources and
aggregators are represented as entities which interoperate using management services provided by the ZSM framework,
or similar mechanisms operating among systems lying outside the ZSM framework. Again, every entity may be owned
and/or operated by a different administrative entity, including the E2E and management domains within a ZSM
framework. Permutations of network service demand sources, in respect of a given ZSM framework instance, may
evolve over time.
Figure 1: Retail and wholesale network service demand generating entities may interact directly with
one or more ZSM frameworks, directly or via one or more NaaS operator entities (e.g. BSSs)
5 Identity management
5.1 Background
As described in clause 4, demands for network services delivered by ZSM-managed network resources, and related
ZSM framework consumer demands for ZSM framework management services, may originate with entities that are
operated by or on behalf of different organizations. Further, ZSM management domains may themselves be operated by
or on behalf of different organizations.
The present clause considers the implications on ZSM management services of organizational diversity among ZSM
framework consumers and components.
Organizations may require assured privacy and security of:
a) information which they consider proprietary and sensitive; and
b) command and control of services delivered by, or use of resources belonging to, ZSM frameworks or
components of them.
ETSI
9 ETSI GR ZSM 019 V1.1.1 (2026-01)

Such assurance requires, first and fundamentally, that ZSM framework components should be able to associate
management services, data and managed resources with particular entities or organizations either lying outside the ZSM
framework or associated with E2E MDs, MDs or managed resources. Identification of associated entities or
organizations provides a basis for managing related restrictions on use of management services, data and managed
resources, as well as for differential application of permissions management, authentication, encryption or other security
measures. Identifiers, denoting entities or organizations, should be associated with management services, data and
managed resources. To maximize anonymity, such identifiers should be generic: for the most part, within the ZSM
framework, it is necessary only to distinguish entity or organizational associations one from another, not to fully
identify entities or organizations as such.
Identification of associated entities or organizations may also be required for reasons not directly related to privacy or
security. Two such reasons, and the use of identity management mechanisms, are considered in clauses 6 and 7.
Specific impacts of these requirements on ZSM components are considered in detail in clause 5.2.
5.2 Supporting framework capabilities and services
The ZSM architecture is based on management services, each of which has a producer and one or more consumers.
Functional associations of management services construct virtual entities called management functions (see ETSI
GS ZSM 002 [i.4] Appendix C for a representation of management services-management functions relationships).
Management functions are often hosted by or associated with specific MDs or E2E SMDs (i.e. the producers -
especially - of the implicated management services are hosted by or otherwise associated with a particular MD or E2E
MD), while any management services that span inter-MD/E2E SMD boundaries (via the cross-domain integration
fabric) represent "inputs" or - perhaps more predominantly - "outputs" of the management function. This is neither
required nor rigorous: a management function may in and of itself span MDs/E2E SMDs, by making liberal use of
management services that transit the cross-domain integration fabric. Nonetheless, the notions of domain-oriented
management functional partitioning and domain hierarchy are intrinsic to the ZSM architecture. As a rule, each
interaction between a given MD and another MD or E2E SMD, or between a ZSM framework consumer and an E2E
SMD, crosses a boundary that reflects a separation of intrinsic roles, responsibilities, scope of resource control and
visibility, visibility of data and information, etc. In the NaaS context - as described in clause 5.1 - it often also
represents crossing organizational, administrative and/or ownership boundaries. In and around inter-domain boundaries
- here construing the term "domain" broadly to mean all of ZSM framework consumers, E2E SMDs and MDs - is
therefore a logical place to concentrate identity management actions and mechanisms within the ZSM framework.
Following this, the following identity management principles and measures are proposed:
1) Management service producers hosted by or associated with an E2E SMD should create and manage
identifiers (per clause 5.1) that reflect differing identities of extra- (ZSM) framework consumers of those
management services. These identifiers subsequently may be associated with particular instances of
management service operations or lifecycles, data, managed resources, etc. - see 5) below.
2) Management service producers hosted by or associated with an MD should create and manage identifiers (per
clause 5.1) that reflect differing identities of MD- or E2E SMD-hosted or associated consumers of those
services. These identifiers subsequently may be associated with particular instances of management service
operations or lifecycles, data, managed resources, etc., - see 5) below.
3) Management service producers, or the E2E SMDs or MDs that host them or are associated with them, should
maintain any applicable correlations between identifiers received and identifiers generated.
4) As discussed in clause 5.1, identifiers may be generic: they need not in and of themselves reflect any specifics
or details of entities they represent; rather, they need serve only to distinguish one such entity from another.
5) Mechanisms should be defined that serve operationally to associate identifiers with particular instances of
management service operations or lifecycles, data, managed resources, etc. Such mechanisms could include
tokens, session or flow labels, etc. These mechanisms should be operable between ZSM framework consumers
and E2E SMDs, such that the former may provide to the latter a basis for identity-based classification of
interface interactions.
6) A class of identity policy management services should be created, that can host and provide information
related to identity-related policies. Such policies might be used by domains and management services to
govern identity-based access to specific data or information, use of control or orchestration services, etc.
It is noted for emphasis that "identities" - for purposes of the present document - refers to organizational identities that
correlate differentially to management services and/or data or information produced or consumed by them.
ETSI
10 ETSI GR ZSM 019 V1.1.1 (2026-01)

This is distinct from, and incremental to, processes defined elsewhere in ZSM for the registration of, and subscription
for use of, management services themselves. The latter processes extend directly to management functions composed of
management services.
The present document therefore does not deal with identification of management functions such as agents, closed loops
or digital twins as such: only, potentially, with correlation of such management functions to organizational identities.
6 Variable abstraction management
6.1 Background
While it has not been explicitly drawn out within ETSI ISG ZSM documents to date, it is clear that E2E SMDs and
MDs should be able to manage the fact that varying degrees of abstraction will feature in interactions among themselves
and with framework consumers. This is easily appreciated by considering the f
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...