June 2024 Open RAN requirements from Vodafone, Telefonica, Deutsche Telekom, Tim and Orange

 As is now customary, the "big 5" European operators behind open RAN release their updated requirements to the market, indicating to vendors where they should direct their roadmaps to have the most chances to be selected in these networks.

As per previous iterations, I find it useful to compare and contrast the unanimous and highest priority requirements as indications of market maturity and directions. Here is my read on this year's release:

Scenarios:

As per last year, the big 5 unanimously require support for O-RU and vDU/CU with open front haul interface on site for macro deployments. This indicates that although the desire is to move to a disaggregated implementation, with vDU / CU potentially moving to the edge or the cloud, all the operators are not fully ready for these scenario and prioritize first a deployment like for like of a traditional gnodeB with a disaggregated virtualized version, but all at the cell site. 

Moving to the high priority scenarios requested by a majority of operators, vDU/vCU in a remote site with O-RU on site makes its appearance, together for RAN sharing. Both MORAN and MOCN scenarios are desirable, the former with shared O-RU and dedicated vDU/vCU and the latter with shared O-RU, vDU and optionally vCU. In all cases, RAN sharing management interface is to be implemented to allow host and guest operators to manage their RAN resource independently.

Additional high priority requirements are the support for indoor and outdoor small cells. Indoor sharing O-RU and vDU/vCU in multi operator environments, outdoors with single operator with O-RU and vDU either co-located on site or fully integrated with Higher Layer Split. The last high priority requirement is for 2G /3G support, without indication of architecture.

Security:

The security requirements are sensibly the same as last year, freely adopting 3GPP requirements for Open RAN. The polemic around Open RAN's level of security compared to other cloud virtualized applications or traditional RAN architecture has been put to bed. Most realize that open interfaces inherently open more attack surfaces, but this is not specific to Open RAN, every cloud based architecture has the same drawback. Security by design goes a long way towards alleviating these concerns and proper no trust architecture can in many cases provide a higher security posture than legacy implementations. In this case, extensive use of IPSec, TLS 1.3, certificates at the interfaces and port levels for open front haul and management plane provide the necessary level of security, together with the mTLS interface between the RICs. The O-Cloud layer must support Linux security features, secure storage, encrypted secrets with external storage and management system.

CaaS:

As per last year, the cloud native infrastructure requirements have been refined, including Hardware Accelerator (GPU, eASIC) K8 support, Block and Object Storage for dedicated and hyper converged deployments, etc... Kubernetes infrastructure discovery, deployment, lifecycle management and cluster configuration has been further detailed. Power saving specific requirements have been added, at the Fan, CPU level with SMO driven policy and configuration and idle mode power down capabilities.

CU / DU:

CU DU interface requirements remain the same, basically the support for all open RAN interfaces (F1, HLS, X2, Xn, E1, E2, O1...). The support for both look aside and in-line accelerator architecture is also the highest priority, indicating that operators havent really reached a conclusion for a preferable architecture and are mandating both for flexibility's sake (In other words, inline acceleration hasn't convinced them that it can efficiently (cost and power) replace look aside). Fronthaul ports must support up to 200Gb by 12 x 10/25Gb combinations and mid haul up to 2 x 100Gb. Energy efficiency and consumption is to be reported for all hardware (servers, CPUs, fans, NIC cards...). Power consumption targets for D-RAN of 400Watts at 100% load for 4T4R and 500 watts for 64T64R are indicated. These targets seem optimistic and poorly indicative of current vendors capabilities in that space.

O-RU:

The radio situation is still messy and my statements from last year still mostly stand: "While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78...) and with multi band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these. This leads vendors trying to find which configurations could satisfy enough volume to make the investments profitable in a quandary. There are hidden dependencies that are not spelled out in the requirements and this is where we see the limits of the TIP exercise. Operators cannot really at this stage select 2 or 3 new RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all of the bands and configurations they need to deploy in their respective network. Since each network is different, it is extremely difficult for a vendor to define the minimum product line up that is necessary to satisfy most of the demand. As a result, the projections for volume are low, which makes the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in n78 band, having 5 vendor providing options for these configurations, with none delivering B40 or B32/B75 makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN." This year, there is one configuration of high priority that has unanimous support: 4T4R B3+B1. The other highest priority configurations requested by a majority of operators are 2T4R B28B+B20+B8, 4T4R B7, B3+B1, B32B+B75B, and 32T32R B78 with various power targets from 200 to 240W.

Open Front Haul:

The Front Haul interface requirements only acknowledge the introduction of Up Link enhancements for massive MIMO scenarios as they will be introduced to the 7.2.x specification, with a lower priority. This indicates that while Ericsson's proposed interface and architecture impact is being vetted, it is likely to become an optional implementation, left to the vendor's s choice until / unless credible cost / performance gains can be demonstrated.

Transport:

Optical budgets and scenarios are now introduced.

RAN features:

Final MoU positions are now proposed. Unanimous items introduced in this version revolve mostly around power consumption and efficiency counters, KPIs and mechanisms. other new requirements introduced follow 3GPP rel 16 and 17 on carrier aggregation, slicing and MIMO enhancements.

Hardware acceleration:

a new section introduced to clarify the requirements associated with L1 and L2 use of look aside and inline. The most salient requirement is for multi RAT 4G/5G simultaneous support.

Near RT RIC:

The Near Real Time RIC requirements continue to evolve and be refined. My perspective hasn't changed on the topic. and a detailed analysis can be found here. In short letting third party prescribe policies that will manipulate the DU's scheduler is anathema for most vendors in the space and, beyond the technical difficulties would go against their commercial interests. operators will have to push very hard with much commercial incentive to see xapps from 3rd party vendors being commercially deployed.

E2E use cases:

End-to-end use cases are being introduced to clarify the operators' priorities for deployments. There are many  but offer a good understanding of their priorities. Traffic steering for dynamic traffic load balancing, QoE and QoS based optimization, to optimize resource allocation based on a desired quality outcome... RAN sharing, Slice assurance, V2x, UAV, energy efficiency... this section is a laundry list of desiderata , all mostly high priority, showing here maybe that operators are getting a little unfocused on what real use cases they should focus on as an industry. As a result, it is likely that too many priorities result in no priority at all.

