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.



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


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!




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



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


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. 



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 chairman 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



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.



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.



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.



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.



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.



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.



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.



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. 



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 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



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) Chairman.

Don Clarke (CableLabs), our NFV NOC Chairman 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 Chairman, 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.



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.