ETSI GS F5G 006 V1.1.1 (2022-09)

Fifth Generation Fixed Network (F5G); End-to-End Management and Control; Release #1

DGS/F5G-006_E2E_MGMT

General Information

• Status: Not Published
• Technical Committee: F5G - Fifth Generation Fixed Network
• Current Stage: 12 - Completion
• Due Date: 10-Oct-2022
• Completion Date: 26-Sep-2022

Standards Content (Sample)

GROUP SPECIFICATION
Fifth Generation Fixed Network (F5G);
End-to-End Management and Control;
Release #1
Disclaimer
The present document has been produced and approved by the Fifth Generation Fixed Network (F5G) 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 GS F5G 006 V1.1.1 (2022-09)

Reference
DGS/F5G-006_E2E_MGMT
Keywords
F5G, 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
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 2022.
All rights reserved.
ETSI
3 ETSI GS F5G 006 V1.1.1 (2022-09)
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 Requirements for E2E management and control of F5G networks . 9
4.1 Motivation . 9
4.2 General requirements and management aspects . 9
5 Architecture of E2E management and control of F5G network . 10
5.1 Design principles . 10
5.2 Hierarchy architecture overview . 11
5.2.1 F5G E2E management and control architecture . 11
5.2.2 Relationship with ZSM architecture . 12
5.3 Service Management Processes . 12
5.3.1 Overview . 12
5.3.2 F5G service fulfilment . 13
5.3.2.1 Overview . 13
5.3.2.2 Service instantiation: . 13
5.3.2.3 Service activation . 13
5.3.2.4 Service Modification . 14
5.3.2.5 Service Deactivation . 14
5.3.2.6 Service Decommissioning . 14
5.3.3 F5G service assurance . 14
5.3.3.1 Overview . 14
5.3.3.2 Performance management . 15
5.3.3.3 Fault management . 15
6 Domain Controllers and E2E orchestrator . 15
6.1 Customer Premises Network Controller . 15
6.2 Access Network Controller . 15
6.2.1 Overview of PON Access Network Controller . 15
6.2.2 ODN management . 17
6.2.3 Access Network slice management . 17
6.2.4 Fault monitoring and troubleshooting . 18
6.3 Aggregation Network Controller . 19
6.3.1 Overview of Aggregation Network Controller . 19
6.3.2 Optical Transport Controller . 20
6.3.2.1 Overview of Optical Transport Controller . 20
6.3.2.2 Multi-domain OTN AggN . 21
6.3.2.3 Relationship with ACTN . 22
6.3.2.4 Management and control of the OTN Underlay Plane . 23
6.3.2.5 Management and control of Service Plane . 25
6.3.3 IP/Ethernet Controller . 27
6.4 E2E Orchestrator . 27
6.4.1 Overview of the E2E Orchestrator . 27
6.4.2 Network service management . 28
6.4.3 Network resource management . 28
6.4.4 General management . 29
ETSI
4 ETSI GS F5G 006 V1.1.1 (2022-09)
7 Interface requirements and parameters . 29
7.1 Interface overview . 29
7.1.1 Overview . 29
7.1.2 Intent-driven NBIs . 29
7.2 NBI of the Customer Premises Network Controller . 30
7.3 NBI of the Access Network Controller . 30
7.3.1 Interface for Access Network topology and inventory report . 30
7.3.1.1 Functional requirements . 30
7.3.1.2 Key parameters . 31
7.3.2 Interface for service fulfilment in the Access Network . 34
7.3.2.1 Functional requirements . 34
7.3.2.2 Key parameters . 35
7.3.3 Interface for fault monitoring and troubleshooting in the Access Network . 35
7.3.3.1 Functional requirements . 35
7.3.3.2 Key parameters . 36
7.4 NBI of Aggregation Network Controller . 37
7.4.1 NBI of Optical Transport Controller . 37
7.4.1.1 General description . 37
7.4.1.2 Interface for OTN topology report . 37
7.4.1.2.1 Functional requirements . 37
7.4.1.2.2 Key parameters . 38
7.4.1.3 Interface for service provisioning in the OTN domain . 39
7.4.1.3.1 Different ways for OTN domain service provisioning . 39
7.4.1.3.2 Functional requirements for the request of OTN connection provisioning . 40
7.4.1.3.3 Key parameters for the request of OTN connection provisioning . 40
7.4.1.3.4 Functional requirements for the request of service traffic in the OTN domain . 41
7.4.1.3.5 Key parameters for the request of OTN domain service traffic transmission . 42
7.4.1.4 Interface for the OTN connection calculation and evaluation . 42
7.4.1.4.1 The functional requirements . 42
7.4.1.4.2 Key parameters . 43
7.4.1.5 The Interface for OTN service performance monitoring . 44
7.4.1.5.1 The Functional requirements . 44
7.4.1.5.2 Key parameters . 45
7.4.2 NBI of IP/Ethernet Controller . 45
7.5 NBI of Core Network Controller . 45
7.6 NBI of E2E Orchestrator . 45
8 Security consideration . 45
History . 46

