ETSI GR ZSM 015 V1.1.1 (2024-02)

Zero-touch network and Service Management (ZSM); Network Digital Twin

DGR/ZSM-015_NDT

General Information

• Status: Not Published
• Technical Committee: ZSM - Zero-touch network and Service Management
• Current Stage: 12 - Completion
• Due Date: 29-Feb-2024
• Completion Date: 22-Feb-2024

Standards Content (Sample)

GROUP REPORT
Zero-touch network and Service Management (ZSM);
Network Digital Twin
Disclaimer
The present document has been produced and approved by the Zero-touch network and Service Management (ZSM) 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 ZSM 015 V1.1.1 (2024-02)

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

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

© ETSI 2024.
All rights reserved.
ETSI
3 ETSI GR ZSM 015 V1.1.1 (2024-02)
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 . 8
3.3 Abbreviations . 8
4 Introduction of Network Digital Twin . 9
4.1 Concept of Network Digital Twin . 9
4.1.1 Introduction. 9
4.1.2 Examples of NDT Taxonomy . 10
4.2 Generic benefits of Network Digital Twin . 10
4.3 Emulation, Simulation and Modelling Time . 11
4.4 Industry progress of Digital Twin . 12
4.4.1 Introduction. 12
4.4.2 Digital Twin Industrial progress . 12
4.4.3 Standardization of the Network Digital Twin . 13
4.4.4 Synergies between Industrial DT and NDT . 13
5 Examples of use cases using NDT . 14
5.1 Radio network energy saving . 14
5.1.1 Description . 14
5.1.2 Use case details . 14
5.2 Network Slicing risk prediction . 14
5.2.1 Description . 14
5.2.2 Use case details . 15
5.3 Signalling storm simulation and analysis . 16
5.3.1 Description . 16
5.3.2 Use case details . 16
5.4 Machine Learning Training . 17
5.4.1 Description . 17
5.4.2 Use case details . 17
5.5 DevOps-Oriented Certification . 17
5.5.1 Description . 17
5.5.2 Use case details . 18
5.6 ML inference-impact emulation . 18
5.6.1 Description . 18
5.6.2 Use case details . 18
5.7 A QoT-Oriented NDT for Optical Networks. 19
5.8 Network Playback to perform historical incident analysis . 20
5.8.1 Description . 20
5.8.2 Use case details . 20
5.9 Data generation for NDT . 21
5.9.1 Description . 21
5.9.2 Use case details . 21
5.10 NDT resource management and orchestration . 21
5.10.1 Description . 21
5.10.2 Use case details . 22
5.11 NDT Time Management . 23
5.11.1 Description . 23
5.12 NDT consumer preference . 24
ETSI
4 ETSI GR ZSM 015 V1.1.1 (2024-02)
5.12.1 Description . 24
5.12.2 Use case details . 25
5.13 NDT Fault Injection Analysis . 25
5.13.1 Description . 25
5.13.2 Use case details . 25
5.14 NDT data accuracy . 26
5.14.1 Description . 26
5.14.2 Use case details . 26
6 NDT for zero-touch Network and Service management . 27
6.1 Principles . 27
6.2 NDT Mapping to ZSM Architecture . 29
6.2.1 Analyzing NDT . 29
6.2.2 Controlling NDT . 30
6.3 Potential new ZSM Framework Capabilities to support the NDT . 30
6.3.1 Generic Capabilities . 30
6.3.2 Data collection . 31
6.3.3 Data Generation . 31
6.3.4 Historical capabilities . 31
6.3.5 NDT ML inference-impact emulation . 32
6.3.6 NDT resource orchestration capabilities . 32
6.3.7 NDT Time Management Capabilities . 32
6.3.8 NDT consumer preference capabilities . 33
6.3.9 NDT Fault injection capabilities . 33
6.3.10 NDT data accuracy capabilities . 33
Annex A (informative): Change history . 34
History . 36

ETSI
5 ETSI GR ZSM 015 V1.1.1 (2024-02)
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) 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.

