ETSI has now completed Release 2 of its Experiential Networked Intelligence (ENI) specifications with the ETSI GS ENI 005 system architecture.
ETSI GS ENI 005 and associated documents will provide better insight into network operations – allowing more effective closed-loop decision making plus better lifecycle management. Through its use, network operators will be able to leverage acquired data and apply artificial Intelligence (AI) algorithms to it. This will mean that operators will be able to respond much quicker to changing situations and gain far greater agility.
The services being delivered across their networks may thereby be rapidly adapted and the resources they have available correctly assigned in accordance with subscribers’ requirements, or any other alterations in circumstances (either operationally or commercially driven).
An industry specification group (ISG) focused on ENI was first established by ETSI five years ago. The organisations involved include many of the leading mobile operators worldwide – full list available here.
ETSI ENI Release 2 defines the key architectural requirements (GS ENI 002), and provides a more comprehensive array of potential use cases (GS ENI 001) and applicable proof of concept (PoC) specifications. To support this release, the ENI ISG has produced a series of reports. These cover data characterization, fault identification, the different types of AI mechanisms that can be employed (along with details of the associated bias and ethical implications), the constituent functional blocks needed for modular design implementations and how to assure their interoperability.
“ENI will have an important part to play in how next generation networks are managed, making them contextually aware and giving them greater inherent flexibility,” states Dr Raymond Forbes, Chair of the ETSI ENI ISG. “Use cases and PoCs are already enabling its validity to be demonstrated, and with ETSI ENI Release 2 we are providing a framework upon which operators and their technology partners can implement it into their infrastructure.”
ETSI’s ENI Release 2 includes the following specifications and reports:
- GS ENI 001 Use Cases
- GS ENI 002 Requirements
- GR ENI 004 Terminology
- GS ENI 005 System Architecture
- GR ENI 008 Intent Aware Network Autonomicity
- GR ENI 009 Data Mechanisms
- GR ENI 010 Evaluation of categories for AI application to Networks
- GR ENI 016 Functional Concepts for Modular System Operation
- GR ENI 017 Overview of Prominent Control Loop Architectures
- GR ENI 018 Artificial Intelligence Mechanisms for Modular Systems
From the Systems Architecture Spec:
The ENI System is an innovative, policy-based, model-driven functional architecture that improves operator experience. In addition to network automation, the ENI System assists decision-making of humans as well as machines, to enable a more maintainable and reliable system that provides context-aware services that more efficiently meet the needs of the business.
For example, the ENI System enables the network to change its behaviour (e.g. the set of services offered) in accordance with changes in context, including business goals, environmental conditions, and the varying needs of end-users.
This is achieved by using policy-driven closed control loops that use emerging technologies, such as big data analysis, analytics, and artificial intelligence mechanisms, to adjust the configuration and monitoring of networks and networked applications. It dynamically updates its acquired knowledge to understand the environment, including the needs of end-users and the goals of the operator, by learning from actions taken under its direction as well as those from other machines and humans (i.e. it is an experiential architecture).
It also ensures that automated decisions taken by the ENI System are correct and increase the reliability and stability, and lower the maintenance required, of the network and the applications that it supports. It improves and simplifies the management of network services through their visualization, and enables the discovery of otherwise hidden trends and interdependencies.
ETSI provides members with an open and inclusive environment to support the development, ratification and testing of globally applicable standards for ICT systems and services across all sectors of industry and society. We are a non-profit body, with more than 950 member organizations worldwide, drawn from 64 countries and five continents. The members comprise a diversified pool of large and small private companies, research entities, academia, government, and public organizations. ETSI is officially recognized by the EU as a European Standards Organization (ESO). For more information, please visit us at https://www.etsi.org/
by Dario Sabella, Intel, ETSI MEC Chair
This is Part II of a two part article series on MEC. Part I may be accessed here.
Access to Local and Central Data Networks (DN):
Figure 5. below illustrates an example of how concurrent access to local and central DN (Data Networks) works. In this scenario, the same UP session allows the UE to obtain content from both the local server and central server (service continuity is enabled by IP address anchoring at the centralized UPF, with no impact on UE by using Uplink Classifier -ULCL).
Figure 5. Concurrent access to local and central Data Networks (DN)
In this context it is assumed that MEC is deployed on the N6 reference point, i.e. in a data network external to the 5G system. This is enabled by flexibility in locating the UPF. The distributed MEC host can accommodate, apart from MEC apps, a message broker as a MEC platform service, and another MEC platform service to steer traffic to local accelerators. Logically MEC hosts are deployed in the edge or central data network and it is the User Plane Function (UPF) that takes care of steering the user plane traffic towards the targeted MEC applications in the data network.
The locations of the data networks and the UPF are a choice of the network operator who may choose to place the physical computing resources based on technical and business parameters (such as available site facilities, supported applications and their requirements, measured or estimated user load etc). The MEC management system, orchestrating the operation of MEC hosts and applications, may decide dynamically where to deploy the MEC applications.
In terms of physical deployment of MEC hosts, there are multiple options available based on various operational, performance or security related requirements (for more details, see the ETSI paper “MEC in 5G networks”  and the more recent study on “MEC 5G integration” ).
Moving forward with 5G (3GPP Release 17 onwards):
Given the increase of 5G adoption, and the progressive migration of network operators towards 5G SA (Stand Alone) networks this above MEC deployment is naturally becoming a long-term option considering the evolution of the networks. A major joint opportunity for MEC 5G integration, is on one hand for MEC to benefit from the edge computing enablers of the 5G system specification, and for 3GPP ecosystem to benefit from the MEC system and its APIs as a set of complementary capabilities to enable applications and services environm5 ents in the very edge of mobile networks. IN this perspective, also in the view of more mature 5G deployments, ETSI MEC is aligning with 3GPP SA6, defining from Rel.17 an EDGEAPP architecture (ref. 3GPP TS 23.558).
In this perspective, an ETSI white paper  provides some first information on this ongoing alignment, which is introducing a Synergized Mobile Edge Cloud architecture supported by 3GPP and ETSI ISG MEC specifications. This is an ongoing alignment, also in the view of future Rel.18 networks, and with respect to MEC federation and the related expansion (for MEC Phase 3 specifications) from intra-MEC communication to inter-MEC and MEC-Cloud coordination (as depicted in Figure 6). A very first study in this field has been published by ETSI MEC with the ETS GR 035 report .
Figure 6. MEC Phase 3: Expansion from intra-MEC to inter-MEC and MEC-Cloud
The MEC 035 study on “Inter-MEC systems and MEC-Cloud systems” was a major effort in ETSI MEC, mainly driven by the need of operators to form federated MEC environments. For example, to achieve V2X (vehicle to X) service continuity in multi-operator scenarios, to enable edge resource sharing among the federating members, and in general offer edge computing infrastructure as an asset to provide global services benefiting of better performance and low latency environments. Many use cases in MEC 035 are in need of MEC federation. Many are also based on the ETSI MEC requirements in MEC 002 (e.g. use cases like “V2X multi-stakeholder scenario” and “Multi-player immersive AR game,” among others).
This work carefully aligns with a GSMA publication introducing requirements for their “Operator Platform” concept. [The GSMA Operator Platform defines a common platform exposing operator services/capabilities to customers/developers in the 5G-era in a connect once, connect to many models. The first phase of the platform focuses on Edge which will be expanded in future phases with other capabilities such as connectivity, slicing and IPComms.] In this scenario, multiple operators will federate their edge computing infrastructure to give application providers access to a global edge cloud which may then run innovative, distributed and low latency services through a set of common APIs.
Currently ETSI MEC is working on the related normative work to enable and support this concept of MEC Federation, by defining a suitable MEC architecture variant in MEC GS 003, updating other impacted MEC specifications in Phase 3, and by introducing proper “MEC Federation Enablement APIs” (MEC GS 040) .
Enablement of MEC Deployment and Ecosystem Development:
MEC adoption is critical for the ecosystem. In this perspective, ETSI ISG MEC has established a WG DECODE dedicated to MEC Deployment and Ecosystem engagement activities. As a part of that (but not limited to it!) MEC is publishing and maintaining a MEC Wiki page (mecwiki.etsi.org), including links to several examples of MEC adoption from the ecosystem:
- MEC Ecosystem, with 3rd party MEC Applications and Solutions
- Proof of Concepts (PoCs), with a list and description of past and ongoing PoCs, including the ISG MEC PoC Topics and PoC Framework (and Information about process, criteria, templates….)
- MEC Deployment Trials (MDTs), with a list and description of past and ongoing MDTs (and the MDT Framework, clarifying how to participate)
Additionally, the MEC Wiki also includes: information on MEC Hackathons, MEC Sandbox, OpenAPI publications for ETSI MEC ISG API specifications, and outreach activities (e.g. MEC Tech Series of video and podcasts).
Summary and Conclusions:
- MEC (Multi-access Edge Computing) “offers to application developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network” (see Ref 1. below).
- The nature of the ETSI MEC Standard (as emphasized by the term “Multi-access” in the MEC acronym) is access agnostic and can be applicable to any kind of deployment, from Wi-Fi to fixed networks.
- MEC is also serving multiple use cases and providing an open and flexible standard, in support of multiple deployment options, especially for 5G networks.
- MEC is focused on Applications at the Edge, and the specified MEC service APIs include meaningful information exposed to application developers at the network edge, ranging from RNI (Radio Network Information) API (MEC 012), WLAN API (MEC 029), Fixed Access API (MEC 028), Location API (MEC 013), Traffic Management APIs (MEC015) and many others. Additionally, new APIs (compliant with the basic MEC API principles) can be added, without the need for ETSI standardization.
- The ongoing ETSI MEC work in alignment with 3GPP includes aspects related to MEC 5G Integration and future evolution, including the standardization work on MEC Federation. Also, carefully aligning the MEC work with requirements from GSMA OPG (Operator Platform Group).
Finally, since MEC adoption is critical for the IT ecosystem, ETSI ISG MEC has established a WG dedicated to MEC Deployment and Ecosystem engagement activities.
There is also a dedicated MEC Wiki page (mecwiki.etsi.org) which provides several examples of MEC adoption from the ecosystem (PoCs, trials, MEC implementations). It also includes information on MEC Hackathons, MEC Sandbox, OpenAPI publications for ETSI MEC ISG API specifications, and outreach activities (e.g. MEC Tech Series of video and podcasts).
Previous References (from Part I):
 ETSI MEC website, https://www.etsi.org/technologies/multi-access-edge-computing
 ETSI GS MEC 003 V2.1.1 (2019-01): “Multi-access Edge Computing (MEC); Framework and Reference Architecture”, https://www.etsi.org/deliver/etsi_gs/mec/001_099/003/02.01.01_60/gs_mec003v020101p.pdf
 ETSI White Paper #36, “Harmonizing standards for edge computing – A synergized architecture leveraging ETSI ISG MEC and 3GPP specifications”, First Edition, July 2020, https://www.etsi.org/images/files/ETSIWhitePapers/ETSI_wp36_Harmonizing-standards-for-edge-computing.pdf
 ETSI GS MEC 009 V3.1.1 (2021-06), “Multi-access Edge Computing (MEC); General principles, patterns and common aspects of MEC Service APIs”, https://www.etsi.org/deliver/etsi_gs/MEC/001_099/009/03.01.01_60/gs_MEC009v030101p.pdf
 ETSI White Paper No. 24, “MEC Deployments in 4G and Evolution Towards 5G”, February 2018, https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp24_MEC_deployment_in_4G_5G_FINAL.pdf
 ETSI White Paper No. 28, “MEC in 5G network”, June 2018, https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf
 ETSI GR MEC 031 V2.1.1 (2020-10), “Multi-access Edge Computing (MEC); MEC 5G Integration”, https://www.etsi.org/deliver/etsi_gr/MEC/001_099/031/02.01.01_60/gr_MEC031v020101p.pdf
 ETSI GR MEC 035 V3.1.1 (2021-06), “Multi-access Edge Computing (MEC); Study on Inter-MEC systems and MEC-Cloud systems coordination”, https://www.etsi.org/deliver/etsi_gr/MEC/001_099/035/03.01.01_60/gr_mec035v030101p.pdf
 ETSI DGS/MEC-0040FederationAPI’ Work Item, “Multi-access Edge Computing (MEC); Federation enablement APIs”, https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=63022
