Showing posts with label virtualization. Show all posts
Showing posts with label virtualization. Show all posts

Wednesday, September 10, 2025

The 6G promise

As I attend TMForum Innovate Americas in Dallas, AI, automation and autonomous networks dominate the debates. I have long held the belief that the promise of 5G to deliver adapted connectivity to different organizations, industries, verticals and market segment was necessary for network operators to create sustainable differentiation. At Telefonica, nearly 10 years ago, I was positing that network slicing would only be useful if we were able to deliver hundreds or thousands or slices.

One of the key insights came from interactions with customers in the automotive, banking and manufacturing industries. The CIOs from these large organizations don’t want to be sold connectivity products. They don’t want the network operator to create and configure the connectivity experience. 

The CIOs from Mercedes, Ford, Magna know better what their connectivity needs are and what kind of slices would be useful than the network operators serving them. They don’t want to have to spend time educating their providers so that they can design a service for them. They don’t want to outsource the optimization of their connectivity to a third party who doesn’t understand their evolving needs. 

The growth in private networks implementations in healthcare, energy, mining, transportation and ports for instance, is a sign that there is demand in dedicated, customized connectivity products. It is also a sign that network operators have failed so far to build the slicing infrastructure and capacity to serve these use cases.

As a result, I proposed that network operators should focus on creating a platform for industries to discover, configure and consume connectivity services. This vision had a lot of prerequisites. Networks need to evolve and adopt network virtualization through separation of hardware and software, cloud native functions, centralized orchestration, stand-alone core, network slicing, the building of the platform and API exposure

A lot of progress has been made in all these categories, to the point that we see emerging the first dedicated slicing solutions for first responders, defense and industries. These slices are still mostly statically provisioned and managed by the network operators, but they will gradually grow. 

The largest issue for evolving from static to dynamic slicing and therefore moving from network operated to as a service user configurable is managing conflicts between the slices. Dedicating static capacity for each slice is inefficient and too cost prohibitive to implement at scale except for the largest governmental use cases. Dynamic slicing creation and management requires network observability, jointly with near real time capacity prediction, reservation, and attribution. 

This is where AI can provide the missing step to enable dynamic slicing for network as a service. If you can extract data from the user device, network telemetry and functions fast enough to be made available to algorithms for pattern identification in near real time, you can identify the device, user, industry, service and create the best fit connectivity, whether for a gaming console connected to a 4K TV in FWA, a business user on a video conference call, industrial collaborating robots assembling a vehicle, or a drone delivering a package.

All these use cases have different connectivity needs that are today either served by best effort undifferentiated connectivity or rigidly rule-based private networks. 

As 6G is starting to emerge, will it fulfil the 5G promises and deliver curated connectivity experiences?

Monday, November 13, 2023

RAN Intelligence leaders 2023


RAN intelligence is an emerging market segment composed of RAN Intelligent Controllers (RICs) and their associated Apps. I have been researching this field for the last two years and after an exhaustive analysis of the vendors and operators offerings and strategies, I am glad to publish here an extract of my findings. A complete review of the findings and rankings can be found through the associated report or workshop (commercial products).

The companies who participated in this study are AccelleRAN, AIRA, Airhop, Airspan, Cap Gemini, Cohere Technologies, Ericsson, Fujitsu, I-S Wireless, Juniper, Mavenir, Nokia, Northeastern. NTT Docomo, Parallel Wireless, Radisys, Rakuten Symphony, Rimedo Labs, Samsung, Viavi, VMWare.

They were separated in two overall categories:

  • Generalists: companies offering both RIC(s) and Apps implementations
  • Specialists: companies offering only Apps

The Generalist ranking is:



#1 Mavenir
#2 ex aequo Juniper and vmware
#4 Cap Gemini



The Specialists ranking is:



#1 Airhop
#2 Rimedo Labs
#3 Cohere Technologies



The study features a review of a variety of established and emerging vendors in the RAN space. RAN intelligence is composed of:

  • Non Real Time RIC - a platform for RIC intelligence necessitating more than 1 second to process and create feedback loops to the underlying infrastructure. This platform is an evolution of SON (Self Organizing Networks) systems, RAN EMS (Element Management Systems) and OSS (Operations Support Systems). The Non RT RIC is part of the larger SMO (Service Management and Orchestration) framework.
  • rApps -  Applications built on top of the Non RT RIC platform.
  • Near Real Time RIC - a platform for RIC intelligence necessitating less than 1 second to process and create feedback loops to the underlying infrastructure. This platform is a collection of capabilities today embedded within the RUs (Radio Units), DUs (Distributed Units) and CUs (Centralized Units).
  • xApps - Applications built on top of the Near RT RIC platform.
