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.

NFV blog evolution new vision imageUndaunted 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.NFV release 4 FEAT 17 blogpost

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:

NFV TST010 blogpost

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.

imageNFVblogSOL14 Medium

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.

labyrinthblogNFV Medium

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.



I’ve been looking over some of my previous entries lately and noticed how many were touching on the subject of interaction between ETSI MEC and other standard and open source bodies. The subject is indeed still one of significant interest and the question about “fragmentation” and “competition” is one that comes up much too frequently.

Those of you who’ve read some of my previous musings on this subject might recall my position on this subject. Standards and open source serve very different functions: standards ensure interoperability between components where it may be necessary and open source provides implementations of such components. As such, the two types of bodies are highly complementary. Moreover, I’ve also maintained that even in the standards space itself little duplication of effort exists around MEC.   Alas, hard evidence to support my view was previously missing – but that is changing fast.



Over the past few decades, many different kinds of electronic voting systems have emerged to assist elections workers and voters in making elections systems easier and faster.  Trusted, paper-based voting system modules for keeping pollbooks, authenticating voters, receiving elections notices and ballots, and casting and counting them have been in many places around the world been augmented with computer-based systems. In a few places, some experiments with network-based balloting have also occurred.

The experiences with these electronic augmentations have also revealed their substantial vulnerabilities and attack vectors that place the integrity of voting systems at risk, and a newfound realization that paper-based systems have enduring value. The ETSI e-Voting cybersecurity work item is intended to develop a framework for understanding and assessing the use of these electronic augments, the associated treats and risks, and provide best-practice guidelines for reducing those risks. A common consensus at the outset is that significant, enduring risks and corruptibility of network based or connected e-Voting exist, and its use should not be encouraged for anything with legal significance. 



The ENI#14 online meeting took place on 22-25 June 2020.

The meeting was very productive and achieved significant progress with 2nd release drafts.

An open area was approved, for all stable drafts and previously published deliverables. The meeting continued drafting within the work items for the next versions on ENI use cases, requirements and Terminology for Release 2.

  • Significant progress was made on the learning techniques and the definition of autonomy for AI in ENI 005 work-item RGS/ENI-0016.
  • The meeting progressed the work-items drafting on the deliverable of Draft GR ENI 008 on Intent Aware Network Autonomicity.
  • Draft GR ENI 009 on Data Processing mechanisms was well progressed in the aspects of data format, data sharing, data management, network telemetry and resource telemetry, etc.
  • Major progress on the evaluation of categories Draft GR ENI 010 was made discussing a five-dimensional system of quantification of the Classes published last year in GR ENI 007.
  • The Draft ES 011 work-item DGS/ENI-0021 on mapping to 3GPP and ONAP was progressed.
  • A new work item (ENI-0022) on In-situ flow information Telemetry (iFIT) Framework was started: Initial draft with skeleton was approved as WI baseline V0.0.1, Key concepts/terminology were approved.

The meeting also approved to send a Liaison Statement to 3GPP S2 & S5 to build a liaison relationship. The LS introduced ETSI Industry Specification Group ENI’s work and asked for further collaboration highlighting ENI 001, ENI 005 and ENI 011.



The 5G Proof of Concept (PoC) Project of ETSI WG TC INT AFI published its White Paper #6 “Generic Framework for Multi-Domain Federated ETSI GANA Knowledge Planes (KPs) for End-to-End Autonomic (Closed-Loop) Security Management & Control for 5G Networks/Services”.

Rationale

The 5G PoC White Paper #6 has now been published, and its purpose is to lay the groundwork for the standardization of “A Generic Framework for Multi-Domain Federated ETSI GANA (Generic Autonomic Network Architecture) Knowledge Planes (KPs) for End-to-End Autonomic (Closed-Loop) Security Management & Control for 5G Networks/Services”.

The White Paper is accessible for download via the INT Wiki.

ETSI TC INT has established that E2E Autonomic (Closed-Loop) Service and Security Assurance shall be achievable through the Federation of GANA Knowledge Planes (KPs) (as Platforms) that implement components for Autonomic Management and Control (AMC) intelligence for specific network segments and domains. While such an E2E Federation of KP Platforms for multiple network segments (as domains) has to be primarily considered within a single network operator administrative domain, the E2E Federation of KPs may be extended to even span multiple network operator or enterprise network administrative domains.



