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.



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.



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



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.

Infrastructure Resources visualised in chart


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