SMO

With over  260 requirements, SMO and non RT RIC is probably a section that is the most mature and shows a true commercial priority for the big 5 operators.

All in all, the document provides a good idea of the level of maturity of Open RAN for the the operators that have been supporting it the longest. The type of requirements, their prioritization provides a useful framework for vendors who know how to read them.

More in depth analysis of Open RAN and the main vendors in this space is available here.

What's behind the operators' push for network APIs?

 

As I saw the latest announcements from GSMA, Telefonica and Deutsche Telekom, as well as the asset impairment from Ericsson on Vonage's acquisition, I was reminded of the call I was making three years ago for the creation of operators platforms.

One one hand, 21 large operators (namely, America Movil, AT&T, Axiata, Bharti Airtel, China Mobile, Deutsche Telekom, e& Group, KDDI, KT, Liberty Global, MTN, Orange, Singtel, Swisscom, STC, Telefónica, Telenor, Telstra, Telecom Italia (TIM), Verizon and Vodafone) within the GSMA launch an initiative to open their networks to developers with the launch of 8 "universal" APIs (SIM Swap, Quality on Demand, Device Status, Number Verification, Simple Edge Discovery, One Time Password SMS, Carrier Billing – Check Out and Device Location). 

Additionally, Deutsche Telekom was first to pull the trigger on the launch of their own gateway "MagentaBusiness API" based on Ericsson's depreciated asset. The 3 APIs launched are Quality-on-demand, Device Status – Roaming and Device Location, with more to come.

Telefonica, on their side launched shortly after DT their own Open Gateway offering with 9 APIs (Carrier Billing, Know your customer, Number verification, SIM Swap, QOD, Device status, Device location, QOD wifi and blockchain public address).

On the other hand, Ericsson wrote off 50% of the Vonage acquisition, while "creating a new market for exposing 5G capabilities through network APIs".

Dissonance much? why are operators launching network APIs in fanfare and one of the earliest, largest vendor in the field reporting asset depreciation while claiming a large market opportunity?

The move for telcos to exposing network APIs is not new and has had a few unsuccessful aborted tries (GSMA OneAPI in 2013, DT's MobiledgeX launch in 2019). The premises have varied over time, but the central tenet remains the same. Although operators have great experience in rolling out and operating networks, they essentially have been providing the same connectivity services to all consumers, enterprises and governmental organization without much variation. The growth in cloud networks is underpinned by new generations of digital services, ranging from social media, video streaming for consumers and cloud storage, computing, CPaaS and IT functions cloud migration for enterprises. Telcos have been mostly observers in this transition, with some timid tries to participate, but by and large, they have been quite unsuccessful in creating and rolling out innovative digital services. As Edge computing and Open RAN RIC become possibly the first applications forcing telcos to look at possible hyperscaler tie-ins with cloud providers, it raises several strategic questions.

Telcos have been using cloud fabric and porting their vertical, proprietary systems to cloud native environment for their own benefit. As this transition progresses, there is a realization that private networks growth are a reflection of enterprises' desire to create and manage their connectivity products themselves. While operators have been architecting and planning their networks for network slicing, hoping to sell managed connectivity services to enterprises, the latter have been effectively managing their connectivity, in the cloud and in private networks themselves without the telcos' assistance. This realization leads to an important decision: If enterprises want to manage their connectivity themselves and expand that control to 5G / Cellular, should Telcos let them and if yes, by what means?

The answer is in network APIs. Without giving third party access to the network itself, the best solution is to offer a set of controlled, limited, tools that allow to discover, reserve and consume network resources while the operator retains the overall control of the network itself. There are a few conditions for this to work. 

The first, is essentially the necessity for universal access. Enterprises and developers have gone though the learning curve of using AWS, Google cloud and Azure tools, APIs and semantic. They can conceivably see value in learning a new set with these Telco APIs, but wont likely go through the effort if each Telco has a different set in different country.

The second, and historically the hardest for telcos is to create and manage an ecosystem and developer community. They have tried many times and in different settings, but in many cases have failed, only enlisting friendly developers, in the form of their suppliers and would be suppliers, dedicating efforts to further their commercial opportunities. The jury is still out as to whether this latest foray will be successful in attracting independent developers.

The third, and possibly the most risky part in this equation, is which APIs would prove useful and whether the actual premise that enterprises and developers will want to use them is untested. Operators are betting that they can essentially create a telco cloud experience for developers more than 15 years after AWS launched, with less tools, less capacity to innovate, less cloud native skills and a pretty bad record in nurturing developers and enterprises.

Ericsson's impairment of Vonage probably acknowledges that the central premise that Telco APIs are desirable is unproven, that if it succeeds, operators will want to retain control and that there is less value in the platform than in the APIs themselves (the GSMA launch on an open source platform essentially directly depreciates the Vonage acquisition).

Another path exist, which provides less control (and commercial upside) for Telcos, where they would  host third party cloud functions in their networks, even allowing third party cloud infrastructure (such as Amazon Outpost for instance) to be collocated in their data centers. This option comes with the benefit of an existing ecosystem, toolset, services and clients, just extending the cloud to the telco network. The major drawback is that the telco accepts their role as utility provider of connectivity with little participation in the service value creation.

Both scenarios are being played out right now and both paths represent much uncertainty and risks for operators that do not want to recognize the strategic implications of their capabilities.

Open RAN technical priorities release 3

The Open RAN technical priorities release 3, was published in March 2023 by Deutsche Telekom, Orange, Telefonica, TIM and Vodafone as part of the Open RAN MoU group at the Telecom Infra Project.

A review of the mandatory, highest priority unanimous requirements shed lights on what the big 5 operators consider essential for vendors to focus on this year, and more importantly highlights how much efforts are still necessary by the industry to meet markets expectations.

Scenarios

In this section, the big 5 regard virtualized DU and CU with open Front Haul on site as a must, for Macro and indoor / outdoor small cell deployments. This indicates that 7.2.x remains the interface of choice, despite recent attempts by other vendors to change its implementation. It also shows that as a first step, at least, they are looking at deploying Open RAN in the conventional fashion, replacing traditional e/g Node  B with like-for-like O-RU, DU. CU on site. The benefits of resource pooling due to disaggregation and virtualization, enabling either CU or CU and DU to be centralized is the highest priority by the majority of operators, but not all yet. Network sharing of O-RU and vDU/CU is also a highest priority for the majority of operators.

Security

The security requirements have increased dramatically in this latest version, with the vast majority of the requirements (166 out of 180) considered highest priority by al the MoU operators. This evolution marks the effort that have been dedicated to the topic over the last 24 months. Open RAN has been openly criticized and accused of lax security and the O-RAN alliance has dedicated a working group to assess and shore up criticism in that space. My assessment is that most of the security concerns of Open RAN are either linked to virtualization / O-Cloud implementation or just mechanically a result of having more open interfaces, providing more attack surfaces. Open RAN is not inherently more or less secure than 3GPP implementation and the level of security by design necessary to satisfy the criticisms we have seen in the media is not today implemented by traditional RAN vendors either. Having said that, the requirements now spell out exhaustively the level of admission control, authentication, encryption, certification necessary for each interface, for each infrastructure block and for their implementation in a cloud native containerized environment.

O-Cloud Infrastructure (CaaS)

The O-Cloud requirements are focused on ensuring a cloud-native architecture, while allowing acceleration hardware whenever necessary. As a result, the accent is put on bare metal or IaaS implementations of Kubernetes, with FPGA, eAsic, GPU acceleration support and management. The second theme that is prevalent in O-Cloud unanimous high priority requirements is the lifecycle management features which indicate a transition from the lab to more mature commercial implementations going forward.

CU and DU requirements

First and foremost the big 5 unanimously are looking at virtualized and containerized implementations of O-CU/O-DU with both look-aside and inline acceleration (this is contradictory, but I assume either one is acceptable). The next requirements are the usual availability, scalability, and performance related requirements we find in generic legacy RAN systems. All O-RAN interfaces support are mandatory.

Interestingly, power consumption targets are now spelled out per scenario.

RU requirements

The Radio Units requirements area good illustration of the difficulty to create a commercially viable Open RAN solution at scale. While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78...) and with multi band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these. This leads vendors trying to find which configurations could satisfy enough volume to make the investments profitable in a quandary. There are hidden dependencies that are not spelled out in the requirements and this is where we see the limits of the TIP exercise. Operators cannot really at this stage select 2 or 3 new RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all of the bands and configurations they need to deploy in their respective network. Since each network is different, it is extremely difficult for a vendor to define the minimum product line up that is necessary to satisfy most of the demand. As a result, the projections for volume are low, which makes the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in n78 band, having 5 vendor providing options for these configurations, with none delivering B40 or B32/B75 makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN.