ETSI
6 ETSI GR ZSM 015 V1.1.1 (2024-02)
1 Scope
The present document describes the Network Digital Twin concept, investigates its applicability for automation of zero-
touch network and service management and introduces existing, emerging and future scenarios that can benefit from it.
Principles and functionality needed to support and utilize the Network Digital Twin for zero-touch network and service
management is introduced, considering also state of the art.
The present document outlines recommendations of additional capabilities needed in the ZSM framework to support
Network Digital Twins.
The present document identifies existing specifications and solutions (both ETSI and external ones) that can be
leveraged to maximize synergies. Collaboration with other SDOs (e.g. in IRTF NMRG, ITU-T SG13) are recommended
when appropriate.
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] A. M. Madni, C. C. Madni and S. D. Lucero: "Leveraging digital twin technology in model-based
systems engineering", MDPI Systems, vol. 7, no. 7; doi:10.3390/systems7010007, 2019.
[i.2] Y. Wu, K. Zhang and Y. Zhang: "Digital Twin Networks: A Survey", IEEE Internet of Things J.,
vol. 8, no. 18, pp. 13789-13804, September 2021.
[i.3] draft-irtf-nmrg-network-digital-twin-arch: "Digital Twin Network: Concepts and Architecture", C.
Zhou, H. Yang, D. Lopez, A. Pastor, Q. Wu, M. Boucadair, C. Jacquenet.
[i.4] ETSI GS ZSM 007: "Zero-touch network and Service Management (ZSM); Terminology for
concepts in ZSM".
[i.5] ETSI GS ZSM 003: "Zero-touch network and Service Management (ZSM); End-to-end
management and orchestration of network slicing".
[i.6] ETSI GS ZSM 002: "Zero-touch network and Service Management (ZSM); Reference
Architecture".
[i.7] Recommendation ITU-T Y.3090: "Digital twin network - Requirements and architecture".
[i.8] draft-chen-nmrg-dtn-interface: "Requirements for Interfaces of Network Digital Twin", D. Chen,
H. Yang, C. Zhou, March 2023.
[i.9] draft-paillisse-nmrg-performance-digital-twin-01: "Performance-Oriented Digital Twins for Packet
and Optical Networks", J. Paillisse, P. Almasan, M. Ferriol, P. Barlet, A. Cabellos, S. Xiao, X. Shi,
X. Cheng, C. Janz, A. Guo, D. Perino, D. Lopez, A. Pastor, April 2023.
ETSI
7 ETSI GR ZSM 015 V1.1.1 (2024-02)
[i.10] draft-yz-nmrg-dtn-flow-simulation-01: "Digital Twin Network Flow Simulation", H. Yang, C.
Zhou, April 2023.
[i.11] draft-yc-nmrg-dtn-owd-measurement-01: "One-way delay measurement method based on Digital
Twin Network", H. Yang, D. Chen, April 2023.
[i.12] C. Janz, Y. You, M. Hemmati, Z. Jiang, A. Javadtalab, J. Mitra: "Digital Twin for the Optical
Network: Key Technologies and Enabled Automation Applications", IEEE/IFIP International
Workshop on Technologies for Network Twins, Budapest, Hungary, April 2022.
[i.13] ETSI GS ZSM 012: "Zero-touch network and Service Management (ZSM); Enablers for Artificial
Intelligence-based Network and Service Automation".
[i.14] ISO 23247 series (2021): ""Automation systems and integration -- Digital twin framework for
manufacturing".
[i.15] IEC 62832-2 (2020): "Industrial-process measurement, control and automation - Digital factory
framework - Part 2: Model elements".
[i.16] IEEE 1451™: "Standard for a Smart Transducer Interface for Sensors and Actuators - Common
Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats".
[i.17] IEEE 2888™ series.
[i.18] IEEE P2888.1™: "Specification of Sensor Interface for Cyber and Physical World".
[i.19] IEEE P2888.2™: "Standard for Actuator Interface for Cyber and Physical World".
[i.20] IEEE P2806.1™: "Standard for Connectivity Requirements of Digital Representation for Physical
Objects in Factory Environments".
[i.21] IEEE 2888.3™: "Orchestration of Digital Synchronization between Cyber and Physical World.
document".
[i.22] ISO/IEC AWI 30172:" Digital Twin : Use Cases".
[i.23] ISO/IEC AWI 30173: "Digital Twin : Concepts And Terminology".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS ZSM 007 [i.4] and the following apply:
data drift: change in observed behaviour of the physical twin, as manifested in observed data or data patterns,
suggesting that performance of NDT models may be degraded
NOTE: Examples for data patterns are peak hour KPI, traffic distribution, user distribution, workday, weekend
patterns etc.
digital twin: digital counterpart of the physical twin that captures its attributes, behaviour and interactions
NOTE: In the context of the present document the digital twin is referred as the Network Digital Twin (or NDT).
input data accuracy: accuracy of the input data used for the NDT model compared with the corresponding behaviour
of the physical twin at the same time as related to the NDT virtual time
NDT master virtual clock: NDT virtual clock that provides virtual time reference for synchronizing a set of NDT
virtual clocks
NDT time delay: time delay that specifies the delay associated with data collection from the physical twin and
processing of the same data in the NDT
ETSI
8 ETSI GR ZSM 015 V1.1.1 (2024-02)
NDT virtual clock: clock that provides NDT virtual time
NDT virtual time: time used by the NDT MnS
NOTE: NDT virtual time is artificial time used in NDT modelling, simulation or emulation
output data accuracy: accuracy of the NDT output data compared with the corresponding behaviour observed in the
physical twin at the same time as related to the NDT virtual time
physical twin: object, system, process, software or environment that the digital twin is designed to replicate and
represent virtually
NOTE: In the context of the present document the physical twin is a communications network, or some part of
one, including e.g. physical network elements and components, virtualized network functions (VNFs - i.e.
network functional elements instantiated as software-based entities), the physical hosts for such VNFs,
services and traffic, etc.
twinning: process that creates and maintains a digital twin corresponding to a particular physical twin
NOTE 1: In the context of the present document twinning is the process that creates and maintains the NDT.
NOTE 2: Maintain means ongoing actions that are taken to keep the digital twin aligned (or 'twinned') to the
physical twin.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS ZSM 007 [i.4] and the following apply:
AN Access Network
C-Plane Control Plane
CN Core Network
GAN Generative Adversarial Network
M-Plane Management Plane
NDT Network Digital Twin
TN Transport Network
U-Plane User Plane
ETSI
9 ETSI GR ZSM 015 V1.1.1 (2024-02)
4 Introduction of Network Digital Twin
4.1 Concept of Network Digital Twin
4.1.1 Introduction
Digital Twins (DTs) are an increasingly examined technology relevant to system automation. A DT is a virtual replica
of a real-world system - a "physical" system - on which operations can be performed [i.1]. The observed outcomes and
effects of such operations constitute information that can be used e.g. to inform operational decision-making, including
within automation-supporting closed loops.
A Network Digital Twin (NDT) is a DT whose physical counterpart is a communications network, or some part of one
[i.2]. The communications network can include e.g. physical network elements and components, virtualized network
functions (VNFs - i.e. network functional elements instantiated as software-based entities), the physical hosts for such
VNFs, services and traffic, etc.
In [i.3], it is proposed that an NDT encompasses four components: data, models, interfaces and mapping (referring to
between digital entities and their real-world counterparts). Data and models constitute the functional core of an NDT.
"Data" can include information about the network, its use, and its environment; e.g.:
• physical and virtual equipment types, functions and capabilities;
• network topology and configuration;
• services or traffic;
• network element, or network element component, health and status (e.g. fault management data);
• service or network element performance data;
• network environmental data;
• interface-related information, including interface operations;
• histories of any or all of the above;
• etc.
Specific data consumed by an NDT is determined by the requirements of targeted use cases.
"Models" can include information and data models used to represent e.g. network or service topology or configuration,
and also behavioural models used to compute the physical network, service or other behaviours expected in postulated
scenarios. Specifics of required models, including the required accuracies of behavioural models, are determined by the
requirements of targeted use cases.
The functional perimeter of an NDT can be viewed as limited to the information-generating function: an "Analyzing
NDT". Alternatively, it can be viewed as the information-generating function and encompassing other functions, such
as additional closed loop stages, that are needed to drive actions on the physical twin: a "Controlling NDT".
An Analyzing NDT can be used to determine the expected behavioural impacts of changes to network, traffic, service,
environmental or other conditions, or of prospective operational actions. A Controlling NDT additionally can make
operational decisions based on such assessments and drive those decisions forward into actuation on the physical twin.
ETSI
10 ETSI GR ZSM 015 V1.1.1 (2024-02)
Achieving highly accurate behavioural predictions requires that behavioural models have access to as much current data
as possible, representing in detail the "twinned" physical network, services, traffic, environment etc. The use by NDTs
of copious and current data specific to the physical networks they represent lies at the heart of the notion of "twinning"
and distinguishes NDTs from generic behavioural simulations and their uses. However, in many cases, NDTs are used
to predict behaviours that would occur in scenarios - circumstances, actions, etc. - that are at least partly hypothetical or
prospective, rather than strictly representing the actual state of the physical network. In such cases, current network data
may be modified or complemented for use by the NDT in order to specify scenarios for which behavioural prediction is
sought.
4.1.2 Examples of NDT Taxonomy
There are many diverse network and service management automation use cases such as visualization, monitoring,
planning, validation, analytics and optimization, etc. which pose diverse requirements to network digital twins and to
their implementation. To be able to define and describe network digital twins, a common taxonomy would be useful.
The following gives a list of examples of NDT properties and options for each property, which may be used to describe
a network digital twin in the taxonomy or scope:
• Use case: planning, monitoring, optimization, visualization.
• Interaction with the physical twin:
- Including if there is interaction from the NDT to the network, i.e. Analyzing or Controlling, frequency,
characteristics of such interaction, etc.
• Aggregation level: network element, single domain, multi-domain.
• NDT deployment level: application, service management, network management.
• Twinned network size.
• NDT can be used to implement use cases, capabilities, functionalities, and roles that may be mapped to
specific planes such as U/C/M plane.
Below are some examples for plane specific NDTs:
• NDTs may support C-Plane related use cases which controls parts of the network. For example, an NDT for a
C-Plane may simulate various future or expected user mobility patterns and demand distributions (e.g.
coverage or capacity or service distributions) modelling of future events, generate relevant policies for the
network and provisioning them to the PCF. The power of NDT in these cases specifically is its ability to
accurately evaluate the real network's response to future or predicted demands as well as the network's
behaviour. The best outputs of the NDT are then ready for ingestion to the network.
• NDTs may support U-Plane use cases such as estimating the impact of potential UPF QoS policies on the
current traffic pattern. Such use cases need access to the real traffic or matching traffic patterns rather than
working with a statistically simulated traffic mix.
• NDTs may support M-plane use cases by providing emulation or simulation of management functionality such
as configuration management, performance management fault management, services and processes of the
management plane of the physical twin.
4.2 Generic benefits of Network Digital Twin
The following benefits can be obtained from network digital twins:
• A network digital twin may have access to real-time data, which facilitates accurate verification of network
and service configurations, deployments, etc., before their application on the counterpart physical network.
This reduces operational risks and unintended adverse impacts.
• A network digital twin may have access to historical as well as current data, so that it can "replay" a historical
status, for example to analyse past network and services issues (e. g. failures, network congestions, etc.). In
addition, data analysis can be used to predict potential network and service issues in the future.
ETSI
11 ETSI GR ZSM 015 V1.1.1 (2024-02)
• A network digital twin may have access to additional contextual data (e.g. environmental data, etc.), which
allows verification, simulation, etc. in a realistic environment.
• Network digital twins facilitate data sharing and organizational collaboration. For example, in the case of a
natural disaster forecast, the autonomous network can be informed of potential issues and it can make
automatic adjustments based on this.
NOTE: Additional advantages that fit in terms of network digital twin is for further study.
4.3 Emulation, Simulation and Modelling Time
An NDT is a digital replica of its corresponding physical twin. The fidelity of the correspondence is generally of
primary concern. Such fidelity is determined by two factors:
a) The completeness, accuracy and currency in time of physical twin-related data available to the NDT. Such data
is used by models that represent network, element, service or related states, configurations or conditions (e.g.
YANG models), and by functional or behavioural models that emulate or simulate behaviours.
b) The completeness of state models describing states, configurations or conditions, and the quality of functional
or behavioural models that emulate or simulate behaviours.
Functional or behavioural models may represent either emulations or simulations. In a computing science context,
emulation typically refers to the complete imitation of a machine running binary code. The objective of this is to
duplicate as exactly as possible the detailed processes by which the emulated object operates, which is a satisfactory
general description of emulation methods. Simulation, on the other hand, makes use of mathematical models,
algorithms, transfer functions, etc. in order to generate targeted behavioural predictions. An emulation mimics in detail
the detailed workings of an object and thus may capture a broad range of its detailed behaviours; a simulation operates
at a more abstracted level and focuses more narrowly on particular aspects of behaviour.
As an example, consider the examination of traffic-dependent congestion on a network. An emulation approach might
model traffic as actual series of frames, which are buffered to varying degrees - leading to delays and frame discards - at
individual elements across the network. Metrics of interest, such as frame loss and delay statistics, might then be
determined from inspection of the outcomes of this detailed modeling. A simulation approach, on the other hand, might
use statistical models to estimate these metrics directly.
The use of emulation or simulation may be required or preferred depending on circumstances. For example, physical
behaviours, such as thermal generation, noise generation, wave propagation, etc. cannot be emulated by a digital
replica. NDTs should use simulation methods to predict such behaviours. On the other hand, some behaviours that
derive from digital functions and operations might best be predicted by emulation methods. Still other behaviours might
be adequately predicted by emulation or simulation. Finally, hybrid techniques may be envisaged, wherein particular
behaviours are modeled on atomic elements using simulation methods, while network-level behaviours are determined
by assembling the results of such "micro-simulations" on an emulation-like basis. The types of behaviours to be
predicted, for what purpose, and with what needed fidelity or precision, thus determine not only the use of emulation or
simulation methods, but also influence specific choices regarding model types, construction and execution.
Requirements on what might be called "modelling time" may also influence or be affected by choices regarding
modelling methods. As emulation replicates physical twin operations and processes in detail, it should to a large degree
respect sequences and relative timing of operations, processes and their consequences. Emulation therefore is time-
based, with timing coordination required between the physical and digital twins. Retrospective, forward-looking and
accelerated emulation of events are not precluded, given appropriate timing coordination management; however,
forward-looking or accelerated emulation may involve considerable demands on NDT computing resources, as
operations and events should be "played out." Simulation is typically less rigorously time-based. In some circumstances
it may involve no notion of time whatsoever: e.g. given a particular, postulated hypothetical state and conditions,
predict other aspects of the same hypothetical state and conditions. In general, simulation may permit a full or partial
"collapsing" of time and events. In some circumstances this can lead to a relative greater efficiency, in computational
resources and execution time, of simulation vs. emulation.
ETSI
12 ETSI GR ZSM 015 V1.1.1 (2024-02)
4.4 Industry progress of Digital Twin
4.4.1 Introduction
The process of standardization of the Digital Twin started several years ago mainly driven by the industry 4.0 and the
need to standardize the architecture for the digital representation of processes for smart factories. Within this push, the
ISO established the Digital twin framework for manufacturing (ISO 23247 series of standards [i.14]).
However, only lately ICT related Standards Developing Organization (SDO) have started the process of standardization
of a network digital twin.
4.4.2 Digital Twin Industrial progress
With the increase in digitalization, adaptation of the digital twin technology in various industries and fields have been
increasing too. This clause summarizes some of digital twin related industrial activities in the non-telecom domains.
The standardization efforts in ISO are paying more attention to digital twins in industry and relative fields.
Committee 184, and its subcommittee "Industrial Data" has a standard series for smart manufacturing, and several other
digital twin standardization projects related to industrial data and systems. ISO also created a work group named
ISO/IEC JTC 1/SC 41/WG6 which specifically focuses on digital twin standardization, including concepts, terminology
(ISO. ISO/IEC AWI 30173 [i.23]), use cases (ISO. ISO/IEC AWI 30172 [i.22]) and related technologies of digital twin
(ISO. ISO 23247 (2021) [i.14]).
The International Electrotechnical Commission (IEC) has a digital twin related working group IEC/TC65/WG24 which
provides guidance for Asset Administration Shell (AAS), which can be considered as an implementation method of
digital twin in smart manufacturing. AAS provides solutions for real world asset representation in the information world
by structures, properties, and services in order to benefit industrial operation and management process (IEC.
IEC 62832-2 (2020) [i.15]).
The IEEE-SA Digital Representation Working Group (IEEE-SA DR_WG) provides a series of standards in digital
representation for various elements in the digital twin. IEEE 1451 [i.16] proposes a solution for sensor interface, it
provides a common interface by creating a self-descriptive electric datasheet and a network-independent smart
transducer object model, which allows sensor manufacturers to support multiple networks and protocols, thus
facilitating the plug and play of sensors to networks:
• Standard series IEEE 2888 [i.17], this standard series comprehensively defines interface between cyber (digital
twin) and physical world.
• IEEE P2888.1 [i.18] and IEEE P2888.2 [i.19] defines the vocabulary, requirements, metrics, data formats, and
APIs for acquiring information from sensors and commanding actuators, providing the definition of interfaces
between the cyber world and physical world.
• IEEE P2806.1 [i.20] proposes digital representation for digital twin, it defines high-speed protocol conversion,
unified data modelling, and data access interfaces for heterogeneous data situations in the digital twin.
• IEEE 2888.3 [i.21] provides a framework overlooking interactions between general objects in cyber and
physical world, including capabilities to interact between physical things and digital things (cyber things),
capabilities to easily integrate with backend infrastructure / integrate with other external systems, capabilities
to access to things by authorized parties, capabilities to describe physical devices, virtual devices, or anything
that can be modelled.
The Digital Twin Consortium is a worldwide industry association that aims to boost the growth and use of digital twin
technology. By bringing together top companies, academic institutions, and government organizations, the consortium
seeks to foster collaboration and promote the progress of digital twin technology across a wide range of industries such
as healthcare, aerospace, and manufacturing (with over 200 organizations involved). Their goal is to encourage the
widespread adoption of digital twin technology, create new business opportunities, enhance efficiency, and drive
innovation. Additionally, the consortium is actively engaged in the development of digital twin technology standards,
including the ISO 23247 [i.14] standard for digital twin framework and the IEEE 1451 [i.16] standard for digital twin
data interoperability.
ETSI
13 ETSI GR ZSM 015 V1.1.1 (2024-02)
4.4.3 Standardization of the Network Digital Twin
ITU has published the Recommendation ITU-T Y.3090 [i.7] which describes the requirements and architecture of a
Digital Twin Network (DTN) as defined in the ITU-T. At this time, version 1.0, published in February 2022, is
enforced. The scope of the recommendation includes:
• Functional requirements of DTN
• Service requirements of DTN
• Architecture of DTN
• Security considerations of DTN
IRTF has done the most extensive work on NDT so far with several internet-drafts published. The main draft [i.3]
provides the concept, basic definition and reference architecture for the NDT.
Within IRTF, there are also a number of interesting individual drafts (at the time of writing not yet endorsed by the
IRTF). These include:
• Requirements for Interfaces of Network Digital Twin [i.8]: which defines requirements for interfaces for the
Network Digital Twin, including northbound interfaces to applications to use the capabilities provided by the
NDT, southbound interfaces between the digital twin and its physical counterpart, and internal interfaces.
• Accurate prediction of packet network performance metrics [i.9]: an NDT that predicts metrics such as end to
end path/link delay, jitter, and loss for a packet network; optical channel terminal powers and margins for an
optical network.
• High-precision simulation of network traffic [i.10]: an NDT that simulates traffic flows by replicating the
forwarding paths, netw
...