ITU-R M.2150-1 (5G RAN standard) will include 3GPP Release 17 enhancements; future revisions by 2025
ITU-R Recommendation M.2150 (previously known as IMT 2020) is being updated with new features for the 3GPP and ETSI-DECT 5G radio interface specifications in Annex 1, 2 and 4. This updated recommendation has been given the temporary name “M.2150-1.”
The main changes include the addition of enhanced capabilities for 3GPP 5G-SRIT (Set of Radio Interface Technologies), 3GPP 5G-RIT (Radio Interface Technology), DECT 5G-SRIT, and some consequential changes to the overview sections of the text, as well as to the Global Core Specifications.
This M.2150-1 revision is expected to be completed at ITU-R WP 5D meeting #44 which is June 13-22, 2023 in Geneva.
Annex 1: 3GPP 5G SRIT
The main purpose of this update is to align Rec. ITU-R M.2150 to the Release 17 December 2022 version of the 3GPP Specifications of 3GPP 5G-SRIT. The main features introduced in this update are:
– Addition of new modulation schemes for NB-IoT and LTE-M (LPWANs for IoT connectivity)
– The addition of new numerologies for NR;
– New logical channels and their mapping to physical channels;
– Reduced Capability (RedCap) NR devices.
Annex 2: 3GPP 5G RIT- aka “5G-NR”
The main purpose of this update is to align Rec. ITU-R M.2150 to the Release 17 December 2022 version of the 3GPP Specifications of 3GPP 5G-RIT. The main features introduced in this update are:
– The addition of new numerologies for NR
– New logical channels and their mapping to physical channels
– Reduced Capability (RedCap) NR devices.
IMPORTANT NOTE: Since 3GPP Release 16 5G-NR URRLC in the RAN spec has not been completed yet, it was not submitted to 5D for inclusion in M.2150-1. Therefore, ITU M.2150-1 still does not meet the URLLC Minimum Performance Requirements specified in ITU-R M.2410. In particular, 3GPP Rel 16 URRLC in the RAN:
|1335||830074||Physical Layer Enhancements for NR Ultra-Reliable and Low Latency Communication (URLLC)||NR_L1enh_URLLC||1||Rel-16||R1||6/15/2018||12/22/2022||96%||RP-191584|
Annex 4: DECT 5G – SRIT
The DECT 5G – SRIT consists of two components: 1.] DECT-2020 NR and 2.] 3GPP 5G-NR. The followings contain the information for each of the component RITs.
– DECT-2020 NR component RIT The original submission contained the layers up to the ‘Medium Access Control’ layer. In this update the ‘Data Link Control’ (DLC) and ‘Convergence’ (CVG) layers have been added.
– 3GPP 5G- NR component RIT. The changes are identical to those in Annex 2. The main purpose of this update is to align Rec. ITU-R M.2150 to the Release 17 December 2022 version of the 3GPP Specifications of 3GPP 5G-RIT.
• The addition of new numerologies for NR
• New logical channels and their mapping to physical channels
• Reduced Capability (RedCap) NR devices.
ITU-R WP5D meeting #43 considered future revisions of Recommendations ITU-R M.2150 (and ITU-R M.2012) after year 2023 and prepared initial and preliminary revision schedules in which revisions of both Recommendations would be completed by the end of 2025. That may or may not include what pundits label “5G-Advanced,” which is coming from 3GPP Release 18.
Objectives for WP5D – WG Technology Aspects at the 44th WP 5D meeting (June 12-23, 2023 in Geneva):
i) finalize preliminary draft revision “after year 2021” of Recommendation ITU-R M.2150;
ii) finalize preliminary draft revision of Recommendation ITU-R M.2012-5;
iii) finalize the Report ITU-R M.[IMT.ABOVE 100GHz];
iv) finalize preliminary draft revisions of Recommendations ITU-R M.2070-1 and ITU‑R M.2071-1 “Generic unwanted emission IMT‑Advanced”;
v) continue working on OOBE BS/MS for IMT-2020 “Generic unwanted emissions IMT‑2020.”
IMT 2020.SPECS approved by ITU-R but may not meet 5G performance requirements; no 5G frequencies (revision of M.1036); 5G non-radio aspects not included
5G Specifications (3GPP), 5G Radio Standard (IMT 2020) and Standard Essential Patents
Executive Summary: IMT-2020.SPECS defined, submission status, and 3GPP’s RIT submissions
ETSI DECT-2020 approved by ITU-R WP5D for next revision of ITU-R M.2150 (IMT 2020)
ETSI Telemetry Standard for Optical Access Networks to enhance FTTP QoE
As the scale and services offered through the Optical Access Networks increase, it is crucial to maintain network good operation and performance. To achieve this, the Optical Access Network monitoring can be improved when compared to existing traditional methods via automated real-time data collection. Telemetry enables this and transmits data from the optical line terminal (OLT) – i.e., the device at the endpoint of a passive optical network – in real-time to provide information to the data collection platform.
With the new ETSI specification ETSI GS F5G-011 defining Telemetry Framework and Requirements for Access Networks, service providers and operators benefit from the advantages of real-time monitoring with scale, speed and automation using telemetry. The data retrieved by telemetry, together with analytics and AI, will ultimately offer end users an optimized quality of experience (QoE) for their fiber to the home (FTTH) network, unlocking the potential of the fifth generation of fixed networks (F5G). Note that F5G is based on fiber access- not wireless/cellular access.
Today, the Access Network deployment is based on a traditional data pulling methods, such as Simple Network Management Protocol (SNMP), syslog and Command-Line Interface (CLI) to pull data from the OLT to monitor Optical Access Network and troubleshoot any issues. The interface uses proprietary management information bases (MIBs) from different OLT equipment vendors, making automation a difficult task. Each request to pull data is therefore resource intensive and impacts the performance of the OLT, adding complexity because there is more than one pull request per OLT. The pulling method does not efficiently scale.
With the flexibility of telemetry, which uses the push method to continuously stream data from the OLT, the data of interest can be selected from the OLT and transmitted it in a structured format to a data collection platform for monitoring, AI-based analytics and visualization.
Telemetry introduces finer granular data points and more frequent data streaming in the Optical Access Network. It enables better performance monitoring and therefore better control over large Access Networks. Telemetry data can assist in the prediction of network problems and take preventative actions without impacting the performance of the OLT. The operators can gain better visibility and insight into the network. They can also enhance the network operational performance by using data analytics.
“Telemetry technology opens the door to big data and machine learning methods application in the Access Network and brings a clear benefit to end users,” outlines Luca Pesando, Chair of the ETSI F5G group which developed this standard. “In the Group Specification, we also showcase examples of implementation of the telemetry system as we recommend it, already at the stage of Proof of Concept so that operators can leverage the potential of this new telemetry architecture,” he adds.
Requirements of F5G QoE (from ETSI GS F5G 005 V1.1.1 (2022-03):
- The F5G network shall support telemetry.
- The F5G network shall support the capability of telemetry to frequently send measured data.
- The F5G network shall support the capability of telemetry to export fine grained statistics.
- The F5G network telemetry interface shall support per-slice QoS measurement data.
- The F5G network shall support end-to-end QoE assessment in the CPN, Access Network, Aggregation Network, and Core Network.
- The F5G network shall support AI-based QoE assessment based on measured network or application performance data.
- The F5G CPN shall provide a mechanism to improve QoE in the customer premises network (residential, enterprise, verticals).
- The F5G service and underlay plane shall support network-layer QoS measurement mechanisms to support QoE assessment and management.
- The F5G service and underlay plane shall support application-layer QoS measurement mechanisms to support QoE assessment and management.
The ETSI F5G Industry Specification Group is working on 10 other specifications and will soon release F5G PON (Passive Optical Networks) for industrial applications and an F5G security architecture. If you’re interested, feel free to join us and contact [email protected]
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 900 member organizations worldwide, drawn from over 60 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 Standardization Organization (ESO). For more information, please visit us at https://www.etsi.org/
Tel.: +33 (0)6 87 60 84 40
Email: [email protected]
ETSI – New ETSI Telemetry Standard Improves Automation for better End-User Quality of Experience
ETSI Experiential Networked Intelligence – Release 2 Explained
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/
Multi-access Edge Computing (MEC) Market, Applications and ETSI MEC Standard-Part I
ETSI MEC Standard Explained – Part II
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):
Multi-access Edge Computing (MEC) Market, Applications and ETSI MEC Standard-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
IHS-Markit Forecast: Carrier NFV at $37B in 2021 for a CAGR of 30% from 2016-2021
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.