The other RU related requirements helpfully spell out the power consumption, volume and weight targets for each type of configuration.

Open Front Haul requirements

There are no changes in the release 3, which shows the maturity of the interface implementation.

RAN features

The RAN features of the highest priority unanimously required by the big 5 operators remain mostly unchanged and emphasize the need for multi connectivity. Dual connectivity between 4G and 5G is essential for any western european operator to contemplate mass deployment of open RAN or replacement of their Chinese RAN vendor. The complexity does not stop to the support of the connectivity, but also necessitate advanced features such as Dynamic Spectrum Sharing (DSS) and Carrier Aggregation (CA) which is a complexity multiplier when associated with the RU band support requirements. These advanced features are probably some of the highest barriers to entry for new vendors in the space, as they have been developed for years by traditional vendors and require a high level of technological maturity and industrialization.

Near-RT RIC

The requirements for the Near-Real Time RAN Intelligent Controller are extremely ambitious. While they technically would enable better control of a multi-vendor RAN operation, they are unlikely to succeed in the short to medium term, in my opinion, as per previous analysis.

SMO and Non-RT RIC

The requirements for Service Management and Orchestration and Non-Real Time RIC are fairly mature and provide a useful framework for RAN domain automation and lifecycle management. The accent in this release is put on AI/ML support and management, which shows that the operators have been seduced by the promises of the technology, allowing a zero touch, automated, network, relying on historical analysis and predictive algorithms. The requirements are fairly high level, suggesting that the operators themselves might not have yet very clear targets in terms of algorithmics policy, performance and management.

In conclusion, this document provides useful data on Open RAN maturity and priorities. While the release 3 shows great progress in many aspects, it still fails to provide sufficient unanimous guidance from a commercial standpoint on the minimum set of end to end capabilities a vendor could reasonably develop to be selected for deployment at scale in these western european networks.

RICs and Apps executive summary

I first came across open RAN as a concept in 2016, as one of the teams I was supporting at Telefonica was looking into connecting the unconnected in Latin America. After ascertaining the demand, the primary problem to solve was affordability. It just wasn’t economical to deploy traditional RAN networks designed for dense urban environment in the middle of the jungle. The team came out with an interesting idea, the disaggregation of the RAN into components, allowing to pool resources and enabling multiple vendors to compete for different parts of the deployment.

After a few iterations and field trials, the team went on to write the first Open RAN RFI, jointly with Vodafone, released at TIP. From this idea, an ecosystem was born, with a community of operators and vendors, issuing specifications at the Open RAN alliance, elaborating and testing blueprints, issuing requirements and roadmap at the Telecom Infra Project and commercial deployments slowly spreading from Japan to Western Europe and North America.

As the first layer of disaggregation has split the gNodeB into the Radio Units, Centralized Units and Distributed Units, an ecosystem of vendors has emerged, addressing each or all the parts of this new architecture. That first layer of disaggregation was aimed at disrupting the traditional RAN ecosystem, breaking the oligopoly of vendors that have come to dominate the market.

The next stage of disaggregation is aimed at disrupting further the market, by introducing elements of vendor-independent centralized management, optimization, visualization and orchestration with the introduction of the Radio Interface Controllers (RICs). Two RICs have been defined, and although they share the same name, they are quite different in nature and ambition.

The non real time RIC is part of the Service Management and Orchestration layer and is the evolution of Self Organizing Networks (SON) and the RAN OSS / Element management. Features instantiated on the non real time RIC can be deployed as rApps, a standard-defined set of interfaces for multiple vendors to deploy.