5G PoC White Paper: AI in Test Systems, Testing AI Models and ETSI GANA Model's Cognitive Decision Elements (DEs)

Rationale

The purpose of this 5G Proof of Concept (PoC) White paper #5, is to lay the groundwork of the standardization that has been jointly launched recently in ETSI by TC INT and TC MTS with the support of the Centre of Testing and Interoperability (CTI) on the topic of “Testing of AI and AI in Testing Systems” that will address the various aspects linked to this topic through the development of ETSI assets such as specifications to be used by the industry.

These specifications will include the definition of metrics pertaining to specific classes of AI models that can be targeted for testing and assessment, for such metrics definitions are currently missing in the work being done in the various standardization groups.

Moreover, the specifications will close a gap also identified in the 5G PoC White Paper #5 on the need for a “Test & Certification Framework for AI Models in AMC” (Autonomic Management & Control) to support the Industry in implementing and achieving Multi-Layer AMC for Autonomous Networks being specified by ETSI and other Standards Development Organizations (SDOs) / Fora.

It is noticeable that the framework being proposed by ETSI TC INT is aligned with the European Commission’s White Paper, published on 19 February 2020, on “Artificial Intelligence: a European approach to excellence and trust” that emphasizes the need for:

  1. A Regulatory Framework
  2. The Creation of an AI Testing Center, and
  3. The Creation of a Certification Center

Looking at the topic of “Testing of AI and AI in Test Systems” as a journey, ETSI TC INT has identified, already in 2015, the need for a Test & Certification Framework for Adaptive Networks and their Associated Autonomic Functions using AI Components and published, in 2016, EG 203 341 “Approaches for Testing Adaptive Networks” to anticipate and prepare the Industry’s readiness in implementing Multi-Layer Autonomic (AMC) frameworks for evolving and future networks. 



Due to confinement and travel restrictions, the ENI#13 meeting was successfully organized online only on 17-20 March 2020.

  • 32 were present including 8 operators
  • 4/5 Government Ministry Institutes are members: China, Japan and South Korea
  • 133 documents were handled

A workshop “ENI-Machine Learning in communication networks” was organized on 16 March between two ETSI ISGs, namely ENI and SAI (Securing AI), and ITU-T’s Q20/13 and FG ML5G “Machine Language 5th Generation”, on AI/ML. This workshop was instrumental in enabling synergies between ETSI and the ITU-T in this field and to better understand the needs of industry. ETSI ISG ENI will send the template of ENI Use Cases to the ITU-T groups by liaison for their reference in future work.

As for the meeting, it was very productive and achieved significant progress. After the publication of the approved ENI 006 PoC framework revision, all PoCs will be required to show interworking on an external reference point. The meeting also progressed on the draft reports GR ENI 008 on Intent Aware Network Autonomicity and GR ENI 009 on Data Processing mechanisms. Major progress on the evaluation of categories in Draft GR ENI 010 was made discussing a five dimensional system of quantification of the Classes published last year in GR ENI 007.

Significant progress was made on the learning techniques for AI in the ongoing revision of ENI 005. An open area was also approved for all stable drafts and previously published deliverables. Attendees continued drafting revisions of the next versions on ENI use cases, requirements and Terminology for Release 2.
In addition, we started working on Evaluation of the AI Network Configuration and Mapping of operational systems to ENI architecture. ISG ENI is now progressing into the 2nd Release.



