Back

Technologies


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.

Fig 1 ZSM Architectural Framework

Fig 1 ZSM Architectural Framework.2

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.



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).Blog ZSM Forum 2018

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



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



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



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.



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.

ZSM3-architecture-image


Figure 1: ZSM Architecture



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



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.



A blog about MEC? Well, as the chair of ETSI’s MEC ISG for a year now, I wondered what was there about MEC that could be said in a blog format; that would be of real interest to the community; that would have some chance of making me the social media superstar of edge computing?

This took some sleeping, but one fine sunny morning in Shanghai (during our very successful 13th plenary), I hit on an idea. One of the privileges of chairing a standards group is that you get to represent that group in various public events. And so, over the past year, I’ve been doing a good amount of public speaking on edge computing in general and MEC specifically. I’ve also been doing quite a bit of “private speaking” of a similar kind, as part of my day job at HPE.

Thinking back over all that speechifying on that fine sunny morning in Shanghai I realized that much of it is spent addressing the MASSIVE CONFUSION that exists around MEC – and that much of what I say is constant across the various venues and audiences. And so… why not use the tools of social media to get the message out and try and dis-spell some of that confusion.



ZSM2-Helsinki-2018The second meeting of the ETSI Zero touch network and Service Management (ZSM) Industry Specification Group (ISG) was hosted by Nokia at its Båtvik Training Center in Kirkkonummi, Finland, on March 13-15, 2018.

Forty-nine experts participated in the meeting and more than one hundred contributions were submitted and discussed. The meeting started with key notes presented by Lauri Oksanen, VP Research and Technology at Nokia, on “the automation imperative” to transform economy and society and to create time.

Klaus Martiny, the ZSM ISG Chair, continued with his perspective, highlighting the steady growth of the ISG which has seen a 56% increase since the kickoff meeting. Fifty organizations have already joined the group (see the List of Members and Participants), underlining the importance of the ZSM work for future network and service automation. The fact that the ZSM experts come from different backgrounds (e.g. Telco, IT, Enterprise) is a positive development, since the ISG strives to bring these worlds together, utilizing the best that each can offer. However, this may create a slow start, since all the members need to speak a common language.



The NFV community met for the 21st time (NFV#21) from February 26 to March 2, in a familiar setting:

ETSI-snowflakes-NFV21-2018ETSI headquarters in Sophia Antipolis, France.

The flawless organization, the friendly faces greeting us, the countless wonderful coffee machines, everything was normal. What was less familiar: it snowed. On the Cote d’Azur. Twice(!). For a total of approximately 15cm. This is very rare in this region. Apparently, the last time it snowed was during NFV#1, back in January 2013. While we are solving the challenges for NFV, the weather is telling us we can easily deal with another one!

Despite the predictable flight delays resulting from the frigid European weather, the event was well attended by over 80 members of the core team. And it was a busy, productive week.

Work on Release 3 is well under way. There are currently 17 new features being actively developed, along with 15 active work items related to Release 3. In addition, multiple Release 2 deliverables (13 as of now) are being currently propagated to Release 3 (with their corresponding work items). At NFV#21, a third maintenance cycle for Release 2 work items was also approved, so the maintenance work will continue for the first half of 2018. That’s a lot of balls up in the air at the same time, and it’s a remarkable achievement that this highly focused group can pull this off.

The results of the 2nd ETSI NFV Plugtests were center stage at this meeting: the findings were presented to the plenary and discussed within the TST working group who will incorporate the feedback into their documents going forward. Clearly the industry is progressing with more energy compared with just one year ago. The Plugtests results will be summarized in a separate blog post and presented at upcoming conferences.

Two new working group leaders were elected since the last plenary meeting: Julien Maisonneuve (Nokia) and Ulrich Kleber (Huawei). Julien brings extensive leadership experience, while Uli brings new perspectives including valuable open source experience. These roles require a lot of personal commitment and long hours across multiple time zones. We are very grateful to both of them.



Almost every packet on a digital network is part of a "flow", a sequence of packets from the same source to the same destination. These flows are of two types:

  • they either carry a continuous stream of data such as an audio or video signal
  • or transfer information between processes running in computers, as in a TCP session

We can think of the former as "AV" flows and of the latter as "IT" flows. For many applications, AV flows are sensitive to "latency", which is the time between a packet being transmitted by the sender and received at its destination; in a phone call, for example, longer delays make it difficult to have a natural conversation. New applications proposed for 5G, such as those involving augmented or virtual reality, or tactile feedback, will have even more severe requirements. For IT flows, if latency is important at all it will be the average over time that matters, whereas for AV flows it is the delay for the slowest packet.

Current-generation networks were originally designed as IT networks, carrying IT flows, and have had various features added to assist AV flows, which increase complexity but still do not provide the best service for these flows.



With the publication of ETSI GS NFV-SOL005, the specification of the RESTful APIs exposed by an NFV Orchestrator (NFVO) towards operations support systems (OSS), the ETSI NFV Industry Specification Group (ISG) has successfully met its objective to deliver a full set of API specifications enabling an open ecosystem where Virtualized Network Functions (VNFs) will be interoperable with independently developed management and orchestration systems, and where the components of a management and orchestration system are themselves interoperable.

Encouraging interoperability within an open ecosystem was a key objective for ETSI NFV when it was launched in late 2012 by global carriers.

These API specifications are the result of a wide industry consensus. Compliance to them permits a wide range of multi-vendors deployment scenarios. For example, a VNF can be managed by a generic VNF Manager (VNFM) function (stand-alone or combined with an NFVO), an NFVO can consume the services of a VNF-specific VNFM, and the services exposed by an NFVO can be consumed by higher-level service orchestration functions.

Furthermore, the ISG has completed revisions of two previously published API specifications which detail the REST APIs between an NFV Orchestrator (NFVO) and a VNF Manager (VNFM), and between a VNFM and a VNF or its Element Manager, respectively ETSI GS NFV-SOL 003 and ETSI GS NFV-SOL 002, completed in July 2017. Revised versions have been approved in December 2017, the main change being the support of a TLS-based option for controlling API access authorization (as an alternative to the use of OAuth 2.0).



One of the main drivers for the formation of ISG NGP was operators' need to make more efficient use of spectrum. While New Radio allows more bits to be carried, by some estimates half of those bits are unnecessary overhead. NGP is investigating how these overheads can be reduced, while at the same time providing the kind of performance (such as lower latency) that the new services proposed for 5G will need.


We use cookies or similar technologies to collect data about your use of this website and to improve your experience when using it. To find out how to disable our cookies, please visit our Privacy Policy.

  I accept cookies from this site.
EU Cookie Directive plugin by www.channeldigital.co.uk