The near real time RIC is a feature set belonging to the RAN layer and aimed at disaggregating it further. It extracts capabilities today embedded in the gNodeB, or the RU, CU, DU and provides a layer of abstraction and platform for multiple vendors to theoretically pilot and tune the Radio Network. xApps are the applications that can be developed to be deployed on near real time RIC.

From my experience at Telefonica, as an operator or at Bell Canada or Deutsche Telekom as advisor and consultant or from my time at NEC as global VP Product Management overlooking the development and partnerships surrounding open RAN products, or as an independent analyst researching the market, I have derived a unique perspective on the maturity and effectiveness of open RAN, RICs and Apps. 

This report examines the architecture, strength, drawbacks of open RAN RICs and apps as well as provides an inventory of the main players in the space.

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.

The Lean Telco

As alluded to in my previous posts, I have tweaked the Lean Startup methodology and the Wardley Map model to create value in a telco environment.

Value is a subjective topic but in a Telco context, my efforts have been aimed at creating sustainable growth strategies. Very simply, sustainable growth comes from sustainable differentiation, which stems from the creation and evolution of technological, commercial and operational characteristics that become difficult, expensive and time consuming to emulate from your competition.

Sustainable growth comes from sustainable cost reduction and revenue growth (Duh!).

Sustainable cost reduction can be achieved through drastic cost structure changes. In 2020 Telco, it can be attained through the implementation of a cloud native architecture and principles, underpinned by strategies of network disaggregation, extensive use of open APIs and open network topologies; SDN and control / user plane separation and systematic automation. While these goals are challenging by themselves, particularly in a brownfield legacy telco environment, they are the bare necessary changes for survival. The challenges associated with the organization, skill sets and methodologies to evaluate, test, deploy, purchase and maintain these technologies are even larger.
Every telco is extremely skilled at managing technological and operational risk, through iterative, waterfall evaluation and tests, resulting in deployment of high availability and capacity networks. This methodology has also led to lengthy evaluation periods and deployments. Most vendor will recognize that the sales cycles in telco are over 2 years long and that making any change in a commercial network takes several million of dollar or euros. This has led to an oligopoly where only a handful of specialized vendors are able to sustain economically these drastic processes.
Lately, telcos have been trying to diversify the pool of vendors to increase competition and innovation by promoting open source and open API projects such as open RAN.
While these projects have shown interesting progress, the real cost reduction comes from the change in methodology and processes to take advantage of these more nimble vendors offering.

What I am proposing with Lean Telco is a methodological framework for identifying, evaluating, testing, sourcing, deploying telco products and services that will provide sustainable differentiation with drastically different cost structure than the incumbent versions.

Once you have successfully changed the cost structure of evaluating, buying, deploying and managing telco infrastructure and capacity, you can survive as a high capacity, low overhead provider of connectivity. But if you want to strive and grow, you need to attack the revenue part of the equation. Actually, one would argue should start with growth objectives, and look at cost structure as an optimization challenge.

Growing revenue sustainably, in a telco environment comes from either having more people using your existing services, or using more of them, connect new people or create new services. I have prototyped, tested and launched projects in each of these categories in my last role at Telefonica.

1. Having more people use your existing products is difficult for telcos, because those products (residential and enterprise mobility, internet, telephony, TV...) are poorly differentiated, since they rely on the same technology from the same vendors. As a result most telcos end up trying to deploy first (5G, SDWAN...) or to claim a performance advantage, usually derived from a superior spectrum or infrastructure investment. The only real differentiation ends up being pricing. This is very expensive and not sustainable.
2. Having your customers using more of your service does not necessarily lead to more revenue, as bundles and unlimited plans are periodically rolled out to counter internet hyperscalers offering who rely on a different cost structure and revenue model. Again, since these services are mostly the same from one operator to another, differentiation comes from bundling and pricing. This is not sustainable.
3. Connecting new people / clients is a worthy endeavour, but the last unconnected live mostly in rural, low density areas and selling services to new corporate clients usually mean competing against public cloud offering that are more cost effective and flexible than what most telcos can offer. There are possibility of growth there, but it requires breaking out from the current telco technological framework and a willingness to assemble new value chains.
4. Creating new services is certainly where there is the most value, if we look at the growth of telephony over internet, video streaming services, social media and social messaging, SDWAN, cloud security... it is also the area with the most uncertainty and risk.

Telcos are not well equipped to manage the risk and uncertainty inherent in the discovery and creation of new services. The methodologies, organization and processes they use is to deliver with absolute certainty a product or utility with zero default to a mass market without variation. This model works well for mature, disciplined technology and vendors, not at all for exploration and innovation.
Too often, some Telcos build an extremely detailed plan, with contingencies. They budget it, staff it, resource it to execute it within a given timeframe, only to discover that the client didn't really want / need / value what was proposed (cf. push to talk, IMS/VoLTE, RCS, private networks...).

Just like in Lean Startup, the methodology I propose allows the progressive liberation of resource and funds as commercial uncertainty is shed by direct client interaction, testing and feedback. In a typical telco environment, the client interaction is at the very end of the process, here we are going to intersperse it throughout the development process to allow pivots, or early termination if the hypothesis are not met.

Trained, mentored and helped by many, I have adapted a few methodologies to enable Telcos to identify, validate, and deploy new services in an agile and cost effective fashion. I call it the Lean Telco Methodology.

How do I create a Lean Telco?
I use Wadley Maps for situational awareness and create a topographical representation of the current environment, which in my area of interest range from telco network virtualization (NFV), orchestration (MANO), cloud native distribution and orchestration (K8, micro service) and hybrid cloud / edge computing (telco private stacks, AWS outpost, MS Azure edge, Google Anthos...). This is not a map until we apply the level of maturity (Genesis / handmade, Custom / solution, Product, Utility) to each of them, as well as their direction and barriers on the horizontal axis. On the vertical axis, instead of using Wardley's traditional visibility method, I use technology stacks such as access, transport, core network, OSS /BSS, orchestration... The purpose of the map is not to be precise or even right, it is to share and compare comprehension of the environment, the players, their direction, velocity and the barriers. This visualization enables a level of shared understanding necessary to strategic discussions and gameplay around permutations and what-if? scenarios.