The vendors and operators were ranked on their strategy, vision and implementation across six dimensions, based on primary research from interviews, publicly available information, Plugfests participation and deployments observation:
  • Platform - the ability to create a platform and a collection of processes facilitating the developers' capability to create Apps that can be ported from one vendor to the other with minimum adaptation. Considerations were given to Apps lifecycle management, maturity of APIs / SDK, capability to create enabling apps / processes for hosted Apps.
  • Integrations / partnerships - one of the key tenets of Open RAN is the multi vendor or vendor agnostic implementation. From this perspective, companies that gave demonstrated their integration capabilities in multi vendor environments of the hosting of third party applications were ranked higher.
  • Non Real Time RIC - ranking the vision, implementation and maturity of the Non RT RIC capabilities.
  • Near Real Time RIC - ranking the vision, implementation and maturity of the Near RT RIC capabilities.
  • rApps - ranking the vision, implementation and maturity of the rApps offering
  • xApps - ranking the vision, implementation and maturity of the xApps offering

Friday, September 18, 2020

Rakuten: the Cloud Native Telco Network

Traditionally, telco network operators have only collaborated in very specific environments; namely standardization and regulatory bodies such as 3GPP, ITU, GSMA...

There are a few examples of partnerships such as Bridge Alliance or BuyIn mostly for procurement purposes. When it comes to technology, integration, product and services development, examples have been rare of one carrier buying another's technology and deploying it in their networks.

It is not so surprising, if we look at how, in many cases, we have seen operators use their venture capital arm to invest in startups that end up rarely being used in their own networks. One has to think that using another operator's technology poses even more challenges.

Open source and network disaggregation, with associations like Facebook's Telecom Infra Project, the Open Networking Foundation (ONF) or the Linux Foundation O-RAN alliance have somewhat changed the nature of the discussions between operators.

It is well understood that the current oligopolistic situation in terms of telco networks suppliers is not sustainable in terms of long term innovation and cost structure. The wound is somewhat self-inflicted, having forced vendors to merge and acquire one another in order to be able to sustain the scale and financial burden of surviving 2+ years procurement processes with drastic SLAs and penalties.

Recently, these trends have started to coalesce, with a renewed interest for operators to start opening up the delivery chain for technology vendors (see open RAN) and willingness to collaborate and jointly explore technology development and productization paths (see some of my efforts at Telefonica with Deutsche Telekom and AT&T on network disaggregation).

At the same time, hyperscalers, unencumbered by regulatory and standardization purview have been able to achieve global scale and dominance in cloud technology and infrastructure. With the recent announcements by AWS, Microsoft and Google, we can see that there is interest and pressure to help network operators achieving cloud nativeness by adopting the hyperscalers models, infrastructure and fabric.

