ETSI GR ZSM 015

V1.1.1 (2024-02)

Contents

Foreword ............................................................................................................................................................. 5

1 Scope ........................................................................................................................................................ 6

4.3 Emulation, Simulation and Modelling Time .................................................................................................... 11

5.2.2 Use case details ........................................................................................................................................... 15

5.3.2 Use case details ........................................................................................................................................... 16

5.4.2 Use case details ........................................................................................................................................... 17

5.8.2 Use case details ........................................................................................................................................... 20

5.9.2 Use case details ........................................................................................................................................... 21

6.3.1 Generic Capabilities .................................................................................................................................... 30

[i.20] IEEE P2806.1™: "Standard for Connectivity Requirements of Digital Representation for Physical

[i.21] IEEE 2888.3™: "Orchestration of Digital Synchronization between Cyber and Physical World.

document".

3 Definition of terms, symbols and abbreviations

For the purposes of the present document, the terms given in ETSI GS ZSM 007 [i.4] and the following apply:

of the physical twin at the same time as related to the NDT virtual time

virtual clocks

NDT time delay: time delay that specifies the delay associated with data collection from the physical twin and

NDT virtual time: time used by the NDT MnS

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

NOTE 1: In the context of the present document twinning is the process that creates and maintains the NDT.

For the purposes of the present document, the abbreviations given in ETSI GS ZSM 007 [i.4] and the following apply:

4 Introduction of Network Digital Twin

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

functions (VNFs - i.e. network functional elements instantiated as software-based entities), the physical hosts for such

VNFs, services and traffic, etc.

• service or network element performance data;

• network environmental data;

• interface-related information, including interface operations;

• histories of any or all of the above;

• etc.

"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

capacity in the core network. This might in turn lead to a signalling storm, eventually causing serious impacts on

network performance.

impact of optimization actions derived by management services (e.g. domain intelligence services). While handling

signalling traffic, the network digital twin provides the capabilities as described below:

1) The NDT could predict terminal reconnection growth in the physical network. To do so, it could utilize data

such as the number of current subscribers, signalling traffic collected in recent and historical periods, predicted

1) Train an ML model using imported data in a specific training environment (e.g. the ML developer lab).

2) Retrain an ML model with data measured in the context of a deployed environment when deploying the model

The traditional method involves training in multiple stages, which consumes human resources and time to build the

environment and measured data. By using the NDT, however, it is possible to acquire data from the NDT automatically,

which reflects the situation of the deployed environment in real time for model training resulting in cost reduction as a

post-deployment after deployment to a deployed environment. Therefore, the performance can be evaluated using a

the E2E service management domain and/or management domain. The AI training data management service

specified in ETSI GS ZSM 002 [i.6] can be used to measure the data.

3) E2E and/or domain management services use the data acquired in Step 2) to train the ML model. After the

training is completed, the deployed AI model performance evaluation service and deployed AI model

assessment service specified in ETSI GS ZSM 002 [i.6] are used to evaluate the ML model to see if they meet

the requirements given in Step 1).

4) Upon completing the training after acknowledging the ML model meets the requirements, the ML model is

Verification using NDT in the CI-CD process can be carried out by the following procedure:

input or trigger of the intent, the result (e.g. success or failed) will be the output and then use cases may be

used as input of NDT to verify if the software can fulfil the expectation.

3) Management services may return verification results to ZSM framework consumers (e.g. Operators).

ETSI GS ZSM 012 [i.13], clause A.3 describes the scenarios and needs for AI/ML model validation during pre-

deployment / post-deployment and model reality monitoring. ETSI GS ZSM 012 [i.13], clause 4.2 describes the

diversity in the development, deployment environments and various types of trainings. ETSI GS ZSM 012 [i.13],

For the MnS consumer (e.g. operator) to validate the ML Entity's performance, it may be necessary to apply the

decisions of the ML Entity in a sandbox environment. The sandbox environment may be the twin of the relevant parts

NDT in the ZSM framework may provide sandbox or emulations service. As such, the ML inference emulator use case

modifications, to achieve the required emulation. Description of possible extension or modifications would be part of

1) For the NDT as MnS producer to provide information about the ML inference-impact emulator, its features

execution or the available execution resources. Such information can be used by authorized MnS consumer to

required,

2) For an authorized MnS consumer to request an ML Inference-impact Emulator to execute ML inference-

resource management and orchestration service MnS:

• When a new NDT- MnS is requested, the NDT MnS producer will decide if a new instance of the service is

needed:

- if no similar services are running;

• When a new NDT MnS is requested, there may be similar services running and if the NDT MnS has the

information from the NDT MnS capabilities partially such that no conflicts and adversarial impacts may occur or be

These two instances share the same environment, yet they have their own RAN digital component.

In addition, resource sharing makes management of syncs of the NDT to the physical network twin easier. The resource

inefficient allocation of resources, negative impact over the mobile network operations (load generated to create and

Below are potential capabilities related to NDT resource management and orchestration service:

1) Determine whether a new NDT MnS instance is needed or existing instance could be used by utilizing the

2) Ensuring the needed isolation required for simultaneous existence of several service requests by any of the

time may be future time or past time (e.g. playback use case described in clause 5.8), whether the simulation needs to be

between these. For example, if an NDT is used to simulate the impact of configuration changes for network slicing

proposed by network automation functions, the NDT simulation may be initiated to a specified network state at a

specified time. It may also be required to change the simulation related time configuration, for example to simulate a

future point in time. The simulation may require several simulation elements, like NDT simulation models for different

• The NDT virtual clock at the network-level NDT in the example above may play the role of NDT master

discover the NDT MnS capabilities.

sources (network data, environment data, analytics, UEs data, etc. described in clause 4.1) and suitable

or configurations to the NDT MnS producer tailored to fulfil consumer specific needs i.e. to define the consumer

feasibility to fulfil the consumer preferences the NDT MnS producer may either acknowledge the request or

provide recommendations on potential consumer preference that could be fulfilled.

5) The NDT MnS producer once the customer preference is fulfilled would report about the fulfilment to the

based, for example, on detected anomaly events and their signature. Anomalies are, by definition, rare, so building a

patterns of different faults. Injection of faults is not possible in operational networks as it may hinder normal operation

scenarios are created. Fault exploration may include, for example:

• NDT consumer explicitly configure the NDT with fault scenarios to simulate the faults in the NDT.

• NDT consumer configure the NDT with a policy for generating fault scenarios to simulate the faults in the

NDT. This may include, for example, pre-designed scenarios as well as heuristic exploration.

• NDT consumer may provide the NDT a pre-determined fault signature for the NDT to explore potential fault