Once identified priorities and areas of risks / opportunities to investigate, I use the Lean UX framework and Lean Startup methodology to systematically identify potential current problems needing solving, unmet customer needs, unsatisfactory experiences and potential new products / services that customer wouldn't even know or have an opinion about. A series of workshop is usually best to crystalize the ideas. Once identified, they need to be refined into customer centric objectives. Contrary to popular belief, customer centricity is not necessarily going to ask prospective customers about what they think. Most wouldn't have any idea about what to do with 5G, augmented reality or a private network if you asked them. This is where lean UX and empathetic composite models are useful.

Each idea is reviewed by a jury and graded, the jury will define which ideas can make it to the next stage. The ideas are shaped and staffed as independent projects, with dedicated resource, budget and time box. Each project lead has the overall responsibility for moving the project to the next phase and to deliver the results of the current phase to justify additional resource and budget for the next one.
At a high level, the phases are:

• Ideation - ($5k-10k /1 - 3 months) -the idea is shaped into a project, with central opportunities, areas of innovation, right to play for the company, sustainable differentiating factor, commercial high level opportunity and cost / timing for the next phase.
• Prototyping - ($20k - 50k / 2 - 6 months) - In this phase a prototype is built, that might or might not incorporate any development or use of technology for the target invention. The idea is just to emulate the resolution of the problem and put it into customers hands as early as possible to identify whether the objectives, assumptions are framed properly and whether the client would value the resolution.
• Beta - ($300k - $600k / 3 - 6 months) -  once the central problems are identified, and we know the client values their resolution, it is time to create a MVP to prove that it is technically, commercially, organizationally possible to solve that problem and that the value created exceeds the costs.
• Product - ($1m - $3m / 3 - 6 months) - In this phase, once proven that the solution is possible, it is necessary to prove that the solution will scale and will be deployable with a mature operational and commercial model.
• Growth - (TBD) This is the phase where the project needs to be commercially and economically sustainable.

Each phase require client interactions, in the form of actual tests in conditions as close as possible to commercial network. Within each phase, we decompose the project into customer centric objectives. Each objective into hypothesis. Each hypothesis into series of experiments that will validate or invalidate the hypothesis. It helps to set clear expectations and success criteria for each of these.
Wardley maps helps again, within each phase understanding what tasks, experiments are more suited for pioneers, settlers or town planners and indeed whether the project lead can adopt this mental posture in this phase or whether someone else needs to take the lead.

The result is a portfolio of new revenue making projects, that are systematically validated by customer feedback, capacity and propensity to pay; together with a robust operational and commercial model. Each project is periodically reviewed and graded, all projects must pass a gate review before the next phase and liberation of funds, which allow a nimble, measured, progressive investment plan, as risks and uncertainty decrease throughout the life of the project.

Of exploring, planning and executing in Telco

Over the last few years, I have embarked on a journey of discovery to create sustainable value in telco and cloud environments. Spurred initially by my boss, David del Val at Telefonica, then by Susana Jurado, I slowly learned the basis of lean startup applied to large telco businesses. Then, helped by colleagues such as Carlos Gonzalez, I learned how to apply design thinking and lean UX to the creation of products. Further on, I discovered Wardley's mapping and became an instant enthousiast and timid practitioner. I have been inspired by my teams that have put these methodologies in practice, particularly Juan Campillo with Internet para todos, David Artunedo with Onlife and David Lopez Meco with the first iterations of network as a service.

Be it the world's first implementations of Open Ran or of edge computing in a commercial telco network, or the first implementation of an open source SDWAN in a hybrid telco / commercial cloud network, I have learned much about the methodology and the state of our industry.

I have learned so much, and at the same time, I feel so humbled by the progress of others. There is so much more to learn. Here are a few nuggets I still use in my day to day work.

• Telcos are excellent at planning and executing iterative organic improvements. Their capacity to plan, operate, execute incrementally is second to none.
• Telcos are not so good at disruptive innovation. Having a large part of the organization trained to make sure things don't break doesn't lend itself well to the necessary risk taking of exploring high uncertainty opportunity.
• Lean startup and Telefonica's Lean Elephant is a practical step towards managing this uncertainty.
• Telcos desperately need to understand that the value to capture in 5G is not in the "plumbing" but in the services enablement.
• Granular, stage-based, project funding and validation with end customers is key to identify and understand value for customers.
• Being customer centric is key, but customer centric is not what you think the value is to the customer and is not what the customer thinks you should do. There is no substitute for testing live with real customers.
• To find one successful service, you might have to test 20 or 50 of them - that's 150 telco years...
• It is possible to compress discovery and innovation through a process of setting objectives, listing hypotheses and systematically designing experiments with customers to validate them with explicit success criteria and expectations
• Such a process allows to adjust, validate, pivot, accelerate or kill projects 
• It is much better to make a lot of imperfect decisions fast, with the ability to measure and adjust than having one very detailed master plan, greatly executed, leading to a product nobody wants
• Have a doctrine, people need a true north star and tools to help decision making
• Challenge the status quo and be bold
• Recognize and empower pioneers, settlers and town planners. Apply the right mix at the right product phase

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:

• xRAN 2020 report and workshop
• Edge Computing 2020 report and workshop

Telco relevance and growth

I am often asked what I think are the necessary steps for network operators to return to growth. This is usually a detailed discussion, but at a high level, I think a key to operators' profitability is in creating network services that are differentiated.
I have seen so much value being created for consumers and enterprises at Telefonica when we started retaking control of the connectivity, that I think there are some universal lessons to be learned there.

Curating experiences

Creating differentiated network services doesn't necessarily mean looking at hyper futuristic scenarios that entail autonomous drones or remote surgery. While these are likely to occur in the next 10 to 20 years, there is plenty today that can be done to better user experiences.
For instance, uploading large files or editing graphics files in the cloud is still slow and clumsy. Also, broadband networks' advertised speed has become meaningless for most consumers. How can you have a 600mbps connection and still suffer from pixelated video stream or a lagging gaming session? There are hundreds of these unsatisfactory experiences that could benefit from better connectivity.

