ETSI Blog

What happened at the NFV Evolution virtual event?

2021-05-12 Posted by Bruno Chatras, ETSI NFV Chair 3109 Hits

NFV blog052021

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.

ENI#17: Winding up Release 2, scoping release 3

2021-03-19 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 4326 Hits

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.

4 amazing years as MEC Chair

2021-03-03 Posted by Alex Reznik, Former Chair of MEC ISG 1518 Hits

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. 

ETSI NFV Release 3: update on protocols and data model specification outcomes

2021-01-21 Posted by Joan Triay, ETSI NFV Technical Manager and Zarrar Yousaf, ETSI NFV SOL working group Chair 6741 Hits

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.

2020: The year a universe of [COVID-19] apps emerged

2020-12-21 Posted by Miguel GARCIA-MENENDEZ, Vice-Chair, ETSI ISG E4P / CPO, Alastria 4186 Hits

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.

ENI#16 - Significant progress with approval of much of Release 2

2020-12-18 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 5374 Hits

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.

OS container object model and management interfaces: The first set of Cloud-Native VNF orchestration specifications

2020-11-10 Posted by Jörg Aelken, Rapporteur of ETSI GS NFV-IFA 040 9048 Hits

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.

Insights on API conformance testing for NFV-MANO

2020-11-03 Posted by Pierre Lynch, NFV TST WG Chair and Rapporteur of TST010 7185 Hits

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.

ENI is progressing with 15th meeting & Technology Workshop on AI policy

2020-10-14 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 5764 Hits

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.

New release: Data models for resource templates to foster interoperability between VIMs and NFVOs/VNFMs

2020-08-19 Posted by Hiroshi Dempo, ETSI GS NFV-SOL 014 rapporteur, NEC 6984 Hits

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.

End-To-End Management and Orchestration procedures: The ultimate step towards interoperability (Publication of SOL016 – MANO Stage 3 procedures)

2020-08-19 Posted by Rajavarma Bhyrraju, WG IFA Vice Chair 11205 Hits

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.

Convergence in the MEC ecosystem

2020-08-19 Posted by Alex Reznik, Chair of MEC ISG 6744 Hits

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.

Mitigating the Cybersecurity Threats Which e-Voting Faces

2020-07-10 Posted by Tony Rutkowski, e-Voting Cybersecurity Group Technical Lead, ETSI 4949 Hits

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. 

New work on Reactive In-situ flow information Telemetry

2020-07-06 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 5696 Hits

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.

TC INT working group INT AFI published White Paper in frame of 5G PoC Project

2020-06-16 Posted by Dr. Tayeb Ben Meriem (Orange), Dr. Muslim Elkotob (Vodafone) 5284 Hits

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.

TC INT and TC MTS published White Paper on Testing of AI and AI in Test Systems

2020-04-28 Posted by Tayeb Ben Meriem (TC INT), Andreas Ulrich (TC MTS) 5213 Hits

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. 

ENI#13 Progressing Release 2 and ETSI / ITU-T workshop “ENI-Machine Learning in communication networks”

2020-03-31 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 6337 Hits

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.

Steady progress on Release 3 and Release 4 work

2020-03-16 Posted by Joan Triay (ISG NFV Technical Manager, DOCOMO Euro-Labs) 7651 Hits

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 TR 103 626 published - an instantiation & implemention of GANA Model

2020-03-04 Posted by Dr. Tayeb Ben Meriem, ETSI TC INT Vice Chair 5678 Hits

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.

ENI#12 with Proof of Concept Demos, interesting discussions and 110 documents handled

2020-01-20 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 7322 Hits

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

NFV#28 full of surprises in Japan

2019-12-19 Posted by Yoshihiro Nakajima, ISG NFV Vice-Chair (NTT Docomo) 7849 Hits

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 chair, 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.

ETSI TC INT has launched a new standardization request on “AI in Test Systems and Testing AI Models”

2019-12-05 Posted by Dr. Tayeb Ben Meriem, ETSI TC INT Vice Chair 5882 Hits

Rationale

Technical Committee (TC) INT Working Group (WG) AFI delivered:

  • TS 103 195-2 - “Autonomic Network Engineering for the Self-Managing Future Internet (AFI); Generic Autonomic Network Architecture (GANA)”
  • TS 103 194 - ”Scenarios, Use Cases and Requirements for Autonomic /Self-Managing Future Internet”
  • ETSI White Paper No.16 on “ETSI GANA Model and GANA Implementation Guide”, complemented by
  • ETSI 5G PoC White Paper No.4

AFI WG is also running a series of 5G PoC Demos aiming at operationalizing this “GANA Multi-layer AI Framework for AMC” (Autonomic Management & Control):

AFI WG is driving a PoC Program on other various topics pertaining to the introduction of Autonomics in various network architectures and their associated management and control architectures.

Artificial Intelligence Models for evolving and future networks

2019-12-03 Posted by Dr. Tayeb Ben Meriem, ETSI TC INT Vice Chair 5438 Hits

The 7th UCAAT (User Conference on Advanced Automated Testing) was held at Bordeaux on 22-24 October 2019.

ETSI Technical Committee INT presented the pdfcurrent work on Artificial Intelligence (AI) in Test Systems and Testing AI Models for Autonomic (Closed-Loop) Network Automation.