Some operators might feel this is a welcome development (see Telefonica O2 Germany announcing the deployment of Ericsson's packet core on AWS) for specific use cases and competitive environments. 

Many, at the same time are starting to feel the pressure to realize their cloud native ambition but without hyperscalers' help or intervention. I have written many times about how telco cloud networks and their components (Openstack, MANO, ...) have, in my mind, failed to reach that objective. 

One possible guiding light in this industry over the last couple of years has been Rakuten's effort to create, from the ground up, a cloud native telco infrastructure that is able to scale and behave as a cloud, while providing the proverbial telco grade capacity and availability of a traditional network. Many doubted that it could be done - after all, the premise behind building telco clouds in the first place was that public cloud could never be telco grade.

It is now time to accept that it is possible and beneficial to develop telco functions in a cloud native environment.

Rakuten's network demonstrates that it is possible to blend traditional and innovative vendors from the telco and cloud environments to produce a cloud native telco network. The skeptics will say that Rakuten has the luxury of a greenfield network, and that much of its choices would be much harder in a brownfield environment.




The reality is that whether in the radio, the access, or the core, in OSS or BSS, there are vendors now offering cloud native solutions that can be deployed at scale with telco-grade performance. The reality as well is that no all functions and not all elements are cloud native ready. 

Rakuten has taken the pragmatic approach to select from what is available and mature today, identifying gaps with their ideal end state and taking decisive actions to bridge the gaps in future phases.




Between the investment in Altiostar, the acquisition of Innoeye and the joint development of a cloud native 5G Stand Alone Core with NEC, Rakuten has demonstrated vision clarity, execution and commitment to not only be the first cloud native telco, but also to be the premier cloud native telco supplier with its Rakuten Mobile Platform. The latest announcement of a MoU with Telefonica could be a strong market signal that carrieres are ready to collaborate with other carriers in a whole new way.


Friday, July 31, 2020

Objectives of xRAN


The primary objective of xRAN was to change the cost of designing, purchasing and operating Radio Access Networks. This can be achieved by a variety of means:

Software virtualization

Traditional RAN vendors provide integrated proprietary hardware and software solutions for their equipment. Separating the hardware from the software, and virtualizing the latter yields a variety of benefits:
Part of the hardware can now be purchased commercial off the shelf, based on cost efficient white box designs.
Virtualized software is able to make full use of Software Defined Networking (SDN). When a software is virtualized using virtual machines, we use virtual bridges to connect the VMs with the physical servers. We use virtual switches such as OVS to optimize the servers utilization. Cables and physical switches are used to connect physical servers between each other. Hyperscalers have, early on identified that white box switches can be deployed at a fraction of the cost of the proprietary switches used in telco networks. It is very difficult, in practice to orchestrate VMs that are not on the same servers, as well as VMs with the physical servers’ capacity.
In a software-defined network, the decision-making processes for the categorization, management and routing of IP traffic is separated from the software functions and centralized in the form of a Controller. That Controller can expose (northbound) interfaces to define the rules for traffic handling and (southbound) interfaces to program the traffic management elements. This enables to create sophisticated traffic rules to optimize for performance, latency, congestion or failure avoidance. When applied to the RAN, SD RAN is sometimes used to describe these systems.
A SD RAN can be managed remotely, from a controller API on a web interface, rather than dialing into each network element separately, either remotely of physically. This yields operational savings inasmuch as less in-the-field maintenance is necessary and technicians do not need to physically access the equipment to perform upgrades, patches and maintenance.

 Open interfaces and solution disaggregation

RANs are composed of a variety of elements that are tightly integrated in a traditional solution. The interfaces and protocols linking these elements are closed, which means that only the vendor of the solution can perform a change because even if they are using standards based interfaces, they augment them with proprietary parameters and headers.. Opening these interfaces means designing, specifying and enforcing the implementation of standards-based interfaces between these elements without any modification. This yields a variety of benefits:
  •      These elements can be scaled independently from each other.
  •      Since the interfaces are open, you can replace an element from one vendor by one from another vendor with minimum testing and integration.
  •        It is possible to deploy elements from different vendors in the same network configuration, allowing best of breed deployment for specific use cases

Value chain disaggregation

A key means to reduce the cost structure of the traditional RAN value chain is to reduce the dependency on powerful vendors. This can be achieved by breaking the RAN products and services into modular components and essentially go directly to the Original Design Manufacturer (ODM) to try and get better commercial conditions. This tactic is not always effective. These ODM might be eager to get closer to the end customer and shortening the intermediary, but they are usually weary as well to discontent their current customers (OEMs) with whom they have long term relationship and volume commitments. Additionally, the traditional vendors provide valuable design, integration and testing work which now has to be carried by the operator or their new subcontractors.
A better solution is to try and stimulate the market to see the emergence of new suppliers to challenge the supremacy of the traditional vendors. This can be achieved in a variety of ways. Many operators have an investment arm or an incubator or accelerator for start ups. A telecom operator entering a technology company’s capital as a strategic investor is a good signal to the market. When several operators invest in companies in the same market segment, it shows that it is strategic and forces other venture capital companies to evaluate whether they should invest in similar companies. It spurs, in turn, entrepreneurs to create start ups in that area. It is a difficult virtuous circle to create and takes time, but it is powerful once it has sufficient momentum.
Another tactic is the in-house development of a new solution, together with the creation of an open source community. The seed development does not need to be huge, but it needs to show steadfast and long-term commitment to developer community for interested parties to adhere to the project. Open source development can become a force multiplier as start-ups emerge to industrialize and resell the shared code.
The last tactic, and probably the most effective, is the purchase and deployment of these new vendors products and services. Telco operators are notoriously slow to take purchasing decisions and the sales engagement is a marathon, from presentations, to demonstrations, to proof of concept, to lab deployment, to integration tests and hundreds other processes before deployment in the field. It is not surprising therefore, that the best suited vendors are those with robust project / program management and deep pockets, able to sustain long sales cycle by their market reach and scale. Start-ups are usually ill-equipped to sell to large operators and more of them have died during the sales cycle than have emerged successful. There is nothing like focus and the ability to test, refine and purchase volumes of start ups products and services in a short timeframe to signal to the market that an operator is serious about it.
All these tactics combined have seen the emergence of a class of RAN suppliers, smaller, more agile, more efficient than their traditional counterparts. They certainly have a higher risk profile, as they are not as financially sustainable and haven’t reached the operational excellence operators demand in their market, but the cost-ratio with their counterpart is sufficiently important that some operators feel these vendors are good enough for specific use cases.
The introduction of these new vendors in the value chain, with their lower price points and their more open interfaces forces the traditional vendors to adapt their offering, by compressing their margins and / or developing equivalent product lines.

Sunday, February 23, 2020

Telco growth: my objectives, vision, tactics, doctrine at Telefonica




As mentioned in my previous post, telco transformation through innovation and connectivity control requires a strong framework to guide the decision-making process. Here is a list of objectives, vision, strategies, tactics and doctrines that guided me through my time at Telefonica. I believe they can be adapted to many operators’ situation and organization to generate value through successful launch of new connectivity products.

Objectives:

  • Fast creation of new products and services by systematically leveraging economies of scale, reusing modular technical solutions and automation.
  • Creation of a toolbox of technological tools, operating models, best practices, documentation, blueprints, tests and certified solutions...
  • Deliver complete products, not just technology, but also operating model, suppliers value chain and devops teams...
  • Facilitate the transition from innovation to business
  • Systematically evaluate new technologies, suppliers in the laboratory and in the field
  • Fulfill our ambition to transform the industry


Vision:

Create a sustainable commercial growth factory for the company through the systematic research, implementation of services and products that achieve strategic, tactical, commercial, and technological advantages based on the network such as infrastructure or connectivity as a service.

Strategies:

  • Explore and classify services, market trends, competitive and direct and indirect movements and their technological evolution to identify risks and opportunities to create/destroy value for the company based on the network as infrastructure or connectivity as a service.
  • Creation or integration of network and IT technologies to disaggregate and control the cost structure of the purchase, implementation and deployment of connectivity functions and services.
  • Choice and implementation of disruptive connectivity services, products or businesses by designing the E2E value chain
  • Transfer of technological parts, services, products to commercial teams ready for production
  • Systematic identification of differential competitive advantages for the company and strategies to achieve their implementation
  • Implementation of innovative work and development methodologies, especially aimed at creating a DevOps/continuous development/continuous testing model for network technologies and connectivity services


Tactics:

  • Systematic disaggregation of high-level commercial systems and products of network and IT integration to identify manufacturers, intermediaries, sources of savings and their organizational and process impact
  •  Systematic prioritization of open source for MVPs, to learn the state of the art, limitations and development and integration needs
  • Projects, products, technology parts delivered with operating model, manufacturers / integrators / ecosystem developers
  • Identification and implementation of critical paths to deliver to the customer as fast as possible (MVPs, early prototypes deployed in commercial networks)


Doctrine:

  • Customer first
    • Development of services, projects, products with priority to the voice of the customer and the business over technology
  • One size does NOT fit all
    • Resist the model of trying to implement the same technology, solution, manufacturer for all parts of the network and all situations. Specification, design and development of technological and commercial solutions that are infinitely modular. Nothing monolithic, so that we can adapt the solutions to the realities of each market / segment
  • Always open
    • Technological development based on open models (APIs, standard and published interfaces, ...)
    • Open Source, wherever possible
    • Multi manufacturer and no lock-in by design
  • Modular, serverless when possible > micro services > containers > VMs > VNFs > PNF
  • Availability, generosity, active collaboration with commercial teams, third parties and transparency of communication
  • Systematic use from the design of
    • Data science
    • UX
    • Security
  • Agility, speed and results
  • Planning, development, iteration, continuous deliveries
  • Hypotheses, design, development, testing, ... Repeat
  • Pivot fast
  • Take calculated risks
  • Stop activities that fail to meet objectives
  • Organizational flexibility for team members to have diverse and multi-project responsibilities, and can also change during the life cycle of each project
  • Self-management and organizational structures with minimal hierarchy
  • Simple and cheap
  • Systematic simplification of legacy
  • Good enough, cheap > >  over engineered and expensive
  • DevOps
  • Continuous development



If you would like more details, feel free to reach out, I have developed an innovation / transformation workshop to put in practice some of these strategies.
Also available: