Layer 123 Network Transformation Congress: Unlocking 5G Growth Requires New Operating Model
by Johanne Mayer, Director MayerConsult and TM Forum Distinguished Fellow
At the Layer123 Network Transformation Congress in San Jose, CA this week, the discussions predominantly focused on the network technology changes and references to traditional network transformation such as 3G to 4G and the benefits that transforming to 5G would bring.
However I would contend that unlocking growth in 5G requires a new operating model with new processes, automation and actual supplier implementation of standard APIs for Communications Service Providers (CSPs) to achieve the agility and speedier time to market to remain relevant in the new ecosystem which has consequential impact on what they need from their vendors.
CSPs have predominantly packaged and sold products and services direct to customers with every technology, think 2G, 3G, 4G which have included connectivity and often a handset. Looking at 5G and IoT growth from the above figure, it’s highly unlikely that CSPs will package and resell connected cars, or robots for remote robotic surgery, or AR games with headsets, etc.
In addition, with today’s timeframes of 18 to 24 months to get new product to market due to the complexity and touch points between the network equipment and all of the operational and business support systems (OSS/BSS), we need to rethink how we do things for CSPs to stay relevant and profitable.
Traditional OSS and BSS have served us well but with newer cloud, SDN and NFV technologies, the relevance of understanding the relationships (think inventories) between products, services and resources is diminishing, and having to adapt to different APIs for each supplier is slowing CSP’s time to market and adding more cost pressure.
TM Forum has introduced its Open Digital Framework Concept to address CSP’s business challenges including business & IT agility, optimization, digital customer experience and both B2B and B2C growth through a set of core tools and standards along with support and guidance programs.
Of particular interest is the Open Digital Architecture (ODA) which focuses on seamless interactions between functional domains using a rich set of Open APIs which have been released and made available in Open Source (https://www.tmforum.org/open-apis/).
To achieve the seamless integration with 5G ecosystem partners and reduce costly time to market to stay competitive, the interaction and processes between the production and other functional areas need to change. The network needs to expose and fully manage the lifecycle of its set of capabilities as reusable services independent of products and resources.
The temptation today is for product and network engineers to translate the current product/network service into a monolithic network service model. Think NFV 5 years ago where we asked suppliers to place their code on white boxes. They abstracted the code from the current hardware and adapted the same thing on white boxes without taking advantage of micro-service architecture a la NFV2.
Since each product or network engineer selects their own suppliers for their products (e.g. internet security and managed firewall services) each used a firewall but likely from different suppliers. If each product engineering team were to expose their network service model, we would likely have exposure of “internet security” and “managed firewall service” as is (i.e. per early NFV) rather than “Firewall as a Service” micro-service that could be reused in both network services.
A TM Forum NaaS API Component Suite has been created in support of the complete lifecycle operations for each network as a service including service qualification, service configuration and activation, service test, service problem management and service usage. Also the more that product and network engineers can expose in relation to that reusable network service during the design time, the more automation can be developed reducing time to market to deliver products and offers to the market.
Is this too good to be true?
While the telecom industry keeps on saying that CSPs are too slow, it is rich in promoting proprietary APIs claiming that “my APIs are the best”, that standard APIs are not agile enough or that they can’t support “my differentiators” hence each of the OSS/BSS applications (think inventories, product catalogues, orchestrators, alarm management, performance management, SLA, etc.) has to use integration services to create adapters for each supplier, increasing time and costs and adding extra testing. The costs and delays in getting service up and running inherent in this business approach are simply not economically sustainable in the new business opportunities for CSPs.
The good news is that if suppliers don’t expose a service, for example it could be a core router supporting and routing several network services, but that device in itself does not expose a “reusable service” (think firewall or AAA or Eline, etc) then that supplier does not need to support the TM Forum NaaS (Network as a Service) APIs.
Using MEF LSO architecture, the NaaS component suite would fit the Legato interface point.
Conclusions:
As a supplier or CSP, it’s time to think where you want to fit in the new value chain.
I believe that more and more CSPs will start their transformation towards a NaaS architecture, allowing them to expose their network capabilities using standard and open APIs to be consumed seamlessly by their partners and customers.
For further information, the TM Forum is hosting a Network Transformation track at its Digital Transformation World event in Nice, May 14-16th, 2019. https://dtw.tmforum.org
………………………………………………………………………………………………………………………………………………………………………………………………………………………………..
References:
IG1167 ODA Functional Architecture R18.5.1
Global Architecture Forum – Webinar 1 NaaS
From network spaghetti to hyperscale simplicity
http://www.mef.net/lso/lifecycle-service-orchestration
……………………………………………………………………………………
Kindly post comments in the box below this article.
Alan J Weissberger
……………………………………………………………………………………
4 thoughts on “Layer 123 Network Transformation Congress: Unlocking 5G Growth Requires New Operating Model”
Comments are closed.
TM Forum and MEF are working together to automate the lifecycle of services such as carrier Ethernet and software-defined wide area networking (SD-WAN), showing how they can be ordered through a portal and then automatically activated across hybrid networks made up of virtualized and physical components. The idea is to demonstrate orchestration of services across multiple providers and over diverse network technology domains, allowing communications service providers (CSPs) to build automated, model-driven digital ecosystems.
Specifically, the project shows how to implement MEF Lifecycle Service Orchestration (LSO) across multiple operational network domains provided by Ciena, Riverbed and ONAP using an architecture based on the TM Forum Hybrid Infrastructure Platform. DGIT’s Telflow is used as the platform to create a self-service ordering portal with an offer canvas experience.
https://www.tmforum.org/catalysts/automating-network-as-a-service/
5G brings great opportunities but requires a network transformation
According to 451 Research, 12% of network operators expect to roll out 5G services in 2019, and an additional 86 percent expect to be delivering 5G services by 2021, according to a Vetiv survey of more than 100 global telecom decision makers with visibility into 5G and edge strategies and plans.
The “Telco Study Reveals Industry Hopes and Fears: From Energy Costs to Edge Computing Transformation” research covers 5G deployment plans, services supported by early deployments, and the most important technical enablers for 5G success.
According to the survey, those initial services will be focused on supporting existing data services (96 percent) and new consumer services (36 percent). About one-third of respondents (32 percent) expect to support existing enterprise services with 18 percent saying they expect to deliver new enterprise services.
As networks continue to evolve and coverage expands, 5G itself will become a key enabler of emerging edge use cases that require high-bandwidth, low latency data transmission, such as virtual and augmented reality, digital healthcare, and smart homes, buildings, factories and cities.
However, illustrating the scale of the challenge, the majority of respondents (68 percent) do not expect to achieve total 5G coverage until 2028 or later. Twenty-eight percent expect to have total coverage by 2027 while only 4 percent expect to have total coverage by 2025.
“While telcos recognize the opportunity 5G presents, they also understand the network transformation required to support 5G services,” said Martin Olsen, vice president of global edge and integrated solutions at Vertiv.
“This report brings clarity to the challenges they face and reinforces the role innovative, energy-efficient network infrastructure will play in enabling 5G to realize its potential.”
To support 5G services, telcos are ramping up the deployment of multi-access edge computing (MEC) sites, which bring the capabilities of the cloud directly to the radio access network. Thirty-seven percent of respondents said they are already deploying MEC infrastructure ahead of 5G deployments while an additional 47 percent intend to deploy MECs.
As these new computing locations supporting 5G come online, the ability to remotely monitor and manage increasingly dense networks becomes more critical to maintaining profitability. In the area of remote management, data center infrastructure management (DCIM) was identified as the most important enabler (55 percent), followed by energy management (49 percent).
Remote management will be critical, as the report suggests the network densification required for 5G could require operators to double the number of radio access locations around the globe in the next 10-15 years.
The survey also asked respondents to identify their plans for dealing with energy issues today and five years in the future when large portions of the network will be supporting 5G, which 94 percent of participants expect to increase network energy consumption. Among the key findings:
Reducing AC to DC conversions will continue to be an area of emphasis, with 79 percent of respondents saying this is a focus today and 85 percent saying it will be a focus five years from now.
New cooling techniques will see the biggest jump in adoption over the next five years. Currently being used by 43 percent of telcos worldwide, this number is expected to increase to 73 percent in five years.
Upgrades from VRLA to lithium-ion batteries also show significant growth. Currently, 66 percent of telcos are upgrading their batteries. Five years from now, that number is projected to jump to 81 percent.
“5G represents the most impactful and difficult network upgrade ever faced by the telecom industry,” said Brian Partridge, research vice president for 451 Research.
“In general, the industry recognizes the scale of this challenge and the need for enabling technologies and services to help it maintain profitability by more efficiently managing increasingly distributed networks and mitigating the impact of higher energy costs.”
https://www.helpnetsecurity.com/2019/05/01/5g-deployment-plans/
Cloud, 5G and Industry 4.0 initiatives all create huge disruption for CSP’s (Communications Service Providers), which cover the entire life cycle of both products and services. In particular, how new services will be modeled and how they will be consumed (which is very different than the old legacy services previously provided by CSPs).
These urgent new requirements may force CSP’s to evolve to NaaS [or Network as a service] offering with clear expectations that each component will expose services as an API. However, as we cherish some early success with TM Forum NaaS initiatives we find major vendors are not aligned with it or at least there road maps do not reflect it.
It seems like current architecture simplification and value up the stack with out solving spaghetti issue on south bound . For example if we need create a new Product offering who will do the mapping between CFS (Customer facing service) to RFS (Resource Facing Service) since NaaS shifts this role to Service Orchestration on south bound so it is very important this relation is open and modular and can be done by CSP in most simple manner . This means we need to either ensure Orchestration solutions cater these requirements or we introduce an additional open pluggable solutions that can complete this stuff . Nevertheless NaaS initiative is very important for CSP ambitions to become a pure DSP (Digital Service Providers) and this is direction sooner or later all carriers need to adopt.
It is often a pain in the ass to reaԁ ԝhat bloggers write, because there is no corroboration of their claims. However, the IEEE Techblog is objective, balanced, accurate and user friendly. Thanks for your hard work to maintain this website!