ENI#19 meeting has taken place from 6 to 9 September 2021 and has been performed online because many countries were still affected by travel restrictions or delegates were not allowed to travel. In terms of most relevant figures that denote the heavy work carried out during the meeting, it should be taken into account that:
25 ISG members were present, and
96 documents were handled.
Let’s remind that the Industry Specification Group (ISG) is open to ETSI members and non-ETSI members alike. The different players in the value chain are welcome to join the ISG effort, contribute to the development of key specifications and demonstrate Proofs of Concepts (PoCs). To join, please contact: [email protected].
The ETSI ISG was created in February 2017 and today members come from operators, vendors and research institutes all over the world.
Highlights of the meeting
The meeting was productive and progress was achieved in different areas. Deliverable GR ENI 012 on “Reactive In-situ Flow Information Telemetry” was reviewed and declared as stable and it will now proceed to ISG review and approval. It was also decided to re-open the Work Items for the Use cases GS ENI 001 V3.2.1 in release 3 as well as Requirements GS ENI 002 V3.2.1 in Release 3.
GS ENI 005 V2.1.1 on “System Architecture” (Release 2) has completed the Remote Consensus and will be published soon.
The Terminology report GR ENI 004 V2.2.1 is in Remote Consensus until 29 September 2021, after which it is expected to be ratified and published.
An open area where all stable drafts and previously published deliverables are available, was approved.
Approved by ETSI in October 2020, ISG (Industry Specification Group) IPE, as a follow-up of the ETSI ISG IP6, with the prime goal at producing best practices to promote global IPv6 adoption, reference e2e architecture including emerging business scenarios and recommendations to accelerate global IPv6 adoption. Starting with 9 reports, IPE has already published its first report on the IPv6 Gap Analysis involving more than ten stakeholders, pointing out the usability of IPv6 in all scenarios and the need to continue the IPv6 Enhanced innovation addressing the features of ubiquitous connectivity, ultra-high bandwidth, automation, low latency, deterministic quality and security.
Zero-touch network and service automation are essential to unleash the business potential of 5G and beyond. The ultimate automation target is a largely autonomous operation driven by high-level policies and rules, enabling self-configuration, self-monitoring, self-healing and self-optimization – without further human intervention.
Automation is not only about technology; it also requires changes in the mindset of people. Trust is a major barrier to adoption and striving to build it requires a continuous learning process. As more automation processes are deployed and operate safely and efficiently, human trust will increase and the requirement for a level of supervision/intervention will diminish. Having native security (e.g. an adaptive secured framework, access control, trustworthiness, data protection) can help to establish confidence and instill trust as the automated processes deliver the intended business outcomes.
The threat surface in the ZSM environment is extensive, firstly due to the openness of the ZSM framework. The framework is modular, extensible and service-based and expands across multiple domains. Its interfaces are open and offer model-driven services. Protecting the interfaces and the management services within and across the domains is essential to ensure the trustworthiness of the ZSM framework.
In addition, the ZSM services can be produced and consumed by new players coming from diverse industries (e.g. government, vehicle industry, energy, transport, etc.). Each player may require or support different trust levels according to its own deployment/execution environments, security policies and regulations. This variety demands flexible and adaptive security control.
The ETSI ZSM end-to-end network slicing specification has been released.
Network slicing is expected to become a fundamental enabler for value generation: a $300 billion global revenue opportunity by 2025, according to the GSMA. It has been designed to support a broad variety of use cases (including the unknown) with extreme requirements, providing tailored network capabilities for each individual service. But building a network that supports tens of thousands of individual slices – all of which can be created and set up, operated, scaled, assured to meet each slice’s service-level agreement (SLA), and torn down at a moment’s notice – presents several challenges.
The accelerated worldwide deployment of 5G networks poses a significant challenge to the way networks and services are created, orchestrated and managed. Full end-to-end automation becomes crucial for the delivery, dynamic adaptation and continuous assurance of the highly diverse services – each with its own broad range of requirements – while still ensuring economic sustainability. In addition, the network’s performance, coverage and capacity should be constantly assured to satisfy the requirements of the active services.
The ENI#18 meeting was online only as many countries were affected by travel restrictions or delegates not allowed to travel. It took place at 7-10 June 2021.
26 ISG members all of which were present.
Operators: Telefonica, China Telecom, China Mobile, China Unicom, NTT, Deutsche Telekom, and Portugal Telecom.
115 documents were handled.
Let’s remind that the ISG is open to ETSI members and non-ETSI members alike. The different players in the value chain are welcome to join the ISG effort, contribute to the development of these key specifications and demonstrate Proofs of Concepts (PoCs). To join, please contact: [email protected]
The ETSI ENI Industry Specification Group was created in Feb 2017, today members come from operators, vendors and research institutes all over the world.
Last March 2021, I’ve started my new journey in ETSI MEC, taking over the Chair position from my friend Alex Reznik (HPE). Sure, of course I’m not a “beginner” in this group (as most of you who know me can appreciate that I’m there in the MEC Leadership Team since the beginning of the Phase 1!). Nonetheless, given the great work done together in these amazing years in collaboration with all MEC stakeholders, I’m grateful of the trust of many companies who elected me and expressed their warm support in my new role.
A virtual event on NFV Evolution organized by ETSI in partnership with Telecom TV and sponsored by Huawei was held from 19 to 21 April 2021. The objective of the event was for the ETSI NFV Industry Specification Group (ISG) to get feedback from the industry on implementation experience with the ISG’s specifications and on future topics to be addressed in next specification releases. The event was also an opportunity for the participants to get updated on ETSI NFV’s activities, deliverables and future plans, as well as on the progress made in open source communities with regards to the convergence with the ISG’s standards. The event was held in parallel with the 34th meeting of the ISG. The choice was not accidental as this was the meeting where the ISG launched the process for collecting proposals from its members and participants on the features to be addressed within the scope of its next specification release (NFV Release 5).
The event programme featured six original presentations selected from the responses received to an open call, addressing deployment experience, new use cases and technical requirements:
Mr. Yuya Kuno, NTT DOCOMO, presented DOCOMO’s experience in developing and operating NFV and future expansion.
Mr. Pierre Lynch, Keysight Technologies and Ms. Silvia Almagia, ETSI CTI Technical Expert jointly presented “Measuring NFV Evolution: ETSI NFV Plugtests”.
Mr. Borja Nogales, Universidad Carlos III de Madrid, presented “An NFV system to support service provisioning on UAV platforms: a walkthrough on implementation experience and standardization challenges”.
Dr. Lingli Deng, China Mobile, presented “From Orchestration Towards Automation”
Dr. Haopeng Zhu, Huawei Technologies Co., presented “Towards the future of NFV: Edge-native, Containerization, Networking-NFV convergence”.
Mr. Gianpietro Lavado, Whitestack, presented about the advances in deployment of standardized NFV Orchestration through ETSI OSM.
The ENI#17 meeting on 8-11 March 2021 was “online only” due to travel restrictions or delegates not allowed to travel.
26 were present, 29 were registered,
Operators were present from: China Telecom, China Mobile, TIM, Deutsche Telekom, and Portugal Telecom, Also, NTT, Telefonica & Vodafone (messaging the Chair),
121 documents were handled.
The meeting was very productive and achieved significant progress. The meeting progressed the work-items to stable output on the deliverables Draft report ENI 009 on Data Processing mechanisms planned to be approved at the end of March 2021. Report ENI 008 Intent aware architecture is in publication, the Group Report on the evaluation of categories report ENI 010 is published as v1.1.1 describing measures of automation of the Classes published in 2019 in report ENI 007 v1.1.1.
An open area is approved, for all stable drafts and previously published deliverables are available.
Last week I transitioned the position of Chair of ETSI MEC over to Dario Sabella from Intel. Having spent four amazing years serving as the Chair of this group, I am happy to see it in such good hands. For years Dario has been a significant contributor and an enthusiastic advocate of our work. He’s been the driving force behind many of our Hackathons. Moreover, Intel’s support and commitment for the group is a strong signal of our importance. The best days for MEC are in the future and this is where all of us should look. Still, leaving a position such as this, one does tend to reflect on one’s years of tenure and so for my last blog as Chair I am going to do just that.
2020 turned out to be an unexpected year, with the COVID19 pandemic adversely impacting the “normal” day-to-day lives of humans across the globe. However, even during this turn of events and unforeseen testing times, communication networks demonstrated their efficacy in keeping people and businesses connected. More concretely, Network Functions Virtualisation (NFV) proved its feasibility by enabling the operators to gracefully manage high demand for network connectivity.
Undaunted by this situation, the technical experts at the ETSI ISG NFV continued to work tirelessly developing and delivering specifications that help get and keep “everyone/everything connected”. And the hard work paid off as ETSI ISG NFV delivered during the second half of 2020 new and updated "protocols and data model" (stage 3) specifications incorporating NFV Release 3 features.
The experts in the Solutions (SOL) working group completed stage 3 work on a subset of the NFV Release 3 features. One of the first features that was already finalised in 2019 was "Management of NFV-MANO" (FEAT11) with the release of ETSI GS NFV-SOL 009 V3.3.1. This document specifies a set of RESTful protocols and APIs that can be used to manage different aspects regarding configuration, performance, fault and logging of entities implementing specified NFV-MANO functional blocks. The defined APIs leveraged the same RESTful principles used for NFV-MANO APIs in Release 2, i.e., the ones used for managing VNF instances, NS instances and on-boarding VNF Packages, NSDs and other artefacts.
New outcomes on the development of NFV-MANO APIs continued in 2020 with the release of ETSI GS NFV-SOL 011 V3.3.1, which specifies NFV-MANO APIs related to management across "NFV-MANO administrative domains" (FEAT08). These APIs are produced by the NFVO and allow different administrative domains to communicate over the Or-Or reference point to help coordinate the management of NS instances deployed on their respective administrative domains. The Or-Or reference point is set in between NFVO instances placed on different administrative domains, as specified in ETSI GS NFV-IFA 030. For instance, the APIs of ETSI GS NFV-SOL 011 enable reusing an NS instance deployed on a domain A and nest it into another NS instance deployed on a domain B. Due to the functional similarities with existing capabilities offered by the NFVO to other systems such as OSS/BSS, most of the APIs are identical or based on those specified in ETSI GS NFV-SOL 005.
The release of new API specification documents was completed in 2020 by the ETSI GS NFV-SOL 012 V3.4.1 "NFV; Protocol and Data Models; RESTful protocols specification for the Policy Management Interface". As its title hints, the document specifies a new NFV-MANO API based on RESTful principles that can be used for setting up a "Policy management framework" (FEAT07). The API, produced by the NFV-MANO functional blocks, offers the much needed management capabilities by the network operators to be able to transfer, update, delete, activate, de-activate policies, and subscribe to and get notifications related to policy management. Note that the specification of the data models and formats of the policy content is not within the scope of this document. Information and data modelling work on policy content is under development as part of the Release 4.
This year ending, the SARS-CoV-2 virus and its effect, the COVID-19 pandemic, have devastated the planet. Its rapid expansion in the first weeks of 2020 was putting to the test the health systems of as many countries as they were touching, and demonstrating the difficulties - including, in many cases, the ineffectiveness - of the measures adopted to alleviate them. Among such measures, one of the most recurrent has been the identification of those affected (or possibly affected) and their isolation; a measure that relies on what is traditionally known as contact tracking or tracing.
However, contact tracing carried out the traditional, manual way, based on interviews with identified or suspected patients, presents known weaknesses from previous pandemics, such as the lack of memory of the interviewees when remembering who they have recently been in contact with, or the non-availability of the contact information of those strangers with whom there may have been some kind of encounter.
In this challenging context and in the 21st century, “digital”, which today permeates everything, could not fail to be present. Already from the first days of the pandemic, numerous initiatives began to emerge that tried to help tackle it with the help of the most varied technological solutions. In terms of apps alone, the Inter-American Development Bank, in an internal report, a few months ago surveyed more than 600 available applications related to COVID-19. Of these, today there are more than 100 oriented to digital contact tracing, which gives an idea of a true universe of applications.
The ENI#16 meeting on 7-10 December 2020 was "online only" due to travel restrictions or delegates not allowed to travel.
29 delegates were registered and 29 were present
Operators were present from: China Telecom, China Mobile, Deutsche Telekom, NTT, Portugal Telecom, Telefonica and TIM
Government Ministry Institutes being members from Germany, China, Japan and South Korea
163 documents were handled
The meeting was very productive and achieved significant progress. The work-items were progressed to stable output on the deliverables Draft GR ENI 008 on Intent Aware Network Autonomicity and Draft GR ENI 009 on Data Processing mechanisms both planned to be approved at the end of December. Approval as final draft on the evaluation of categories Draft GR ENI 010 describing measures of automation of the Classes published last year in GR ENI 007 v1.1.1.
The ETSI Industry Specification Group (ISG) NFV has published the initial release of ETSI GS NFV-IFA 040 titled "Requirements for service interfaces and object model for OS container management and orchestration specification". This document is the first normative specification delivered for the NFV Release 4 feature on “Cloud-native VNFs and Container Infrastructure management”. The specification propagates the recommendations from the study in ETSI GR NFV-IFA 029 and formally specifies the new functions required for the management and orchestration of OS containers, the Container Infrastructure Service Management (CISM) and the Container Image Registry (CIR). The CISM is responsible for maintaining the containerized workloads while the CIR is responsible for storing and maintaining information of OS container software images.
To enable a consistent and generic system for the management of containerized VNFs, ETSI GS NFV-IFA 040 specifies an abstract NFV object model for OS container management and orchestration, including their relationship to the core information models of NFV-MANO. The abstract NFV objects are also expected to be used in specifications profiling APIs of de-facto standard solutions, to map the abstract NFV objects to objects of the specific de-facto standard solution. One of the introduced abstract NFV objects is the Managed Container Infrastructure Object (MCIO), an object managed and exposed by the CISM, characterized by the desired and actual state of a containerized workload. Managed objects from Kubernetes® such as Deployment or Service are examples which map to an MCIO. Another new NFV object is the Managed Container Infrastructure Object Package (MCIOP), a hierarchical aggregate of information objects including declarative descriptors and configuration files for one or multiple MCIOs. Helm charts as specified by CNCF® are an example which maps to an MCIOP.
Furthermore, ETSI GS NFV-IFA 040 specifies requirements on the list of services to be offered by architectural elements providing the CISM and CIR functions and on the interfaces for exposing these services to NFV-MANO and other consuming entities. The CISM shall provide services for the management of OS container workloads as well as for the management of OS container compute, storage, network resources and their configuration. The CIR shall provide a service for the management of OS container images. This document intentionally does not specify interface operations or information models but only requirements on the management service interfaces. This approach leaves further details to the specification of protocols and data models in the form of profiling de-facto standard open source solutions.
ETSI GS NFV-TST 010 (TST010) is a published API conformance testing specification for NFV Management and Orchestration (NFV-MANO) APIs. Specifically, it contains conformance tests for the APIs used on the following reference points:
Os-Ma-Nfvo, defined by ETSI GS NFV-SOL 005 (SOL005)
Ve-Vnfm, defined by ETSI GS NFV-SOL 002 (SOL002)
Or-Vnfm, defined by ETSI GS NFV-SOL 003 (SOL003)
The figure below shows the reference points supported by TST010:
The latest released version of TST010 is Version 2.6.1 (available from the ETSI website), which means that it supports the corresponding 2.6.1 versions of the above SOL documents (i.e. SOL02, SOL003 and SOL005). Version 2.4.1 is also available, and it similarly corresponds to the 2.4.1 versions of the SOL documents. This will always be the case going forward as well: the TST010 version will always match the corresponding version of the SOL documents specifying the reference points being tested.
The ENI#15 meeting took place from 14-17 September 2020 "online only" as many countries were affected by travel restrictions or delegates not allowed to travel.
30 were present, 33 were registered
Operators included: Telefonica, TIM, China Telecom, China Unicom, China Mobile, Deutsche Telekom, NTT and Portugal Telecom
Government Ministry Institutes members came from Germany, China, Japan and South Korea
134 documents were handled
The meeting was very productive and achieved significant progress. It progressed the work-items drafting on the deliverables "draft GR ENI 008" on Intent Aware Network Autonomicity and "draft GR ENI 009" on Data Processing mechanisms, both planned to be approved in December. Major progress on the evaluation of categories "draft GR ENI 010" was made discussing measures of automation of the classes published last year in GR ENI 007 V1.1.1. The new draft ENI 022 on iFIT in-situ reactive telemetry framework was progressed well.
The ETSI NFV Industry Specification Group (ISG) has completed the initial release of ETSI GS NFV-SOL 014 titled "YAML data model specification for descriptor-based virtualised resource management". The specification focuses on a set of YAML-based data models used between NFVO and VIM (Or-Vi reference point), and also between VNFM and VIM (Vi-Vnfm reference point) for exchanging information on virtualised resources and their management. The work item and resulting document addresses specification gaps in the area of virtualised resource management and aim at enhancing the integration and interoperability of VNFM and NFVO with VIM solutions.
In the ETSI NFV specifications, interfaces and information models for the Or-Vi and Vi-Vnfm reference points have been specified in ETSI GS NFV-IFA 005 and ETSI GS NFV-IFA 006 respectively. Based on those specifications, the objective of ETSI GS NFV-SOL 014 is to define a set of YAML-based data models for representing information exchanged over these reference points as input and outputs to perform virtualised resource management. The descriptor-based virtualised resource management assumes a type of VIM which supports templates declaring parameters, requirements, lifecycle and composition of sets of virtualised resources.
Following intense technical work, ETSI NFV has just released ETSI GS NFV-SOL 016, the first stage 3 specification of NFV-MANO procedures in NFV Release 2 addressing interactions across several NFV-MANO functional blocks and/or interfaces. This specification builds on the ETSI NFV-MANO API specifications ETSI GS NFV-SOL 005, ETSI GS NFV-SOL 003 and ETSI GS NFV-SOL 002 which have defined the mandatory and optional operations and data attributes per individual NFV-MANO interface. As these specifications are focusing on individual interfaces, it is left up to the operator or the integrator to stitch together the information across different NFV-MANO interfaces to realize the NFV-MANO procedures involving interactions across several NFV-MANO functional blocks and/or interfaces, also referred to as end-to-end procedures. This might lead to various interpretations of how the end-to-end NFV-MANO procedures should work. ETSI GS NFV-SOL 016 defines procedures for selected key NFV-MANO procedures with the target to improve interoperability end-to-end.
The first released version of ETSI GS NFV-SOL 016 addresses five selected key NFV-MANO procedures, namely on-boarding of a VNF package, instantiation of a network service, termination of a network service instance, scaling of VNF instances in a network service instance and changing the external connectivity of VNF instances in a network service instance.
You are leaving the ETSI website and will be directed to the ETSI Member Portal.