The ETSI NFV community met for its twenty ninth plenary meeting (NFV#29) from 17 to 21 February at the Home of NFV, ETSI Headquarters, in Sophia-Antipolis, France. This time, the plenary meeting took place amidst the unfortunate situation, the Coronavirus outbreak that has hit so many countries and seriously impacted standardization work, and life in general almost worldwide. Consequently, some of our delegates were not able to travel and attend the meeting physically. Our best wishes to all of you all around the world who have been impacted by the outbreak, "wishing you a good and quick recovery".

Addressing the impact of this outbreak on the handling of the plenary meeting, ETSI provided outstanding support, as usual, by enabling remote access for participants that could not travel. Furthermore, the ISG and working group officials made a very good job of adapting the schedule and working procedures to facilitate the active participation and contributions of the remote delegates. As for those of us that had the opportunity to attend the plenary physically, ETSI had provided a very useful new facility: the delegates participating F2F could check-in for the first time by scanning their meeting QR code using a check-in station in the ETSI lobby. check in

All in all, despite the circumstances, the plenary meeting was once again a success. All working groups made steady progress in most of the work items that are currently being developed as part of the Releases 3 and 4.

With regards to Release 4 work, Marcus Brunner (Swisscom), chair of the Network Operators Council (NOC) provided additional input from the network operators at the closing plenary. Some of the discussion points concerned the direction in which the specification of the cloud-native capabilities in NFV is being performed, including containers and Platform-as-a-Service (PaaS). On behalf of the NOC, Marcus also highlighted the importance of deeply embracing more efficient CI/CD and software upgrade mechanisms to cope with the challenges that operators are having for integrating and maintaining current and future NFV deployments. The plenary welcomed the input from the operator community and acknowledged the need for the ETSI NFV to stay focused and address the challenges with diligence.

A couple of weeks after this meeting, ETSI published a brand new animated video explaining the importance of virtualizing network functions in just two minutes.

 

As ETSI NFV has done on previous occasions, there was an evening session. This time the topic was not about ETSI NFV work program matters, or discussions specific to NFV technologies. Instead, colleagues from ETSI CTI introduced the new working methods and tools that ETSI are preparing to make the development of the specifications more agile. A demo enabled the delegates to see the already advanced development status of these tools. Several ETSI NFV delegates provided their feedback, which was also greatly welcomed by the presenters. As a matter of fact, several working groups in the ETSI NFV already make use of agile and software development tools while performing their work. I would say that the ETSI NFV has been a pioneer in ETSI in making use of version control, code development and bug tracking tools.



ETSI TC INT has published ETSI TR 103 626 on 17 February 2020. An Instantiation and Implementation of the Generic Autonomic Network Architecture (GANA) Model onto Heterogeneous Wireless Access Technologies using Cognitive Algorithms.

TR 103 626 for Int blog

This Technical Report provides a mapping of architectural components for Autonomic Network Management & Control developed/implemented in the European Commission (EC) funded WiSHFUL and ORCA Projects to the ETSI TC INT AFI Generic Autonomic Networking Architecture (GANA) model - an architectural reference model for autonomic networking, cognitive networking and self-management.

The mapping pertains to architectural components for autonomic decision-making and associated control-loops in wireless network architectures and their associated management and control architectures.



ETSI hosted ENI#12 meeting and Proof of Concept (PoC) Demos in its headquarters in Sophia Antipolis, France, on 9-12 December 2019. The meeting can be summarized as follows:

  • 34 delegates present F2F out of 41 registered, (Vodafone & NTT participating with email)
  • 7 operators represented, from Asia and Europe
  • 110 documents handled

On 9 & 10 December there were demos of most of the completed and progressing PoCs PoC#1, 2, 3, 4, 5, 6 & 7. This generated discussions and interest with other ETSI members and participants of meetings in the ETSI HQs at the same week. Especially, delegates from Industry Specification Group (ISG) Zero-touch network and Service Management (ZSM) and Technical Committee (TC) SmartM2M.

ENI12blog 1 ENI12blog 2



ETSI ISG NFV was warmly welcomed back to Japan for NFV#28! Five years have passed since the group was in Okinawa in May 2014 for NFV#6.

This time, the ETSI NFV Industry Specification Group (ISG) met from 2 to 6 December 2019 at Across Fukuoka in Fukuoka, Japan. Fukuoka is located on the north of Kyushu, the southernmost of the four major Japanese islands. Fukuoka is well known for its local food, especially, the Hakata-Ramen, which are extremely tasteful and popular. In addition, it was the perfect season to see autumn leaves in Japan.

Group photo with participants of NFV#28 

In the opening plenary, Diego Lopez the ISG chairman, shared his current perspectives on NFV standardization and the industry’s landscape using a Japanese cartoon. I feel the technology trends around the network industry are getting shorter whilst the scope continues to broaden in response to the demands of network technology evolution, the expansion of open source, and new use cases. I think our ETSI NFV community is adjusting towards the right way forward from a standards point of view and cooperating with other SDOs remains important. Release 4 is going at full speed, and as an example, the discussion around container technology and its adaptation for NFV use cases is gaining much more momentum, with an increasing number of work items and related contributions.