These nonoptimal experiences can be where operators can start creating value and differentiating themselves. Afterall, operators own their networks; since they do not rely on the open internet for transport, they should presumably be able to control the traffic and user experience at a granular level? A better connectivity experience is not always synonymous with more speed, in most case it means a control debit, latency and volume.

Accepting this, means that you have to recognize that the diktat of "one size fits all" is over for your network. You cannot create a connectivity product that is essentially the same for everyone, whether they are a teenage gamer, an avid video streaming fan, an architect office, a dentist or a bank branch. They all have different needs, capabilities, price elasticity and you can't really believe that your network will be able to meet all their needs simultaneously without more control. Growth is unlikely to come in the future for everyone paying the same price for the same service. There are pockets of hyper profitability to extract, but they need a granular control of the connectivity.

"Vanilla" connectivity for all will not grow in terms of revenue per user with more general speed.

Being able to create differentiated experience for each segment  means certainly being able to identify and measure them. That's the easy part.  Operators mostly have a good, granular grasp on their market segments. The hard part is finding out what these segments want / need and are willing to pay. The traditional approach is to proceed by creating a value proposition, based on a technology advance, test it in market studies, focus groups, limited trials and trials at scale before national launch.

While this might work well for services that are universal and apply to a large part of the population, identifying the micro segments that are willing to pay more for a differentiated connectivity experience requires a more granular approach. Creating experiences that delight the customers is usually not the result of a marketing genius that had it all planned in advance. In my experience, creating, identifying and nurturing this value comes from the contact with the client, letting them experience the service. There are usually many unintended consequences when one starts playing with connectivity. Many of successful telco services are the fruit of such unintended consequences (texting was initially a signalling protocol for instance).

Programmable networks

One way to create and curate such experiences is to increase your control on the connectivity. This means disaggregate, virtualize and software-define the elements of your access (virtualize the OLT and the RAN, built a programmable SDN layer).
You should accept that you can't a priori really understand what your customers will value without testing it. There will be a lot of unintended consequences (positive and negative). It is therefore necessary to create a series of hypothesis that you will systematically test with the customer to validate or discard them. These tests must happen "in the wild" with real customers, because there are invariably also many unintended consequences in deploying in live networks with real population compared to in a lab with "friends and family" users.
In average, you might need to test 50-60 variants to find 2 or 3 successful services. In telecom-years, that's about 100 years at today's development / testing cycles. But if you have a programmable networks, and know how to program, these variants can be created and tested at software speed.

Therefore, you need to test often and pivot fast and you need to be able to test with small, medium and large samples. The key for this is to build an end to end CI/CD lab that is able to coarsely reproduce your network setup from the core, the access and transport perspective. It needs to be software defined with open interfaces, so that you can permutate, swap and configure new elements on-demand.

Since current networks and elements are so complex and proprietary, you need to identify greenfields and islands of wilderness in your connectivity where you will be able to experiment in isolation without disrupting your core customer base. At Telefonica, these uncharted connectivity fields were rural networks and edge computing, in other networks, AI-augmented networks operation, network slicing or 5G could be perfect experimentation grounds.

Pluridisciplinary teams

Another learning is that not integrating user / customer feedback at every stage of the elaboration of the service is deadly. It is necessary that UX designers be part of the process from the inception and throughout. They might not be as heavily involved in some phases (development) than others (inception, beta, trial...) so they can be shared across projects.
Increasingly, data science, security and privacy good practices need to be considered also throughout the projects pivot points. In many cases, it is difficult, expensive or impossible to retrofit them if they were not part of the original design.
Products and services do not necessarily need large teams to take off the ground and create value, but they do need dedication and focus. Resist the temptation to have the core team work cross-project. What you gain by identifying possible synergies, you lose in velocity. Rather have small dedicated teams with core members and specialists that are lent from project to project for periods of time.
Foster internal competition. Evaluate often and be ready to pivot or kill projects.

Paradoxically, when you find a successful service, in many organization, the phase in which these projects are most likely to die is when transitioning to the products and business teams. The key is possibly for these not to transition. I have long advocated that it is easier for an operator to launch 5G as a separate company than as an evolution. But it is impractical for many operators to consider starting a parallel organization for network transformation.These innovations, if they are to transform the way the networks and services are managed must be accompanied by a continuous training process and a constant resource rotation between innovative and live projects. Therefore transformation and innovation is not the work of a dedicated team, but of the whole workforce and everyone has opportunity to participate in innovation projects, from inception to delivery.


Beyond the "how", the teams need a clear framework to guide them in their daily decision making. The "what" needs to be oriented by a vision, strategies, tactics and a doctrine that will explore in a subsequent post.

Please share your experience with transformation and innovation projects in the telco world. We all grow by sharing. "A rising tide lifts all boats".

Interested in how these principles were applied to the creation of the Open RAN market? contact me for a copy of the report "xRAN 2020".

Announcing telco edge computing and hybrid cloud report 2020

As I am ramping up towards the release of my latest report on telco edge computing and hybrid cloud, I will be releasing some previews. Please contact me privately for availability date, price and conditions.

In the 5 years since I published my first report on the edge computing market, it has evolved from an obscure niche to a trendy buzzword. What originally started as a mobile-only technology, has evolved into a complex field, with applications in IT, telco, industry and clouds. While I have been working on the subject for 6 years, first as an analyst, then as a developer and network operator at Telefonica, I have noticed that the industry’s perception of the space has polarized drastically with each passing year.

The idea that telecom operators could deploy and use a decentralized computing fabric throughout their radio access has been largely swept aside and replaced by the inexorable advances in cloud computing, showing a capacity to abstract decentralized computing capacity into a coherent, easy to program and consume data center as a service model.

As often, there are widely diverging views on the likely evolution of this model:

The telco centric view

Edge computing is a natural evolution of telco networks. 
5G necessitates robust fibre based backhaul transport.With the deployment of fibre, it is imperative that the old copper commuting centers (the central offices) convert towards multi-purposes mini data centers. These are easier and less expensive to maintain than their traditional counterpart and offer interesting opportunities to monetize unused capacity.

