FYUZ 2023 review and opinions on latest Open RAN announcements

 

Last week marked the second edition of FYUZ, the Telecom Infra Project's annual celebration of open and disaggregated networks. TIP's activity, throughout the year, provides a space for innovation and collaboration in telecoms network access, transport and core main domains. The working groups create deployment blueprints as well as implementation guidelines and documentation. The organization also federates a number of open labs, facilitating interoperability, conformance and performance testing.

I was not there are for the show's first edition, last year, but found a lot of valuable insight in this year's. I understand from casual discussion with participants that this year was a little smaller than last, probably due to the fact that the previous edition saw Meta presenting its Metaverse ready networks strategy, which attracted a lot of people outside the traditional telco realm. AT about 1200 attendees, the show felt busy without being overwhelming and the mix of main stage conference content in the morning  and breakout presentations in the afternoon left ample time for sampling the top notch food and browsing the booth. What I found very different in that show also, was how approachable and relaxed attendees were, which allowed for productive and yet casual discussions.

Even before FYUZ, the previous incarnation of the show, the TIP forum was a landmark show for vendors and operators announcing their progress on open and disaggregated networks, particularly around open RAN.

The news that came out of the show this year marked an interesting progress in the technology's implementation, and a possible transition from the trough of disillusion to a pragmatic implementation.

The first day saw big announcements from Santiago Tenorio, TIP's chairman and head of Open RAN at Vodafone. The operator announced that Open RAN's evaluation and pilots were progressing well and that it would, in its next global RFQ for RAN refresh, affecting over 125,000 cell sites see Open RAN gain at least 30% of the planned deployment. The RFQ is due to be released this year for selection in early 2024, as their contracts with existing vendors are due to expire in April 2025.

That same day, Ericsson’s head of networks, Fredrik Jejdling, confirmed the company's support of Open RAN announced earlier this year. You might have read my perspective on Ericsson's stance on Open RAN, the presentation did not change my opinion, but it is a good progress for the industry that the RAN market leader is now officially supporting the technology, albeit with some caveats.

Nokia, on their side announced a 5G Open RAN pilot with Vodafone in Italy, and another pilot successfully completed in Romania, on a cluster of Open RAN sites shared by Orange and Vodafone (MOCN).

While TIP is a traditional conduit for the big 5 European operators to enact their Open RAN strategy, this year saw an event dominated by Vodafone, with a somewhat subdued presence from Deutsche Telekom, Telefonica, Orange and TIM. Rakuten Symphony was notable by its absence, as well as Samsung.

The subsequent days saw less prominent announcements, but good representation and panel participation from Open RAN supporters and vendors. Particularly, Mavenir and Juniper networks were fairly vocal about late Open RAN joiners who do not really seem to embrace multivendor competition and open API / interfaces approach.

I was fortunate to be on a few panels, notably on the main stage to discuss RAN intelligence progress, particularly around the RICs and Apps emergence as orchestration and automation engines for the RAN.

I also presented the findings of my report on the topic, presentation below and moderated a panel on overcoming automation challenges in telecom networks with CI/CD/CT.

NEC MWC 21 Headlines

Whether you were unable to physically go to Mobile World Congress, or were too busy to catch all the announcements, I figured I would put together a brief overview of what we announced this year.

This is also an excellent explanation to those who have been asking what decided me to come work for NEC. If you read the following, I think you will get a good idea.

Besides working with amazing teams and very smart people, what drawn me to NEC is the continuation of innovation and deployment of open and disaggregated networks I started as an independent analyst at {Core Analysis}, as an executive at Telefonica and as an advisor at Bell Canada.

Our first big announcement was from Vodafone UK, selecting NEC for deployment of our 5G Massive MIMO radio units in the UK. It was promptly followed by Deutsche Telekom announcing NEC 5G open RAN mMIMO in Germany. NEC is proving once again its market leadership in Open RAN with the deployment of Radio Units in dense urban environments at commercial scale. Many vendors have massive MIMO technology, some vendors are Open RAN, we are the first and the only one to have deployed massive MIMO Open RAN in urban networks. This will change and we welcome the competition for this market to grow.