Artificial Intelligence Models (AI Models) are enablers for advanced intelligence in the Management and Control operations now strongly required for the evolving and future networks such as 5G Networks. AI algorithms bring benefits to diverse aspects in development and deployment of AI exhibiting systems such as Autonomic and Cognitive 5G networks and their associated Autonomic Management and Control (AMC) systems. This presentation covers the work launched under the ETSI TC INT AFI WG 5G PoC Program on “AI in Test Systems and Testing AI Models” articulated around the three following topics:

  • The benefits AI brings to Test Systems (e.g. in reduction of Test Suites execution time in Performance Testing complex systems)
  • Testing AI Models for autonomic and cognitive management & control of network resources, parameters and services—using a “Qualified Automated Test Component(s) or System” that exhibit best quality AI capabilities for testing those of AI Component(s)/System Under Test
  • Generic Test Framework for Testing ETSI GANA (Generic Autonomic Network Architecture) Model’s Multi-Layer Autonomics & AI Algorithms for Closed-Loop Network Automation

Working towards moving the industry forward together

2019-11-04 Posted by Alex Reznik, Chair of MEC ISG 6875 Hits

Quite some time has passed since my last blog entry, and while I thought about a new blog a number of times, a good topic – i.e. one which is appropriate for discussion in a short, informal and public format - just did not seem to present itself. That’s not for the lack of interest or activity in MEC. 2019 is shaping up to be a critical year in which many operators are now public about their plans for edge computing, initial deployments are appearing and, as expected, holes in what the industry has been working on are beginning to be found (witness the much publicized and excellent Telefonica presentation at last month’s Edge Compute Congress). It’s just that it’s hard to blog about on-going work, even when it is very active, much less about internal efforts of various players in MEC. After all, what would that look like “this is hard and we are working hard on it…”

Nevertheless, the time has come. Those of you who follow my random MEC thoughts on a semi-regular basis might recall the subject of that last post ages ago (I mean in February): the need for both a vibrant Open Source community and Standards development in a space like MEC; and how the two are complimentary in that the focus is, by definition, on complimentary problems. And, if you don’t follow me religiously, here is the link: https://www.etsi.org/newsroom/blogs/entry/do-we-still-need-standards-in-the-age-of-open-source, grab a coffee, tea, a…. whatever … and read up!

Achievement of major milestone – publication of substantial ZSM specifications

2019-10-17 Posted by Nurit Sprecher, ISG ZSM Vice Chair 6491 Hits

ETSI ZSM group now prepares for the next term of activity.

The ETSI ZSM group was formed with the goal to accelerate the definition of the end-to-end service management architecture, spanning both legacy and virtualized network infrastructure, to enable automatic execution of operational processes and tasks. The pivotal deployment of 5G and network slicing has triggered the need for a radical change in the way networks and services are managed and orchestrated. Full end-to-end automation of network and service management has become an urgent necessity for delivering services with agility and speed and ensuring the economic sustainability of the very diverse set of services offered by Digital Service Providers. The ultimate automation target is to enable largely autonomous networks which will be driven by high-level policies and rules (AKA intent); these networks will be capable of self-configuration, self-monitoring, self-healing and self-optimization without further human intervention. All this requires a new horizontal and vertical end-to-end architecture framework designed for closed-loop automation and optimized for data-driven machine learning and artificial intelligence algorithms.

A major milestone was reached during the summer of 2019 with the publication of GS ZSM 001 (ZSM Requirements), GS ZSM 002 (ZSM Reference Architecture) and GS ZSM 007 (ZSM Terminology).

ZSM blog 2019 GS ZSM 001 ZSM blog 2019 GS ZSM 001 ZSM blog 2019 GS ZSM 001

ENI#11 and a CCSA TC 610/SNAI workshop of network artificial intelligence

2019-10-15 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 6828 Hits

Participant photo

The ENI#11 meeting was hosted by China Telecommunications in the research & development labs in Beijing on 24-26 September 2019.

  • 31 people were registered, emails were received from ISG members not able to be in Beijing, their views were considered
  • Operators were present: TIM, China Telecom, China Mobile, NTT and Portugal Telecom
  • 3 Government Ministry Institutes are members, China, Japan and South Korea
  • 131 documents were handled

Conference hosted by DT: Standardization meets open source to manage programmable networks

2019-10-07 Posted by Klaus Martiny, ISG ZSM Chair (DT) 6704 Hits

The Telco industry is heading towards a very interesting phase. Open source (OS) deployments are looking very promising. On the one hand there is the delivery of more flexible, simpler and agile deployments. On the other hand, the success of the current business is based on high quality solutions based on standards. There is no doubt that the success of the Telco industry will not attain the high current level without standards. ETSI, 3GPP, GSMA, etc. have done a great job.

But it is also clear that the way standards are created is evolving and taking on board the best of the open source community methods. An important discussion is how can both camps learn from each other.

Deutsche Telekom hosted a Conference on this topic at DT Headquarters in Bonn, on 9 and 10 September. The conference took place ahead the ETSI ZSM#8 workshop. The supporting organizations were ETSI, Linux Foundation and Telecom TV. Open Source Networking (OSN) Days of Linux Foundation were also embedded into the conference.

The purpose of the event was to discuss the enhancement of the collaboration and cooperation between SDO and OS. ETSI and LFN are good representatives of both parts of the industry. TM Forum (TMF) was invited as well. 

Flying start for NFV Release 4

2019-10-03 Posted by Bruno Chatras, ETSI NFV ISG Vice-Chair 9930 Hits

For its 27th plenary meeting, the ETSI Industry Specific Group (ISG) on Network Functions Virtualisation (NFV) met at Orange Gardens, the recent Research and Innovation Campus of Orange, located in Châtillon, a small town in the outskirts of Paris, France. The meeting is to be remembered as the one where the contents of NFV Release 4 started to materialize with the approval of 8 work items.