ETSI
5 ETSI GS F5G 006 V1.1.1 (2022-09)
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 Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Fifth Generation Fixed
Network (F5G).
Modal verbs terminology
In the present document "shall", "shall not", "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 GS F5G 006 V1.1.1 (2022-09)
1 Scope
The present document focuses on the management and control aspects of the F5G End-to-End network architecture
ETSI GS F5G 004 [1]. The present document specifies the End-to-End management and control architecture and its
related interfaces, including:
• The technical requirements and functional blocks of the domain controllers and the E2E orchestrator in the
F5G networks (Customer Premises Network (CPN), Access Network and Aggregation Network);
• The technical requirements and interface parameters of the northbound interfaces of the domain controllers of
the Customer Premises Network (CPN), the Access Network, the Aggregation Network, the Core Network,
and the E2E orchestrator.
NOTE: The technical requirements and functional blocks of the Core Network Controller is out of scope of the
present document. However, it is part of the management architecture and interface.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] ETSI GS F5G 004 (V1.1.1): "Fifth Generation Fixed Network (F5G); F5G Network Architecture".
[2] IETF RFC 8795: "YANG Data Model for Traffic Engineering (TE) Topologies".
[3] ETSI GS ZSM 002 (V1.1.1): "Zero-touch network and Service Management (ZSM); Reference
Architecture".
[4] IETF RFC 8453: "Framework for Abstraction and Control of TE Networks (ACTN)".
[5] IETF RFC 8346: "A YANG Data Model for Layer 3 Topologies".
[6] IETF RFC 8944: "A YANG Data Model for Layer 2 Network Topologies".
[7] IETF RFC 8299: "YANG Data Model for L3VPN Service Delivery".
[8] IETF RFC 8466: "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service
Delivery".
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.
ETSI
7 ETSI GS F5G 006 V1.1.1 (2022-09)
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] TM Forum IG1230 (V1.1.0): "Autonomous Networks Technical Architecture".
[i.2] TM Forum IG1218 (V2.1.0): "Autonomous Networks - Business requirements & architecture".
[i.3] TM Forum IG1251 (V1.0.0): "Autonomous Networks - Reference Architecture".
[i.4] ETSI GR F5G 008 (V1.1.1): "Fifth Generation Fixed Network (F5G); F5G Use Cases Release #2".
[i.5] IETF RFC 7926: "Problem Statement and Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks".
[i.6] ETSI GR F5G 010 (V1.1.1): "Fifth Generation Fixed Network (F5G); Security; Threat
Vulnerability Risk Analysis and countermeasure recommendations for F5G".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS F5G 004 [1] and the following apply:
alarm propagation relationship: logical association of a set of correlated alarms
NOTE: The logical association of a set of correlated alarms includes but not limit to derivative association, causal
association and time association.
autonomous domains: basic logical business entities to expose network resources/functionalities as
services/capabilities in support E2E lifecycle of automated intelligent network/ICT services
NOTE: The definition of this term comes from TM Forum IG1218 [i.2].
autonomous network: system of networks and software platforms that are capable of sensing its environment and
adapting its behaviour accordingly with little or no human input
NOTE: The definition of this term comes from TM Forum IG1230 [i.1].
domain: logical collection of network nodes and interconnecting links, including their management and control system.
A domain may be further divided into multiple sub-domains
NOTE: In F5G, a domain is a network segment with its domain controller.
event source: the network components where the root alarm event is generated
NOTE: The network components could be a network element or a port.
incident: set of correlated events
intent: formal specification of the expectations, including requirements, goals, and constraints, given to a technical
system
NOTE: The definition of this term comes from TM Forum IG1230 [i.1].
network segment: logical collection of network nodes and interconnecting links, grouped based on network
technologies or for administration purposes
NOTE: In F5G networks, there are four types of network segments: the Customer Premises Network (CPN),
Access Network (AN), Aggregation Network (AggN) and the Core Network (CN).
root alarm event: primary event of the original alarm event(s) that is triggered by the root cause of an incident
root cause: original cause or the critical factor(s) which leads to an incident
ETSI
8 ETSI GS F5G 006 V1.1.1 (2022-09)
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
10G-EPON 10 Gbit/s Ethernet Passive Optical Network
ACTN Abstraction and Control of TE Networks
AggN Aggregation Network
AI Artificial Intelligence
AN Access Network
API Application Programming Interface
BOM Bill Of Materials
CMI CNC-MDSC Interface
CN Core Network
CPE Customer Premise Equipment
CPN Customer Premises Network
CSN Commit Sequence Number
DC Data Centre
E2E End-to-End
E-O-CPE Enterprise-OTN-Customer Premise Equipment
EPON Ethernet Passive Optical Network
FTTR Fibre To The Room
GEM GPON encapsulation mode
GOSNR Generalized Optical Signal-to-Noise Ratio
GPON Gigabit Passive Optical Network
GRE Guaranteed Reliable Experience
HGU Home Gateway Unit
HSI High Speed Internet
ID Identifier
IETF Internet Engineering Task Force
IP Internet Protocol
IPTV Internet Protocol Television
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ISG Industry Specification Group
LTP Link Termination Point
NOTE: See section 3.5 of IETF RFC 8795 [2] for the definition of LTP.
MAC Media Access Control
MCA Management, Control & Analytics
MDSC Multi-Domain Service Coordinator
MDU Multi-Dwelling Unit
MP2MP Multi-Point to Multi-Point
MPI MDSC-PNC Interface
MTU Maximum Transmission Unit
NBI Northbound Interface
ODN Optical Distribution Network
ODU Optical Data Unit
OLT Optical Line Terminal
OMCI ONU Management and Control Interface
ONU Optical Network Unit
OSNR Optical Signal-to-Noise Ratio
OTN Optical Transport Network
OTU Optical Transport Unit
PNC Provisioning Network Controller
POL Passive Optical LAN
PON Passive Optical Network
ETSI
9 ETSI GS F5G 006 V1.1.1 (2022-09)
QoS Quality of Service
RFC Requests for Comments
SAP Service Access Point
SFU Single Family Unit
SLA Service Level Agreement
SME Small and Medium Enterprises
SMP Service Mapping Point
SPP Service Processing Point
TE Traffic Engineering
TM Telecommunication Management Forum
TPN Tributary Port Number
TTP Tunnel Termination Point
NOTE: See section 3.6 of IETF RFC 8795 [2] for the definition of TTP.
UUID Universally Unique Identifier
VLAN Virtual Local Area Network
VOD Video On Demand
VoIP Voice over Internet Protocol
VPN Virtual Private Network
VR Virtual Reality
VxLAN Virtual extensible Local Area Network
WTR Wait-To-Restore
XC Cross-Connect
XG-PON 10-Gigabit-capable Passive Optical Network
XGS-PON 10-Gigabit-capable Symmetric Passive Optical Network
YANG Yet Another Next Generation data modelling language
ZSM Zero-touch network and Service Management
4 Requirements for E2E management and control of
F5G networks
4.1 Motivation
Guaranteed Reliable Experience (GRE) is one of the key dimensions of a F5G network, which enables the business
demand of highly sensitive services, high reliability and high availability communication, and high operational
efficiency.
To meet the requirements of GRE, the Management, Control & Analytics (MCA) Plane is introduced in the F5G
architecture, which is responsible for the management, control and analytics of the E2E F5G networks covering the
CPN, AN, AggN and CN.
The present document defines the F5G E2E management and control architecture as a subset of the overall F5G MCA
Plane as defined in ETSI GS F5G 004 [1].
4.2 General requirements and management aspects
In the following a general set of management aspects of the F5G E2E management and control system are described.
• E2E service provisioning:
The F5G network supports a rich set of applications and services traversing multiple network segments. The
F5G E2E management and control system shall support the instantiation, configuration and maintenance of
these F5G E2E services, including their creation, modification and termination, and supporting the automation
of the corresponding workflows.
ETSI
10 ETSI GS F5G 006 V1.1.1 (2022-09)
• Efficient network operation:
The F5G network improves the efficiency of the network operation by an intelligent E2E management and
control system. The key requirements of this intelligent E2E management and control system include:
- Network resource visibility: The F5G E2E management and control system shall support the necessary
functionality to provide the F5G network resource information to the network administrators. This
improves the efficiency for the network operators to operate and manage their networks. Additionally,
the system should support the visualization of the information at a high-level of abstraction for
administrators to see important system aspects.
- Intelligent fault management: The F5G E2E management and control system shall support intelligent
root cause analysis and alarm correlation analysis, which provides effective guidance to the network
operators for accurate troubleshooting. The management and control E2E management and control
system shall also support proactive fault management to identify and eliminate potential risks in advance.
• Interoperability:
In the F5G network, different network segments may be from different vendors. The F5G E2E management
and control system shall support the collaboration and orchestration of the domain controllers for different
network segments. This is achieved through open interfaces between the E2E orchestrator and each domain
controller.
5 Architecture of E2E management and control of F5G
network
5.1 Design principles
TM Forum IG1251 [i.3] defines the methodology, general principles, and the high-level business and technical
architecture of Autonomous Networks. The present document specifies he E2E management and control architecture as
an "Autonomous F5G Network", which enables the self-configuration, self-healing, self-optimizing and self-evolving of
F5G resources and services with less human intervention.
The design principles for this management and control architecture include:
• Autonomous domain:
Each of the F5G domains, the CPN, the AN and the AggN (together with the management and control system
of that domain) are considered an autonomous domain. This enables the support of F5G E2E services.
• Intent-driven:
Intent defines what is expected to be achieved but leaves the details of how the network is deployed and
operated to the autonomous domain. In the F5G E2E management and control system, the interfaces exposing
to the E2E Orchestrator the resources/functionalities of each autonomous domain shall be designed in an
"intent" style. In this way, each F5G autonomous domain could be treated as a whole, and the E2E
management and control system does not need to be aware of the detailed information of each domain.
The F5G E2E management and control system shall focus on the interaction and orchestration of different
autonomous domains through their intent-driven interfaces.
• Closed-loop control:
Based on the autonomous domain and intent-driven interfaces, it is possible to design the resource and service
control closed-loops in the F5G E2E management and control system. The service control closed-loop enables
the full lifecycle service operation, while the resource control closed-loop enables the full lifecycle cross-
domain and cross-layer resource orchestration.
ETSI
11 ETSI GS F5G 006 V1.1.1 (2022-09)
• Simplicity:
The concept of "simplicity" is a fundamental principle of network design. For management and control
aspects, it means fewer layers, interfaces, and protocols. Intelligent and automatic mechanisms enable
simplicity. In the F5G network, the E2E management and control system shall be designed hierarchically and
includes intelligent components to simplify the architecture.
5.2 Hierarchy architecture overview
5.2.1 F5G E2E management and control architecture
ETSI GS ZSM 002 [3] defines the End-to-End network and service management framework for multi-domain, multi-
technology and multi-layer networks with hierarchical service management domains. The management and control of
F5G networks is an instance of the ZSM architecture applied to optical communication networks.