As Open RAN becomes mainstream, the opportunity for cost savings and new savings relies on the optimization of virtual resources. This selection of NEC by NTT DOCOMO to develop their Radio Intelligent Controller (RIC) is another testament of our innovation and pioneering spirit.

To grow, the Open RAN market needs many different configurations, to offer connectivity products for all kinds of environments (public, private, urban, rural, industrial, government...). We did our part announcing 3 new massive MIMO open RAN RUs.

NEC is focusing on providing RUs that are high performance high quality and completely open. We share this philosophy with MTI and that is why we are proud to have announced a strategic partnership with them.

The other important part of Open RAN is the software. NEC has been recognized as a leading solutions integrator of third parties in that space and will continue to do so, but in complement has announced the launch of of its own cloud native high performance open RAN software offering. 5G success depends on a rich ecosystem and an abundance of vendors.

Shifting from Open RAN, 5G's success will be realized through the capacity to create connectivity products that are adapted to the different use cases. A key element for this a core network that is cloud native, capable of being deployed in public or private clouds and that is blazingly fast. We are proud to announce the world fastest 5G Core network deployed in Rakuten's mobile network, in collaboration with Intel. At the same time, we showed off our deployment together with Netcracker on AWS cloud.

Private and enterprise networks are an important part of 5G and we announced our collaboration with NTT data to promote solutions to accelerate its adoption.

By now, you probably understand why I am so humbled to have been invited to join NEC and to support all these products and teams. It is a great privilege to be able to continue contributing to an open, disaggregated, high performance 5G. More to come soon, stay tuned!

The telco multi core

TobiasD / Pixabay

 
There is something that has been irking me for the last few months: everyone in telco seems to carry on thinking that they will continue have a single omnipotent centralized core network. Even though variations between workloads (voice vs browsing vs video vs gaming vs AR vs AI vs IoT...) continue to amplify and the business models (owned, and operated, IaaS, SaaS, PaaS...) increasingly require separate command and control.

The answer seems to be that slicing will magically solve everything. I fail to understand how slicing can accommodate diverging simultaneous needs from the same infrastructure without overprovisioning but that's a question for another time.

What troubles me most, is that networks have dealt with separate cores for a long time. In many cases, because of IoT or B2B business units who could not afford the timelines and costs of adapting the centralized core, or because, simply the network authority wanted to separate consumer traffic from enterprises. In other cases, you have network sharing and multi-operator core networks (MOCN) that have emerged as viable solution to segregate and manage traffic in a logical network.

I am not an engineer or a scientist, but it feels like the most advancement in processing in the last years is due to parallelization or specialization, and I don't see silicon vendors building bigger CPUs, but rather orchestrating as many CPUs on the same board as possible to manage concurrent, yet different workloads. This analogy has also seen the emergence of specialized processing units such as GPU or TPUs for specific workloads, in specific circumstances...

Now that most cloud providers and many telco vendors have proven the compatibility of their core network (at least the control plane) with cloud infrastructure and networks, I don't understand why telco standards and industry still feel that 5G will have THE core network to evolve to, and that, when, it will be 5G, when it will be standalone, when it will support slicing, when it will have a platform to recognize, identify, reserve, network resources, when it will be able to create dynamic slices on demand... all will be solved.

I feel that many of these issues have been resolved yet? Slicing is just a new iteration of tunneling, VPN, packet tagging, traffic shaping that are today prevalent in many networks. Cloud providers have effectively solved most of these challenges within their networks already so why are telcos trying to reinvent the wheel? 

Wishing a single, unique, centralized core is not necessarily going to make it so. Other telcos, cloud providers, soon industry verticals, governments, IT vendors will have their core. Thinking that the telco single core architecture will be able to manage all workloads and use cases and verticals simultaneously in a 5G world seems too much like magical thinking.