by Michael Howard of IHS-Markit (co-founder and lead analyst at Infonetics)
Network Function Virtualization (NFV) MANO (management and network orchestration) and VNF (virtual network function) software revenue was $3.5B in 2016 and is expected to reach $5.9B for 2017, according to the NFV Hardware, Software, and Services biannual market tracker from IHS Markit.
NFV revenue is not all new: it includes displaced revenue and newly identified parts of existing market segments. In 2021, 49% of the NFV revenue will be new revenue from software and outsourced services, and 8% will be displaced revenue spent on NFVI server/storage/switch hardware purchased instead of purpose-built network appliances. The remaining 43% represent spend on VNF software.
“Operators around the world are planning or extending their NFV environments to customer sites on CPE (customer premises equipment), which we are calling uCPE (universal CPE). We expect operators will spend $11M on physical “uCPE” hardware in 2017, growing to $448M in 2021,” stated Michael Howard, Executive Director Research and Analysis for Carrier Networks at IHS Markit.
“In our 5th annual global carrier surveys on SDN and NFV, 82% of respondents indicated they are deploying or plan to execute VNFs on uCPE located at customer sites (with 97% in COs and 85% in DCs). Because this is such a large part of operator plans and products available now, we have sized and forecast the uCPE market,” Michael Howard added.
Above illustration courtesy of IHS-Markit
Editor’s Note: NFV and MANO Backgrounder:
NFV Reference Architecture showing NFV Orcestrator and VNF Manager
Above illustration extracted from the ETSI NFV MANO Specification
Recently, there’s been more innovation around the MANO portion of the NFV infrastructure and a recognition that MANO might need more development as a model given the gap between the MANO layer in NFV and the OSS/BSS (operations support systems/business support systems) portion of network operator businesses that handle the core orchestration and billing functions as shown above.
More NFV Market Highlights (IHS-Markit):
· Revenue to vendors and systems integrators for outsourced services for NFV projects will grow to $16.6B in 2021 with a 2016-2021 CAGR of 23%.
· NFV software (NFV MANO and VNFs) revenue will grow to $15.5B in 2021 with a 2016-2021 CAGR of 36%.
· NFV hardware (NFVI server, storage, and switches) revenue will grow from $696M in 2016 to $3.1B in 2021 with a 2016-2021 CAGR of 35%.
· Service providers will invest $2B in hardware and software for the enterprise vCPE use case in 2021, and $293M for the consumer vCPE use case.
NFV Hardware, Software and Services Report Synopsis:
The IHS Markit NFV Hardware, Software, and Services market tracker provides biannual worldwide and regional market size, forecasts through 2021, analysis and trends for:
(1) NFV hardware [servers, switches, storage and uCPE],
(2) software: NFV MANO, Virtual Network Functions (VNF) [SD-WAN, mobile core & EPC, PCRF & DPI, security, IMS, SBC & DCS, video CDN, vRouters, and other VNFs],
(3) outsourced services for NFV projects, plus NFV use case spending [consumer vCPE and enterprise vCPE].
Vendors tracked include Amdocs, ADVA, Ciena, Cisco, ClearPath, Ericsson, Fujitsu, HPE, Huawei, Juniper Networks, Metaswitch Networks, Nakina Systems, Nokia, Nuage Networks, NEC, NetCracker, Oracle, ZTE, and others.
I strongly respect Mr. Howard’s work ethic and primary market research findings. While not having read this latest report, I’m sure it’s excellent. However, I’m still much more pessimistic on the NFV market due to the lack of standards for exposed interfaces/APIs and backward compatibility (especially hybrid network management) with the installed base of non NFV equipment/boxes.
ABI Research on NFV Market:
ABI Research forecasts that North America will lead the NFV market, accumulating $13 billion in NFV-related investments during 2022, while Europe will experience the highest growth rate at an estimated 53% CAGR between 2017 and 2022. Early adopters claim several benefits to NFV-enabled systems, which include reductions in network CAPEX & OPEX, service agility, and reduced deployment times for new network elements.
“In 2015 and 2016, the market experienced some early successes but mostly reconsiderations and failures with NFV,” says Neha Pachade, Senior Analyst at ABI Research. “Early adopters conducted proof of concept testing and NFV-integrated system demonstrations with the aim to understand the true impact of NFV in the technical, operational, and cultural domains. Our forecasts indicate that NFV will become a sizeable opportunity for vendors, although it is not yet clear whether it will cannibalize existing hardware-based product lines or create new market use cases.”
ABI Research estimates that total NFV market revenues will reach $38 billion in 2022. Hardware spend—including servers, storage devices, and switches—will reduce with time, while software and services will have higher growth rates of 55% and 50%, respectively. Although the market is evolving and technical expertise is starting to mature, the standardization and multi-vendor involvement challenges will remain stagnant for the next couple of years. Software and services vendors will have opportunities to identify NFV use-cases in enterprise verticals and use these to offer end-to-end integrated systems.
“Early contracts and market trends illustrate the biggest winners are likely to be the established vendors, including Ericsson, Huawei, and Nokia, as well as specialists like Amdocs and Netcracker, with systems integration becoming more important each day,” concludes Pachade. “Several vendors also place heavy and risky bets on open source software, which may increase business opportunities but may also create difficult choices for them in the future, particularly if telco interest in specific open source projects fizzles out. For the time being, NFV is mostly considered as a cost-cutting exercise, since new revenue opportunities require a transformation in a much broader context, which is more likely to be driven by 5G, after 2020.”
These findings are from ABI Research’s Network Functions Virtualization Tracker and Forecasts report.