The opening session started with an uplifting presentation from Diego Lopez, the chair of the ISG, highlighting the challenges to be addressed by standardization bodies to cope with the transformation of the telco industry ecosystem and processes. I liked the comment he made to invite delegates to resist the temptation of creating new terms and acronyms (e.g. Cloud-Native Network Functions / CNF vs. Virtualised Network Functions / VNF) to catch-up with buzzwords. After all, whether the software of a VNF is designed according to cloud-native patterns or not, the VNF remains a VNF!

After the opening plenary, the bulk of the work was performed during three intense days where delegates divided in six working groups to process hundreds of contributions.

Group photo of participants at 27th NFV plenary meeting

How to secure consumer IoT devices: and why it matters

2019-08-15 Posted by Alex Leadbeater, ETSI TC CYBER Chair 6541 Hits

More and more consumer products contain wireless network connectivity either providing local short range connectivity to other devices or are directly connected to the internet – raising the risk of hacks or personal data breaches. Smart speakers, connected toys, domestic appliances and smart locks are all potentially vulnerable if not adequately secured by design and during their expected lifespan. As an example the Furby Connect doll with Bluetooth connectivity, enabled anyone within 100 feet to hack its wireless connection and access its microphone. Given that this product was intended for use by children, such a fundamental security flaw was especially unfortunate.

Everyone recognises there’s a problem, but exactly how to solve it isn’t yet well-defined. Governments are still developing legislation to improve security and product labelling, and to protect personal data. However, given the poor security of many current and historic IoT products regulation alone is not going to solve the problem overnight.

This leaves product vendors in a difficult position, with a need for clear direction in consumer IoT security. To fill this gap, ETSI recently announced ETSI TS 103 645, the first worldwide standard for consumer IoT security. This sets a benchmark for how to secure consumer products connected to the internet, and aims to promote best practice.

Approval of AI Functionality in the network - ENI#10 closing Release 1, kicking off Release 2

2019-07-26 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 7259 Hits

The ENI#10 meeting was hosted by Altice Labs / Portugal Telecom on 9-11 July, 2019, at their headquarters by the canals of Aveiro, Portugal.

 Group photo of participants and inset photos of remote participants

The meeting was very productive and significant progress was made. To sum it up, we finalized the work on the ENI use cases, requirements and system architecture for Release 1. As a result, the final drafts for approval of these specifications are now available and their publication is expected to take place in September. In addition, we advanced the work on the means of intent aware networks, categorization of AI within networks, including discussion on semantics around the work in Release 2.

Pushing forward in the ZSM#7 meeting: the ZSM architecture work has reached the finishing line and work has commenced on closed-loop – the key automation enabler

2019-07-11 Posted by Nurit Sprecher, ISG ZSM Vice Chair 7300 Hits

The ZSM#7 meeting was hosted by Intel on 17-21 June, 2019, at their headquarters in the sunny city of Santa Clara, California.

ZSM7 2019

The meeting was highly productive and significant progress was made. In a nutshell, we are now finalizing the work on the ZSM requirements and architecture. The final drafts for approval of these specifications will be available during July 2019 and publication is expected to take place in September. In addition, we advanced the work on the means of automation, end-to-end management and the orchestration of network slicing as well as on the ZSM landscape. We agreed on the skeleton of the end-to-end cross-domain service orchestration and automation specification. Noteworthy is the kickoff of a whole bunch of new work items dedicated to closed-loop automation.

SOL006 – NFV descriptors based on YANG Specification

2019-06-11 Posted by Mahesh Jethanandani, Rapporteur SOL006, VMware Palo Alto 12774 Hits

After a year long effort, ETSI has just released the first specification of a Yet Another Next Generation (YANG) data model for NFV descriptors, ETSI GS NFV-SOL 006. The specification is based on ETSI GS NFV-IFA 011 and ETSI GS NFV-IFA 014, and can be found on the ETSI server, with the corresponding YANG files can be found on the Forge website. The specification covers VNFD, PNFD and NSD. It enables on-boarding of NFV descriptors on YANG-based MANO functions, in a standard way. The flexibility and the ability to define network services, and to do it quickly is the true strength of the specification.

NFV#26 - Kicking off the Release 4

2019-06-03 Posted by Joan Triay (ISG NFV Technical Manager, DOCOMO Euro-Labs) 12144 Hits