If you're a telco, you might not like it but you better plan for a multi core network, because others will be soon, whether you want it or not. Chances are there are already premises in the third party caches and edge infrastructure being deployed in your networks.

You might want to start thinking in terms of core per service types, like voice, unicast TV, general browsing, low latency IoT, high compute applications, Edge... and per business model like retail consumer, retail enterprise, wholesale telco, wholesale cloud, IaaS, PaaS...

Telco grade or Cloud grade?

 

For as long as I can remember, working in Telco, there has been the assumption that Telco networks were special. 

They are regulated, they are critical infrastructure, they require a level of engineering and control that goes beyond traditional IT. This has often been the reason why some technologies and vendors haven't been that successful in that space, despite having stellar records in other equally (more?) demanding industries such as energy, finance, space, defence...

Being Telco grade, when I cut my teeth as a telco supplier, meant high availability (5x9's), scalability and performance (100's of millions of simultaneous streams, connections, calls, ...), security, achieved with multiple vertical and horizontal redundancies, and deployed of highly specialized appliances.

Along comes the Cloud, with its fancy economics, underpinned by separation of hardware and software, virtualization, then decomposition, then disaggregation of software elements into microservices. Add to it some control / user plane separation, centralized control, management, configuration, deployment, roll out, scalability rules... a little decentralized telemetry and systematic automation through radical opening of API between layers... That's the recipe for Cloud grade networks.

At the beginning, the Telco-natives looked at these upstarters with a little disdain, "that's good for web traffic. If a request fail, you just retry, it will never be enough for Telco grade...". 

Then with some interest "maybe we can use that Cloud stuff for low networking, low compute stuff like databases, inventory management... It's not going to enable real telco grade stuff, but maybe there is some savings".

Then, more seriously "we need to harness the benefits of the cloud for ourselves. We need to build a Telco cloud". This is about the time the seminal white paper on Telco virtualization launched NFV and a flurry of activities to take IT designed cloud fabric (read Openstack) and make it Telco grade (read pay traditional Telco vendors who have never developed or deployed a cloud fabric at scale and make proprietary branches of an open source project hardened with memorable features such as DPDK SR-IOV, CPU pinning so that the porting of their proprietary software on hypervisor does not die under the performance SLA...). 

Fast forward a few years, orchestration and automation become the latest targets, and a zoo of competing proprietary-turned-open-source projects start to emerge, whereas large communities of traditional telco vendors are invited to contribute charitably time and code on behalf of Telcos for projects that they have no interest in developing or selling.

In the meantime, Cloud grade has grown in coverage, capacity, ecosystem, revenues, use cases, flexibility, availability, scalability... by almost any metrics you can imagine, while reducing costs and prices. Additionally, we are seeing new "cloud native" vendors emerge with Telco products that are very close to the Telco grade ideal in terms of performance, availability, scalability, at a fraction of the cost of the Telco-natives. Telco functions that the Telco-native swore could never find their way to the cloud are being deployed there, for security, connectivity, core networks, even RAN...

I think it is about time that the Telco-natives accept and embrace that it is probably faster, more cost efficient and more scalable to take a Cloud-native function and make it Telco-grade than trying to take the whole legacy Telco network and trying to make it Cloud grade. It doesn't mean to throw away all the legacy investment, but at least to consider sunsetting strategy and cap and grow. Of course, it means also being comfortable with the fact that the current dependencies of traditional Telco vendors might have to be traded for dependencies on hyperscalers, who might, or not become competitors down the line. Not engaging with them, si not going to change that fact. 5G stand alone, Open RAN or MEC are probably good places to start, because they are greenfield. This is where the smart money is these days, as entry strategy into Telco world goes...

Why Telcos need Open Core Surgery

 (This article was initially published in Light Reading)

At Mobile World Congress, TIP (the Telecom Infra Project, an industry forum created by Facebook and a number of leading telco operators and IT vendors), announced the creation of a new project group called Open Core Network. Details have starting to emerge last week, with a webinar.