5G will see a new generation of technology providers that will deploy cloud native software-defined functions that will help deploy and manage computing capabilities all the way to the fixed and radio access network.

Low-risk internal use cases such as CDN, caching, local breakout, private networks, parental control, DDOS detection and isolation, are enough to justify investment and deployment. The infrastructure, once deployed, opens the door to more sophisticated use cases and business models such as low latency compute as a service, or wholesale high performance localized compute that will extend the traditional cloud models and services to a new era of telco digital revenues.

Operators have long run decentralized networks, unlike cloud providers who favour federated centralized networks, and that experience will be invaluable to administer and orchestrate thousands of mini centers.

Operators will be able to reintegrate the cloud value chain through edge computing, their right-to-play underpinned by the control and capacity to program the last mile connectivity and the fact that they will not be over invested by traditional public clouds in number and capillarity of data centers in their geography (outside of the US).

With its long-standing track record of creating interoperable decentralized networks, the telco community will create a set of unifying standards that will make possible the implementation of an abstraction layer across all telco to sell edge computing services irrespectively of network or geography.

Telco networks are managed networks, unlike the internet, they can offer a programmable and guaranteed quality of service. Together with 5G evolution such as network slicing, operators will be able to offer tailored computing services, with guaranteed speed, volume, latency. These network services will be key to the next generation of digital and connectivity services that will enable autonomous vehicles, collaborating robots, augmented reality and pervasive AI assisted systems.

The cloud centric view:

Edge computing, as it turns out is less about connectivity than cloud, unless you are able to weave-in a programmable connectivity. 

Many operators have struggled with the creation and deployment of a telco cloud, for their own internal purposes or to resell cloud services to their customers. I don’t know of any operator who has one that is fully functional, serving a large proportion of their traffic or customers, and is anywhere as elastic, economic, scalable and easy to use as a public cloud.

So, while the telco industry has been busy trying to develop a telco edge compute infrastructure, virtualization layer and platform, the cloud providers have just started developing decentralized mini data centers for deployment in telco networks.

In 2020, the battle to decide whether edge computing is more about telco or about cloud is likely already finished, even if many operators and vendors are just arming themselves now.

Edge computing, to be a viable infrastructure-based service that operators can resell to their customers needs a platform, that allows third party to discover, view, reserve and consume it on a global scale, not operator per operator, country per country, and it looks like the telco community is ill-equipped for a fast deployment of that nature.

Whether you favour one side or the other of that argument, the public announcements in that space of AT&T, Amazon Web Services, Deutsche Telekom, Google, Microsoft, Telefonica, Vapour.io and Verizon – to name a few –will likely convince you that edge computing is about to become a reality.

This report analyses the different definitions and flavours of edge computing, the predominant use cases and the position and trajectory of the main telco operators, equipment manufacturers and cloud providers.

vRAN, cRAN, ORAN... whats going on with the Telco Radio Network?

I have been doing more than a dozen due diligence engagements in the virtualized, cloud and disaggregated RAN market space in the last 2 months.

As much as many telco clouds implementation have been somewhat disappointing, due to the inability of the industry to force the traditional telecommunications vendors to adopt an open orchestration model, the Radio Access Networks (RAN) have been undergoing a similar transformation with a different outcome.

Based on the same premises that market pressures have forced telecommunications traditional vendors to oligopolistic consolidations, some operators have been trying to open up RAN value chain by forcing the implementation of a disaggregated model.
Specifically, separating hardware from software and deploying radio solutions on commercial-off-the-shelf (COTS) hardware and virtualizing software logical elements such as Radio Remote Units (RRU)  and Base Band Units (BBU).
The RAN is the last part of the network that sees heavy proprietary implementation, from hardware to software to professional services, and most contracts tend to be for key-in-hand study, implementation, installation and maintenance where margins are fairly opaque. This is the bread and butter of traditional telco vendors.

The idea is that if you force all vendors to move to software and you can source COTS hardware, you gain CAPEX cost efficiency (COTS is cheaper than proprietary) and if you virtualize all the software, you gain OPEX cost efficiency (you can ideally software -manage everything, which leads to on demand use and cost, as well as vendor independance if the interfaces are open).
Predictably, just like in the case of telco clouds, traditional vendors hesitated cannibalizing a multi billion annual revenue. Unlike in telco cloud, though, a number of operators (BT, Deutsche Telekom, Telefonica, Vodafone...) elected to show how serious they were about RAN cost optimization and decided to approach a number of emerging vendors.
These vendors, unlike traditional telco vendors provide an array of innovative solutions, that are usually cloud-native (software defined, virtualized, hardware agnostic) and are eager to attack the incumbents market.
In order to show a clear market commitment, Telefonica and Vodafone released two years ago and last year a public tender within Facebook's TIP summit. This process is remarkable in the telco space in the fact that the list of invited companies (any company part of TIP), the content of the RFI and the ranking of the participating vendors were publicly announced.

The results ranked the vendors along their performance, openness and time to market readiness. The sponsoring operators committed to clear timeframe for lab trials, field trials and commercial deployments.
The tender showed that an ecosystem of innovative vendors was capable to emerge and complement the current value chain with adapted solutions.
Generally speaking these emerging companies do not have to manage the legacy of hundreds of obsolete product releases, which allows them to have a much faster development cycle. This is important because in many case, they do not have the product depth of their more mature competition (2G, 3G, 4G, 5G, small, mini, macro cells). On the other hand they also often lack the operational maturity to manage a RAN deployment at scale for a tier one operator.

Cloud RAN (cRAN), Virtualized RAN (vRAN) and Open RAN (O RAN) are all concepts that have emerged in the last few years to describe this emerging ecosystem. While most operators would rather continue purchasing from their traditional vendors, to reduce operational and financial risks, the race to 5G and the pressure on margins and operators stock prices is forcing them to reevaluate the RAN value chain.
Open, open source and disaggregation are trendy topics in telco, but they come with a steep learning curve as they force those who want to follow this path to actually change their operating model if they want to extract the most value.
The market needs the emergence of a new category of open source distributors, a Red Hat of telco open source if you will, as well as a new category of systems integrators that can take the effort of assembling these new vendors categories into coherent solutions and services that traditional telco will want to purchase.