The ETSI NFV community met for its twenty sixth plenary meeting (NFV#26) from 20-24 May 2019 at NFV’s home, ETSI Headquarters, in Sophia-Antipolis, France.

Photo of ETSI main building in drone view

Visiting the breezy and sunny Provence and Cote d’Azur in May is always quite an experience. Many of our meeting delegates were greeted this time at Nice Airport, by photographers (and paparazzi). The reason for such a warm welcome might not be due to the Cannes Film Festival taking place the same week, but instead due to “our NFV stars” setting down, yet again, for another productive and successful meeting.

Meeting room with chair people of nfv#26 plenary meeting

While the NFV#25 plenary meeting served as a warm-up for what would come after Release 3, NFV#26 should be forever remembered as the kicking-off of Release 4. Let me elaborate more on this.

Why We Must Act Now to Establish Standards for Quantum Security

2019-04-15 Posted by Andrew Shields, Chair of ETSI Industry Specification Group in Quantum Key Distribution (ISG QKD) 5294 Hits

Quantum computing could soon emerge from research labs to handle practical workloads such as simulating complex processes or performing cryptographic calculations that are beyond the reach of current supercomputers. While this is all very exciting it poses serious issues for the security of many systems. Quantum computers could easily break current state of the art cryptography, so data encrypted today will become an easy target for quantum hackers of the future.

Cheap mass storage enables cyber criminals to harvest vast quantities of encrypted data and simply wait until they have the firepower to expose its secrets. Data protection regulations require organisations to maintain data confidentiality for periods of several years, so this is a serious threat.

NFV#25 – Strong start for the ISG in 2019 (several features ready for Release 3 drop 2)

2019-03-12 Posted by Cristina Badulescu, Ericsson, ETSI ISG NFV Vice-Chair 8731 Hits

Refreshed after the winter break and starting 2019 with renewed energy, the ISG community met for its 25th ISG plenary meeting in the sunny Beijing, hosted by Huawei Technologies.

The meeting was held in the week after the Chinese New Year, which left the cheerful spark of the celebrations over Beijing city.

NFV25

Several elections were held during February and the formal appointments were made at the NFV#25 plenary. Two ISG Vice-chair positions were filled, by the re-election of Cristina Badulescu, Ericsson and Bruno Chatras, Orange for the next term. The new Security WG Chair is Alex Leadbeater, BT, a veteran in the SEC WG and the former SEC WG Vice-chair. Stefan Arntzen, Huawei, current Reliability WG Chair was re-elected and will continue for another term.

Do we still need standards in the age of open source?

2019-02-11 Posted by Alex Reznik, Chair of MEC ISG 8176 Hits

There is a sense in our community that while industry-standard interface definitions are important, these do not have to come from traditional “Standards.” Instead they can come from a development community, e.g. from an open source project.  Moreover, having these come from an open source project is better because the result is not just a document, but running code. Before I dive into this, let me be very clear: open source has had and continues to have tremendous and largely positive impact on our industry and beyond.  It dramatically lowers barriers to entry into the market and in doing so enables small, nimble and highly innovative companies to play on a more equal footing with large established players.  

But let me focus a bit more on whether open source eliminates the need for traditional telco standards, as many believe.  To illustrate the point, I need to pick on a project, so let me pick on OpenStack.  Not because it’s bad… quite the contrary because it is so very good and is quite important to our industry’s transition to NFV.  As anyone who has worked with OpenStack knows, developing to the OpenStack API requires specifying:

  • Which version of OpenStack you are developing to and which APIs you need. 
  • Which OpenStack you are developing to (RedHat, Mirantis etc.)

Yes, they are almost the same – but almost is not quite the same as the same.   And when you are a small company, having 100 edge clouds that present almost the same interfaces still leaves you with the challenge of scaling to integrate with 100 different – slightly, but still different – implementations.   In other words – you are still missing a standard. 

This is not OpenStack’s fault, nor is it the fault of the several companies that harden and commercialize it for the market. The primary goal of OpenStack has been and remains to enable its users to get to market as fast as possible and to concentrate their investments where they believe they can add value to the base.   Interoperability should be a side benefit (and good open source projects like OpenStack do try hard to maintain backward compatibility, etc.), but it is not a primary goal. In an ideal world, open source projects would utilize formally Standardized interfaces in those areas where these are needed – i.e. where large-scale inter-vendor interoperability needs are expected. 

As the development of a Telco edge picks up steam with TIP, Linux Foundation and OpenStack all having launched large scale project focused on the telco edge, ETSI MEC is perfectly positioned to fill that role.  Our service APIs are precisely the APIs that exist at the intersection of the needs of a large number (100’s) of global communication service providers (CSPs) and an even larger number (100 000s) of application developers that need to use services exposed by the CSPs.  In such an environment a lack of standardization can be a significant barrier to the evolution of the market and we remain the only standards development organization focused on this issue. 

Moreover, by serializing these APIs – see https://forge.etsi.org/gitlab/mec - we are enabling software developers (and yes, particularly open source developers) to easily integrate our work in their applications. No more reading standards documents in PDF! Furthermore, to accelerate and encourage the development of new and innovative services in this growing Telco edge ecosystem, we have recently established a working group (DECODE) to focus specifically on issues around enabling the use of these APIs in forums such as open source.

So the conclusion of this post is a call to action – we are here and ready to help you get the Edge done!  Let us know how we can help. 

The ZSM story: the power to transform

2018-12-20 Posted by Nurit Sprecher, ISG ZSM Vice Chair 7776 Hits

As the end of the year is fast approaching, I’m taking this opportunity to look back at the progress of our work during 2018 and review what we accomplished during the year. Our excellent achievements and the momentum we managed to create in the industry certainly evoke both satisfaction and pride. 2018 was without doubt an amazing year!

The ZSM kickoff meeting took place on January 10-12, 2018, with 30 companies signed as ZSM members/participants. In that meeting we appointed our leadership, agreed on our objectives and approved the creation of five work items: ZSM requirements, ZSM architecture, end-to-end management and orchestration of network slicing, ZSM landscape and means of automation.  Since then we have grown to 65 members/participants (List) and have made tremendous progress in our work thanks to our weekly calls and the additional six face-to-face meetings. We benefited from the fact that ZSM experts come from different backgrounds (e.g. Telco, IT, Enterprise) and strove to bring these worlds together, utilizing the best that each can offer.

Together we managed to look at many business-oriented scenarios and the related automation challenges faced by operators and vertical industries, and succeeded in deriving architectural, functional and operational requirements for an automated end-to-end network with service management. We grouped related scenarios and are now in the final phase of consolidating the requirements.

In addition, we worked hard to develop a ZSM architectural framework (see Figure 1 below) which will enable a zero-touch automated network and service management in a multi-vendor environment. We introduced a set of architectural principles and requirements that guided the design of the architecture. The ZSM architecture is service-based, modular, flexible and extensible. It allows for the integration and composition of management services via an integration fabric. The ZSM framework supports the separation of management and automation into different areas of concern, i.e. network management domains and end-to-end cross-domain service management; both are responsible for fulfillment (orchestration and control) and assurance (data collection, analytics and intelligent automation) within their scopes. Decoupling network management domains from end-to-end cross-domain service management prevents monolithic systems, reduces complexity in the entire service and enables domain and end-to-end management to evolve independently. Every management domain implements a set of capabilities which are exposed via a set of interface end-points.

The architecture supports open interfaces as well as model-driven service and resource abstraction. The management services which are exposed by management domains, including the E2E service management domain, are described and specified. The architecture allows operational data to be kept separate from the management applications, enabling efficient access to data and cross-domain data exposure (e.g. topology, telemetry data) which can be leveraged by network and service intelligence capabilities (e.g. data-driven machine learning, artificial intelligence and other technologies for automation). The architecture is designed to enable closed-loop automation (connecting assurance and fulfillment processes) at the network and service-management levels where the automated decision-making mechanisms (e.g. self-optimization, automated service assurance) can be bounded by rules and policies.

ZSM Architectural Framework visually displayed as chart

Legend for ZSM Architectural Framework visually displayed as chart

Figure 1: ZSM Architectural Framework

ENI#8 meeting summary

2018-12-19 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 6804 Hits

ENI#8 was held on 3-5 December in 5Tonic labs in Madrid, hosted by UC3M (University Carlos III of Madrid) and Telefonica: the host gave a presentation of the 5tonic laboratory. Attendees included members and participants of the group including Government Ministry Institutes. It was a fruitful meeting with over 80 documents handled.

This meeting was important to discuss the ISG ENI extension terms of reference for Release 2 going into its second term. The group updated the Terms of Reference accordingly and will ask ETSI’s Director General for an extension from April 2019 to March 2021, based on the growing ongoing and future work of the group.

ENI8 blog 18

Expected and Future work of ETSI ISG ENI

NFV#24 – Another full year ends, a new ISG term starts

2018-12-18 Posted by Cristina Badulescu, Ericsson, ETSI ISG NFV Vice-Chair 8202 Hits

A productive meeting closing a prolific year, the 24th NFV ISG meeting had a fortunate setting in a mildly weathered first week of December on French Riviera.

The NFV#24 meeting was marked by some internal community metamorphosis, such as the approval of the restructuring of the ISG and the election of a new Network Operators Council (NOC) Chair.

Don Clarke (CableLabs), our NFV NOC Chair over the last years, is one of the biggest industry advocates for ETSI NFV work and its network transformation potential to support the service providers. He kept us connected to the operators’ perspective and the practical deployment aspects, and for all this I’ve got good indication that I’m not alone in feeling thankful for all Don’s hard work.

We welcomed Marcus Brunner (Swisscom), the new NOC Chair, as we dived right away into the latest NOC priorities while Marcus walked us through them on behalf of the NOC. The operators consolidated view on current deployment pain points, encouraged the NFV community to preserve focus on multi-vendor orchestration systems, simplifying procedures and APIs, as well as completing specifications to support essential network operations such as VNF migration, updates and upgrades, multi-site connectivity.

One of the week’s highlights was the pre-planned co-location with a rising star, ETSI ISG ZSM (Industry Specification Group Zero touch network and Service Management). The evening joint workshop was moderated by the two ISG Chairs and their respective lady Vice-Chairs. In the very well-attended workshop, the young ISG ZSM introduced the ZSM current architecture as defined in the ZSM 002 specification, and afterwards both ISG representatives presented the results of an early joint analysis on identifying the relationship in between ZSM and NFV, and the next steps in their collaboration.

NFV24 blog

The NFV#24 week rewarded us with good progress in exchange for the long working days we have spent together drafting, reviewing and revising contributions, out of reach from the warming sun of the French Riviera.

Migration made easy

2018-10-23 Posted by John Grant (BSI), NGP Chair 6345 Hits

IPv6 is finally beginning to be adopted, more than two decades after its specification was published in RFC 1883. Why did it take so long? And how will NGP avoid the same problems?

Internet Protocol (IP) is a "connectionless" technology, in which all the information necessary to deliver a packet to its destination must be in the packet header. This includes the destination address and the address to be used for sending a reply, as well as other information regarding the service the packet should experience. The format of this information has to be the same throughout the system, so that it can be understood by any switching equipment the packet might pass through. IPv4 and IPv6 use different formats, so if support for IPv6 is to be added to an IPv4 network, all equipment in the network must be updated so it can process IPv6 headers. Only when that has been done can IPv6 be used.

When IP was first specified, packet headers were processed at each switching point by software running in a general-purpose computer. Since then, transmission speeds have increased by more than processing speeds, so more of the processing of headers has to be done in hardware. Technologies such as Software Defined Networking (SDN) recognize that most packets are part of a "flow" such as an audio or video stream or an exchange of information between a browser and a web site; decisions about how each flow should be forwarded are made by software and loaded into a "routing table" at each of the switching points. The hardware in the switch reads the packet header and searches the routing table to find the entry that matches it.

Thus, adding support for IPv6 addresses doesn't just need a software upgrade, it needs new hardware that is able to read IPv6 headers in addition to the existing IPv4 hardware.

GS NGP 013 specifies a system (with the working title Flexilink) in which the packet header carries a "label", which is an index into the routing table, and all other information is carried in control plane messages and is thus sent once for each flow instead of in every packet: the ultimate in header compression. Routing table entries in each switch only need to show the action to be performed by that switch, typically the output port number and the label for the next hop. Supporting a new form of addressing (such as content-centric, or using a domain name directly as an address) only needs a software update to the control elements, and no change to the hardware. The packet format can be different for different kinds of link, for instance having a larger field for the label on links that can carry more flows, but this only affects equipment designed for that kind of link, which will in any case have hardware that is specific to that link type.

Any part of an IP network can be replaced by Flexilink without affecting the rest of the network. Depending on requirements, IP packets (either version) can be carried with their headers included, in the same way as over MPLS, or the headers can be stripped on entry and added back on exit. In the latter case the routing table has to hold the necessary information to construct the IP header, but if the IP network would be doing address translation a similar amount of information would need to be held in any case.

Thus with Flexilink a single hardware implementation is able to support multiple addressing schemes including both IPv4 and IPv6.

Great interest in ZSM Forum @ Layer 123 SDN NFV World Congress 2018

2018-10-18 Posted by Nurit Sprecher, ISG ZSM Vice Chair 9716 Hits

The ZSM Forum @ Layer 123 SDN NFV World Congress 2018 sparked great interest. The importance of the ZSM work, its objectives and approach were once again supported during the highly successful and well-attended forum.

The third ETSI ZSM (Zero touch network and Service Management) forum was hosted by Layer123 at the well-attended SDN NFV World Congress 2018 that took place on October 8, 2018 in The Hague, Netherlands. This year the congress focused on three primary themes relating to ZSM: technology (e.g. cloud native NFV, SDN, security), automation (e.g. zero touch, artificial intelligence, programmable cloud) and business (e.g. 5G, service transformation, use cases).

Klaus Martiny (DT), the ZSM Chair, opened with welcome notes. Klaus reminded the audience that a year ago at the same congress he shared the plan for multiple companies to set up a new initiative, focusing on end-to-end service and network automation, that will address the complexity (in terms of network management) created by the technology evolution. Since then, ETSI was selected as the umbrella for the new initiative and the new Industry Specification Group (ISG) was formed in December 2017. The first meeting of the new ISG took place in January 2018. The ISG has made great progress with the work and is well positioned to facilitate collaboration with relevant open-source projects, standardization bodies and fora to help the industry move to an environment that leverages synergies and achieves alignment through convergence on a single end-to-end network and service management architecture. Cooperation and alignment across the industry are essential to promote the adoption of and alignment with the ZSM architecture and solutions as well as to achieve automated end-to-end network and service management. The ISG ZSM intends to hold an open dialogue with the related organizations and open-source projects so as to encourage mutual convergence. Klaus highlighted the importance of providing early implementations and Proofs of Concepts (PoCs) that can validate the specifications and inject input into the specification work. To this end, he invited the industry players to demonstrate PoCs.

Nurit Sprecher (Nokia), the ZSM Vice Chair, presented (see presentation in ZSM Open Area) the drivers and triggers for full end-to-end automation of network and service management, the rationale for the formation of the new ISG and its goals as well as the work program and status. Currently, the ZSM group includes 59 members/participants of whom 18 are operators.

Nurit also highlighted the important role of PoCs in demonstrating the viability of the ZSM implementations and she invited the different players to join the ZSM PoC projects. The ZSM PoCs are multi-party projects in which network/service providers, suppliers, universities, research centers, open-source projects, integrators and others can participate. The results and lessons learned from the PoCs will be channeled to the ZSM specification work. Nurit pointed to the first ZSM PoC, ServoCloud (see ZSM Wiki) that aims to demonstrate efficient lifecycle and element management automation at scale, and she invited the audience to examine the PoC which was presented during the congress. Nurit concluded that we have just embarked on an exciting journey towards the automation transformation that will help operators to meet user expectations for service agility and create new business opportunities.  Moreover, she emphasized that the ISG intends to drive a highly focused and agile industry effort involving key players spanning the breadth of the ecosystem. The ISG is open to both ETSI members and non-ETSI members. The different players in the value chain are welcome to join the ISG effort, contribute to the development of the specifications and demonstrate PoCs.

Diego Lopez (Telefonica), one of the founders of the ISG ZSM, presented the ZSM scenarios and key requirements which are based on the current content of ETSI Group Specification (GS) ZSM-001. The ZSM scenarios are used to derive the requirements for an automated end-to-end network and service management in general, and to drive the design and specification of the ZSM architecture and solutions. ZSM-001 identifies business-oriented scenarios and related automation challenges faced by operators and vertical industries. The scenarios’ analyses derive architectural, functional and operational requirements. Currently there are 31 scenarios and more than 90 requirements. The ISG is working towards grouping related scenarios and consolidating the requirements. The intention is to outline the key areas for automation and zero-touch operation with the scenario groups and to demonstrate the value and applicability of the ZSM architecture and the management services for supporting future-proof scenarios, such as 5G network-slicing management as well as incremental evolution towards end-to-end automation and zero-touch. The presentation is available in the ZSM Open Area.   

ETSI ISG ENI workshop at the SDN/NFV Forum @ Layer 123 SDN NFV World Congress 2018

2018-10-15 Posted by Dr Ray Forbes, ETSI ISG ENI Chair 7528 Hits

ETSI ISG ENI Chair, Aria’s Head of Research and ISG ENI Technical manager Outline ETSI ENI’s AI Use Cases, System Architecture and the China Telecom Led Proof of concept at SDN NFV World Congress in The Hague.

Over the last few years, Layer123’s SDN NFV World Congress has emerged as the best place to assess the mood and state of progressive thinking in telecom operations. So it was fitting that this year’s program included a progress report from the Experiential Networked Intelligence (ENI) Industry Specification Group (ISG) team developing a reference model for the use of AI in telecom operations.

ENI SDN NFV Blog

NFV#23 – Quebecois Summer

2018-10-02 Posted by Diego Lopez, Chair ETSI ISG NFV 8581 Hits

I’d never been to Montreal (or Quebec) until this summer, and I had the double pleasure of visiting Montreal just before my holidays, as well as soon after them. These visits allowed me to get acquainted with Quebecois summer (surprisingly warmer than back home, in Southern Spain), several delicacies (both poutine and the amazing smoked meat, and some really good microbreweries), the crowded Montreal airport (at least on Friday evenings), and the easygoing nature of a city that makes life so smooth and work so productive.

And a productive week it was indeed. It was the first meeting after I was appointed chair of ETSI NFV for a second term, an honor I really appreciate and that I can only respond to by committing to do my best to keep ISG NFV where this extraordinary community has already brought it: at the core of the radical transformation towards the next generation of networks. And the leadership team is strengthened with the re-appointment of Joan Triay (NTT DOCOMO) as chair of the Technical Steering Committee, leaving the technical management of our extensive work program in the best possible hands.

It was also a meeting for consolidating our vision for the future, defining a common view that, with all the natural differences among the diverse organizations contributing to the NFV effort, will guide us in a new two-year term for the ISG. There was an in-depth discussion about the future of the group during one of our much-loved evening sessions, and the goals for the new term were agreed and submitted to the ETSI Director General for approval, just in time to be discussed at the September ETSI Board meeting.Group photo of participants at NFV23The initial phase, in which the basic NFV concepts and the NFV architectural framework were defined, established a firm foundation for the extensive specification work required to enable an open ecosystem for this new technology. Building on this foundation, as well as climbing a very steep learning curve, required the two first terms of the ISG, with the third that is about to be completed, focused on making the NFV promise suitable for real operations, and establishing the baseline for telecommunications and enterprise networks evolution, infrastructure deployment, service development, and management automation in a software-defined networking world.

What is more, the ISG has managed to explore and enhance the consensus mechanisms required to more rapidly define standards by fostering collaboration with SDOs and related initiatives, especially open-source communities. We have facilitated fruitful practical collaboration with these communities, and the industry in general, boosting prospects for interoperability, as demonstrated by the three successful interoperability events held to date. The ETSI NFV community intends to continue consolidating, improving and evolving the NFV foundation specifications as the key enablers of an ecosystem and strengthening the cross-industry collaborative mechanisms which will boost progress and ensure an agile response to the evolving industry needs.

MEC – your guide into 5G

2018-08-03 Posted by Alex Reznik, Chair of MEC ISG 12477 Hits

One problem with summer holidays in our industry (or is it a benefit?) is that one tends to let certain things slide and to enjoy more time away from work – whether it be on a formal vacation or just by working a little less than our usual “40 hours” – a very loooong 40 hours – per week. I am certainly guilty of that this summer – and one of the things I am guilty of is not highlighting some really important output from the ETSI MEC ISG. But… as they say… better late than never. So here it goes, but let’s start with background and get to the cool things ETSI MEC produced as we go.

We’ve all heard that “MEC is a 5G technology” although what that means is not exactly clear. In fact, in my very first blog posting, I highlighted that this can lead to some of my (least) favorite “MEC myths”. Here those myths are, re-stated:

  • MEC is a 5G technology, so until I roll-out a 5G network I don’t need to worry about it
  • ETSI MEC will be made irrelevant as soon as 3GPP defines its AF/NEF
  • MEC is only needed before 5G, at which point CUPS (meaning the UPF) replaces it

Side note: yes, the first and third statements are in fact mutually contradicting. But these are myths, they don’t need to be mutually consistent.

Clearly, I disagree with all of these statements, but what is the truth “according to Alex”?

Key achievements of the ZSM Interim#1 meeting: driving ZSM towards a truly service-based architecture and demonstrating the first ZSM PoC

2018-08-02 Posted by Nurit Sprecher, ISG ZSM Vice Chair 9511 Hits

The ZSM interim#1 meeting was hosted by Ericsson on 9-12 July, 2018 at their headquarters in Kista, Sweden, in a meeting room which was named after Hilda, the wife of Ericsson’s founder. The meeting was a good opportunity for the ZSM team to discuss additional scenarios, advance the ZSM architecture work and demonstrate the first ZSM PoC.

ZSM 2018 Interim 1

As described in great-strides-made-by-technical-brainstorming-at-zsm-3, the ZSM architecture supports the separation of management and automation into different areas of concern, i.e. management domains. At the ZSM interim#1 meeting and in follow-up conference calls, agreement was reached on the high-level architecture inside a management domain (depicted in Figure 1 below). Each domain includes functional components (FCs) that perform specific task(s) and expose one or more management services via service interface(s). Some of the services are internal services and can only be consumed by authorized functional components inside the domain. Other services can be exposed and also consumed by authorized functional components outside the domain (including those contained in the E2E service management domain and the digital storefront). The management services within the management domain are assembled into logical groups, such as domain control services, domain orchestration services, domain intelligence services and domain assurance services. The architecture is designed to enable closed-loop automation (connecting assurance and fulfillment processes) where the automated decision-making mechanisms (e.g. self-optimization and automated service assurance) can be bounded by rules and policies.

Great strides made by technical brainstorming at ZSM#3

2018-06-21 Posted by Nurit Sprecher, ISG ZSM Vice Chair 10921 Hits

The ZSM ISG reached a significant milestone, agreeing on the baseline for the ZSM architecture

The third ZSM meeting was hosted by Huawei on June 04-08, 2018, in the fascinating Chinese city of Shenzhen.

The meeting was particularly special because of the intensive and fruitful ad hoc technical brainstorming that took place during the week, enabling thorough consideration of the requirements, architectural principles and design. By the end of the meeting, the ZSM group had agreed on the baseline for a service-based, end-to-end management architecture (depicted in Figure 1 below). The architecture enables automation at scale and allows all operational processes and tasks – delivery, deployment, configuration, assurance, and optimization – to be executed automatically.

The architectural principles and requirements were agreed on with the aim of shaping the architectural baseline and guiding its further development during the standardization process. The architecture is modular, flexible and extensible. It allows deployments that can be adapted to different volumes of managed entities and/or to various scales of the geographic distribution of these entities. Modules can be independently deployed and scaled. The functional components of the architecture will also be designed for failure – so that management services can cope with failure of themselves and of the infrastructure without or only with modest service degradation.

Infrastructure Resources visualised in chart


Figure 1: ZSM Architecture

NFV#22 – Reflections on a Remarkable Journey

2018-05-30 Posted by Don Clarke, NFV ISG Network Operator Council Chair 9234 Hits

As I flew to Sophia Antipolis for the twenty second plenary session of the ETSI NFV Industry Specification Group (ISG), I reflected how far we had come since publication of the now famous white paper introducing the NFV concept.

Until that moment in October 2012, the term “Network Function Virtualisation” did not exist, it had emerged from a meeting of the founding group in Paris in the summer of 2012 to distinguish the topic from SDN which by then was gaining momentum. We were all experienced telecommunications R&D leaders who knew that our goals were ambitious and would be highly disruptive to the industry, so we would need to be extraordinarily diligent to bring all the industry players on board, large and small, and with everyone able to be heard and to contribute their energies and expertise.

We chose ETSI to host the effort for many different reasons, but perhaps the most important ones were transparency of governance proven by many years of global standards development, and open membership for small players, especially independent software vendors whom we felt would be important contributors. We have never regretted the decision to come to ETSI who have provided fantastic support, and the rigorously consensus-driven decision-making process has kept us grounded.

leadership-NFV22-2018All of that seemed so long ago and I couldn’t have imagined that along the way I would move to the United States and start a new career in the cable industry while retaining my role as chair of the ETSI NFV Network Operator Council. After a 40+ year R&D career in BT, it was a seamless transition that was as unlikely as it was life changing for me.

Looking back over the past six years, there have been moments of great pride, such as when agreement was reached in a late-night session on the ETSI NFV Architectural Framework, interspersed with moments of doubt as strident voices from the world of software repeatedly criticized our efforts.

As with all things, time is a great leveler, five years on the NFV Architectural Framework has withstood the test of time and is being deployed at scale, and open source groups have begun to realize that the telecommunications networks environment is very different to the enterprise IT environment. Telecommunications networks are critical national infrastructures that underpin global commerce and security and as such demand analytical rigor and auditability that only implementations based on high quality specifications endorsed by the key stakeholders can provide.

Even as we took a page from the open source book and opened our draft specifications for external scrutiny and feedback and continually sought ways to speed up our work. And we founded OPNFV to enable open source groups to collaborate and provide feedback to ETSI NFV.

What is Edge?

2018-05-14 Posted by Alex Reznik, Chair of MEC ISG 14445 Hits

Recently, one of the ETSI staff folks pinged me an e-mail that said, “Someone asked me ‘What is Edge’ and I could not quite reply. Can you help?” Well, come on! The answer is simple. 

Edge is… and this is where I got stuck. Really, the answer depends… well… on who you ask and when or where you ask them. And this, really, is how some blog posts are born.

Let’s start with examples. Amazon seems to have a clear definition of what edge is – just look at Greengrass.

Microsoft more or less agrees with them, ergo Azure IoT Edge  or AzureStack.

So there we are – the definition of the edge. Take your favorite cloud provider, one with the foresight to “extend” their cloud to on-prem deployments either on IoT devices or otherwise and that’s the edge. Well, that is an edge, and, perhaps in the world of Enterprise IT computing it is the prevalent type of edge, but in Telco (i.e. in the world of MEC) it is not – it’s just an edge.

Don't take the wait-and-see approach

2018-04-10 Posted by Alex Reznik, Chair of MEC ISG 7480 Hits

Let’s start at the beginning, as the saying goes; and in the case of this blog that seems to be the question of what the group I work in – ETSI MEC – does, what it produces and how it fits into the overall Edge Computing ecosystem.

Coincidentally, this is related to one of my favorite myths, which goes something like this. “There are soooo many standards, industry bodies and open source groups working on MEC. With all of these organizations competing with each other, it’s not clear which one to choose. I think we need to wait for the dust to settle before doing anything in MEC.”

Like most myths, this one has a not-so-small core of truth. It is true that there are quite a few standards, industry bodies and open source groups working on Edge Compute related topics. And, it is certainly true that this has created a certain amount of confusion in the marketplace.

    Previous    
1 2 3