Figure 1: F5G E2E management and control architecture
Figure 1 shows the F5G E2E management and control system architecture, which adds hierarchical controllers and an
orchestrator to the F5G network topology defined in ETSI GS F5G 004 [1]. Note that all the controllers and the
orchestrator in this architecture are logical functional blocks, which are not necessarily physical controllers in the
network.
A domain controller is introduced for each F5G network segment:
• Customer Premises Network Controller (CPN Controller): Used to manage and control the CPN. The CPN
Controller could be deployed within the CPN or in a remote location. In the remote deployment case, the
management and control of the CPN is the responsibility of the network operator.
• Access Network Controller (AN Controller): Used to manage and control the Access Network, including
OLTs, ODNs and associated ONUs. The AN Controller function includes management and control of the
Underlay Plane (PON network) and the SAP, SPP and SMP in the Service Plane of the Access Network.
• Aggregation Network Controller (AggN Controller): In F5G, both IP/Ethernet network and OTN are possible
options for the Aggregation Network, and both types of Aggregation Networks can co-exist. The AggN
Controller is used to control different types of Aggregation Networks, and provides the resource and services
orchestration function for both IP/Ethernet and OTN.
ETSI
12 ETSI GS F5G 006 V1.1.1 (2022-09)
• Core Network Controller (CN Controller): The CN Controller controls the Core Network and may or may not
control the Cloud/Local Data Centre. The CN Controller is outside the scope of the present document, but the
interface I_cn on the northbound interface of the CN Controller is still in the scope, which is needed for E2E
service provisioning.
The E2E Orchestrator interacts with each domain controller through the I_cp, I_an, I_ag and I_cn interfaces and
performs the resource and service orchestration functions as follows:
• E2E resource orchestration function: this function mainly focuses on the orchestration of the F5G Underlay
Plane. This function includes collecting the (abstracted) topology, resource and status information, triggering
the creation of tunnels in each network segment, resource optimization across multiple network domains,
identification and location of network failures, analysis of status change and prediction of failures.
• E2E service provisioning function: mainly focusing on the management and control of the F5G Service Plane.
The E2E Orchestrator configures the SAP, SPP, and SMP for service access, service processing, and service
mapping into respective tunnels to automatically enable the creation, activation, modification, and deletion of
services. The E2E Orchestrator monitors the performance of the services, and takes necessary actions when
service degradation occurs, according to the SLAs of the services.
5.2.2 Relationship with ZSM architecture
Figure 2 illustrates the mapping relationship between the F5G management and control architecture and the ZSM
architecture defined in ETSI GS ZSM 002 [3].