Hit me up if you want more details on that market space, I am preparing a workshop and report on this.

Gaming in the edge of cloud

As i just wrap up a couple of weeks immersed in the world of cloud gaming, I thought I would share some of what I have learned and a few opinions on the subject while it is still fresh in my mind. First, a short confession - I have been a gamer since my first Atari Pong and Activision consoles - I don't play enough to my taste, since I haven't been able to reach my lifelong ambition of being paid to play video games.
An opinion has formed and has imposed itself as an evidence through my various meetings at the Game Developers Conference last week:

Gaming is like video streaming a few years ago: we used to look at a fraction of mobile users as "bandwidth hogs" as 5-10% of them used 70-80% of data capacity as video streaming appeared. Within a few years, as LTE was implemented at scale and higher capacity became available, we found out that we were all bandwidth hogs, we were all willing to stream video, if the networks were fast and reliable and if the costs were reasonable.

I feel that gaming will go through a similar aha moment once we make every game available on any device, at reasonable price, without having to buy or build expensive PCs or consoles. We are all gamers, we just don't know it yet.
As I turn my attention to this market, I find that much of my gaming experience still has a lot of frictions:

• Buying a console game requires going to a store or a long download (if I have enough storage left)
• Buying a PC game requires the same, with the added effort of ensuring that I have enough graphic capacity, computing to run it well. If you're hardcore, you start chasing latency by buying specialized keyboards and mouse for fast twitch response.
• Once I put the disk on my system, I usually have to wait to download updates, patches, installation...
• Once I start playing, my community is usually linked to my console or service, the Venn diagram of my physical and digital friends has overlaps that are artificial
• I would like to think i would get better results if i had better connectivity, as lag affects my performance, particularly in First Player Shooters.
• I still cant play my favourite games (well) on my phone or tablet.

All in all, gaming is already great, but there are many things we could do as an industry to make it better. As I look at the market and the games that are the most popular, there are a number of clear trends:

• Game studios are starting to enforce real multiplatform play, thanks to Fortnite
• There is interest in extending the life cycle of a game from one shot, to downloadable content, to subscription
• To satisfy players, and keep them engaged, MMO (Massive Multiplayer Online) is key
• Freemium can work (thanks Fortnite, Apex...)
• Cloud streaming works OK for single player but struggles for MMO, particularly looking forward to 1080p, 2k, 4k, VR / AR...
• Gaming is still a large screen first experience

Online Gaming requires cloud. Cloud Gaming requires excellent connectivity. Gaming streaming requires a better cloud and better telco. Edge computing might be able to help there.

Edge computing and Telecom Infra Project

Video taken for the 2018 Telecom infra Project summit in London.

The edge computing and access virtualization opportunity

Have you ever tried to edit a presentation online, without downloading it? Did you try to change a diagram or the design of a slide and found it maddening? It is slow to respond, the formatting and alignment are wrong… you ended up downloading it to edit it locally?

Have you ever had to upload a very important and large file? I am talking about tens of gigabytes. The video of your marriage or the response to a commercial tender that necessitated hundreds of hours of work? Did you then look at that progress bar slowly creeping up or the frustratingly revolving hourglass spinning for minutes on hand?

Have you ever bought the newest, coolest console game only to wait for the game to update, download and install for 10, 20, 30 minutes?

These are a few examples of everyday occurrences, which are so banal that they are part of our everyday experience. We live through them accepting the inherent frustration because these services are still a progress over the past.

True, the cloud has brought us a new range of experiences, new services and a great increase in productivity. With its ubiquity, economy of scale and seemingly infinite capacity, the cloud offers an inexpensive, practical and scalable way to offer global services.

So why are we still spending so much money on phones, computers, game consoles,… if most of the intelligence can be in the cloud and just displayed on our screens?
The answer is complex. We value as well immediacy, control, and personalization. Attributes that cloud services struggle to provide all at once. Immediacy is simple; we do not like to wait. That is why even though it might be more practical or economical storing all content or services on mega data centers on the other side of the planet; we are not willing to wait for our video to start, for our search to display, for our multiplayer game to react…

Control is more delicate. Privacy, security, regulatory mandates are difficult to achieve in a hyper-distributed, decentralized internet. That is why even though we trust our online storage account, we still store file on our computer’s hard drive, pictures on our phone, and game saves in our console.

Personalization is even more elusive. Cloud services do a great job of understanding our purchase history, viewing, likes etc… but there still seems to be a missing link between these services and the true context when you are at home teleworking and you want to make sure your video conference is going to be smooth while your children play video games on the console and live streaming a 4K video.

As we can see, there are still services and experiences that are not completely satisfied by the cloud. For these we keep relying on expensive devices at home or at work and accept the limitations of today’s technologies.

Edge computing and service personalization is a Telefonica Networks Innovation project that promises to solve these issues, bringing the best of the cloud and on premise to your services.

The idea is to distribute further the cloud to Telefonica’s data centers and to deploy these closer to the users. Based on the Unica concepts of network virtualization, applied to our access networks (mobile, fiber residential and enterprise), edge computing allows to deploy services, content and intelligence a few milliseconds away from your computer, your phone or your console.

How does it work? It is simple. A data center is deployed in our central office, based on open architecture and interfaces, allowing to deploy our traditional TV, fixed and mobile telephony and internet residential and corporate services. Then, since the infrastructure is virtualized and open, it allows to rapidly deploy third party services, from your favorite game provider, to your trusted enterprise office applications or your mobile apps. Additionally, the project has virtualized, disaggregated and virtualized part of our access networks (OLT for the fiber, baseband unit for the mobile, WAN for the enterprise), and radically simplified it.

The result is what is probably the world’s first multi access edge computing platform on residential, enterprise and mobile access that is completely programmable. It allow us for the first time to provide a single transport, a single range of service to all our customers, where we differentiate only the access.

What does it change? Pretty much everything. All of sudden, you can upload a large 1GB file to your personal storage in 6 seconds instead of the 5 minutes it took on the cloud. You can play your favorite multiplayer game online without console. You can edit this graphic file online without having to download it. …And these are just existing services that are getting better. We are also looking at new experiences that will surprise you. Stay tuned!