The ambitious target of the group is to define and develop an open and disaggregated 4G Evolved Packet Core and 5G Core for wireless, wired, Wi-Fi on a variety of use cases.

We have seen in the recent past that various attempts to open up the telco cloud ecosystem and value chain have had contrasted results.

• Telco clouds, based on VNFs and Openstack-like virtualization layer have mostly failed to reach critical mass in deployment and usability.
•  ETSI-defined orchestration efforts based on open source projects such as OSM (Open Source Mano) and ONAP (Open Network Automation Platform) have been a work in progress and have equally, to date, failed to become automated telco networks app stores.
• TIP has been successful with the definition, launch and deployment of Open RAN. We have recently seen announcements from Altiostar, Nokia and Cisco in Rakuten's network, as well as from Mavenir in Idea and DISH networks.

As we know, these efforts are aimed at disrupting the current telecom infrastructure provider cost structure by disaggregating traditional networks.

First by separating hardware from software, so that the solutions can be deployed in white boxes - Commercial Off The Shelf (COTS) hardware - rather than costly proprietary ones.

Second by breaking telecom functions into software elements that can be deployed, managed and sourced independently from each other. This is key in the sense that it allows new vendors to enter the ecosystem, who can specialize in specific elements rather than end-to-end solutions. This increases competition and allow a more flexible sourcing strategy, with either best-of-breed vendors for each elements or selection of vendors for fit-for-purpose use cases deployments. The key to enable this scenario is an architecture that is accepted by all, with well-defined software elements functions and more importantly, open, standard, rigid interfaces that guarantee that one vendor can be substituted by another without undue integration effort.

5G is supposed to be the first telco cloud network that is natively virtualized, software-defined, elastic and automated at scale. This can be achieved today by deploying a single vendor solution from one of the dominant telco vendors. Things start to complicate vastly if one wants to deploy a multi-vendor network. Since the standards are not quite finalized on some of the elements and behaviour of a 5G network and operators are announcing and launching 5G networks nonetheless, vendors have to fill the gaps with proprietary implementations, and extensions to the standards to make their end-to-end solution automated, software defined and elastic.

One last bastion of telco proprietary implementation is the Core network. The Core network is basically the brain of the telco network. All the consumer data is stored there, all the charging systems reside there, all the elements to decide where traffic should go and how it should be treated live in the Core. This brain is very complex and composed of a number of elements that have, until now, usually been sold and deployed from single vendors. This has long been a trojan horse for dominant telco vendors to control a network. It is also a self-perpetuating decision, as the evolution from one standard version to another or from one generation to another is much more cost effective as an upgrade of the current vendor's solution as opposed to a rip and replace by a new vendor. 

With 5G, the traditional vendors had a few different architectural options for Core deployment and they mostly elected a non-standalone (NSA) version, which can only be deployed as an upgrade to the 4G EPC. It essentially guarantees that a current 4G Core deployment will evolve to 5G with the same vendor, perpetuating the control over the network. This does not only affect the Core network, it also affects the Radio Access Network (RAN), as its implementation, in the early stage of 5G is dependent on an harmonious interworking with the Core. As a result, many traditional Core vendors who are also RAN vendors have created a situation where the only practical and economical way for an operator to launch 5G fast is to deploy Core and RAN from that same vendor. This situation perpetuates the oligopoly in telco supply chain, which reduces innovation and increase costs.

TIP's Open Core is an attempt to create a Core network for 4G and 5G that will be open, composed of software elements that will be provided by independent vendors, all using the same open interfaces to allow low-touch integration and increase the rate of innovation. If the group follows the same path as Open RAN, it could become a major disruption in telco networks, enabling for the first time in decades the possible deployment of a full telco network from a rich ecosystem of vendors and an innovation pace in sync with what we have seen from the hyperscaler world.

This and more in my upcoming report on telco edge and hybrid cloud networks.