Figure 2: Relationship between the F5G E2E management and control architecture
and the ZSM architecture
In ZSM architecture (ETSI GS ZSM 002 [3]), each management domain manages one or more entities, such as
infrastructure resources and/or resource-facing services associated with the management domain. The F5G domain
controllers, the CPN Controller, the AN Controller, the AggN Controller and the CN Controller, are equivalent to the
entities of the ZSM Management Domains.
The E2E service management domain is a special management domain that provides End-to-End management of
customer-facing services, composed from the customer-facing or resource-facing services provided by one or more
management domains. The F5G E2E Orchestrator is an equivalent to an instance of the ZSM E2E Service Management
Domain, which manages the F5G E2E services across multiple domains.
The management functions of the F5G E2E Orchestrator and the domain controllers are described in clause 6 of the
present document.
ETSI
13 ETSI GS F5G 006 V1.1.1 (2022-09)
5.3 Service Management Processes
5.3.1 Overview
The ETSI ISG ZSM architecture defines the general processes of cross-domain E2E service lifecycle management
(covering the fulfilment and assurance processes) and describes the interactions between the E2E service management
domain and the underlying management domains during these processes. This clause specifies the processes of service
fulfilment and service assurance in the context of F5G.
Note that the error conditions of the service provisioning processes are not included below and are for further study.
5.3.2 F5G service fulfilment
5.3.2.1 Overview
The fulfilment of F5G services includes the processes of service instantiation, service activation, service modification,
service deactivation and service decommissioning.
5.3.2.2 Service instantiation:
a) The E2E Orchestrator receives the E2E service instantiation request from the customer management system.
b) The E2E Orchestrator determines the performance requirements of the service and the policies to instantiate
the service.
c) The E2E Orchestrator communicates with each domain controller associated with the service instantiation to
perform a feasibility check. The feasibility check evaluates whether the service performance can be satisfied
based on the current state of its domain network.
d) The E2E Orchestrator communicates with each domain controller associated with the service to instantiate the
service instances in their respective domain networks. Depending on the service instantiation policies and the
current network state, one of the following steps may be executed for each domain:
- To create a new service instance in a domain. That domain controller allocates the resource for the
service instance in its domain. The path segment for the service instance of that domain in the Underlay
Plane may be created at this stage or later when activating the service instance.
- To re-use an existing path segment instance in the domain shared by multiple E2E service instances. An
existing path segment instance may be re-configured to increase its capacity for the new service request.
For example, in the OTN AggN domain, an OTN container carries multiple E2E service instances from
different CPNs. In the case of a new service request, an existing OTN container needs to be reconfigured.
e) Each domain controller communicates its updated topology/inventory information to the E2E Orchestrator.
f) The E2E Orchestrator creates a service instance in its database.
NOTE: The action f) may occur in at any stage in the aforementioned sequence.
5.3.2.3 Service activation
a) The E2E Orchestrator receives the service activation request from the customer management system.
b) The E2E Orchestrator communicates with each domain controller associated with the service to activate the
service instance within its domain. The domain controller may activate the path of the service instance within
its domain in the Underlay Plane, if it has not already been activated. The domain controllers at both ends of
the path for this service instance may also configure the admission control in the Service Plane, to allow the
customer's traffic to be adapted and carried by the service instance.
c) Each domain controller communicates its updated topology/inventory information to the E2E Orchestrator.
ETSI
14 ETSI GS F5G 006 V1.1.1 (2022-09)
d) The E2E Orchestrator changes the state of activation of the E2E service instances in its database where the
state of the E2E service instances are maintained, if all related domain controllers succeed in activating the
service instances within its domains.
Note that service instantiation and activation processes may be merged, which means that the service is activated
immediately when it is instantiated.
5.3.2.4 Service Modification
a) The E2E Orchestrator receives the service modification request (e.g. a request to change the Service Level
Agreement (SLA) of the E2E service) from the customer management system.
b) The E2E Orchestrator may communicate with each domain controller associated with the service to perform a
feasibility check. The feasibility check evaluates whether the service modification can be fulfilled based on the
current state of its network domain.
c) The E2E Orchestrator communicates with each domain controller associated with the service to modify the
service instance within its domain. For example, to modify the bandwidth, the route or the recovery scheme of
the service instance.
d) Each domain controller communicates its updated topology/inventory information to the E2E Orchestrator
after modifying its service instance.
e) The E2E Orchestrator updates the service instance in its database.
5.3.2.5 Service Deactivation
a) The E2E Orchestrator receives the service deactivation request from the customer management system.
b) The E2E Orchestrator communicates with each domain controller associated with the service to deactivate the
service instance within its domain. When the domain controllers are deactivating this E2E service, it should
not raise any unnecessary alarms in the E2E Orchestrator.
c) Each domain controller deactivates the service instance in its Service Plane. In the Underlay Plane, if the
service instance's path was shared with other services, the domain controller shall keep it active. Otherwise,
the domain controller may deactivate it in its Underlay Plane at the same time.
d) Each domain controller communicates its updated topology/inventory information to the E2E Orchestrator.
e) The E2E Orchestrator deactivates the E2E service instance in its database, where the state of the E2E service
instances is maintained.
5.3.2.6 Service Decommissioning
a) The E2E O
...