Month: November 2020

If you want to make money selling carrier cloud infrastructure, you’re running out of time.  There are three Light Reading stories to buttress this view.  First, Verizon and AT&T are both working through plans to build private wireless networks for enterprises.  Second, IBM has joined other public cloud providers in going after network operator carrier cloud opportunities, and finally, Microsoft and Verizon are partnering for mobile edge computing services (MEC).

All of this is incredibly important, not only to cloud providers and network operators, but also to the vendors who had hoped to reap a piece of the one hundred thousand incremental data centers that carrier cloud could generate by 2030.  These signs, combined with others that I’ve covered in prior blogs, suggest that network operators are changing their thinking, moving to a “cloud-as-a-service” rather than building their own clouds.  Why?  Because nobody has shown them how, or why, they could do that.

All cloud applications pose two questions to buyers.  The first is the nature of the application itself, its functionality and the properties of its implementation that relate to its usability, scalability, and performance.  The second is the resources required to run the application, meaning the hardware, operating system, middleware, management and orchestration tools, etc.  If you want to do something “in the cloud” you need to answer these two questions with respect to your candidate approaches.

Problem number one for operators is that they often know little or nothing about the application side of their cloud plans.  Sure, they’ve heard that their stuff should be “virtualized” and “disaggregated” and “cloud-native”, but what the heck does all that mean?  What applications are out there that have these properties?  The operators may understand things like “SDN” or “NFV”, but they don’t understand how to convert these things, which are really deployment and management architectures and not applications, to the applications themselves.  Without actual applications in mind, it’s hard for them to answer the second question, which is what is needed to run those applications.

I think a big part of the operators’ recent infatuation with public cloud providers as a source of 5G hosting can be traced to this.  Many of these providers are offering not just a platform but a telco cloud application (5G), and so they’re a one-stop shop.  There’s no concern about the functionality or the compatibility of the application to the platform—it’s all integrated, from a single source, and one big enough to sue if they misrepresent things.

For the classic potential beneficiaries of carrier cloud, or the hypothetical beneficiaries thereof, these problems are big stuff.  If operators can’t build carrier cloud applications and infrastructure, the platform vendors lose revenues on a hundred thousand data centers.  Even chip vendors cringe at the thought of that kind of loss.

This is the context of the Samsung/VMware announcement, following a similar one with Samsung and Red Hat, is highly significant.  Absent applications, platforms for 5G are an intellectual exercise, which means that the platform vendors are in the drivers’ seat.  That may also explain Ericsson’s somewhat-late-and-somewhat-uneasy commitment to Open RAN with its “Cloud RAN” platform.  The lack of applications for carrier cloud puts mobile network vendors in an awkward position.  On the one hand, they stand to gain from selling their original proprietary solutions.  That’s particularly true with the pressure on operators to keep price-leader Huawei out of the market.  On the other hand, of operators want an open-model mobile network, the proprietary vendors are setting up non-network competitors to provide it, raising more competition at likely lower prices yet.

Platform vendors would, of course, rather see a bunch of application providers vying for their platform business, and operators pushing for the whole package, than a small number of application vendors all dealing on the same platforms.  That’s particularly true when 5G is the only target at this point, and it’s hardly the only driver of carrier cloud.  In fact, 5G is likely to reach its peak influence on carrier cloud decisions by the end of 2021, and (even then) account for about a fifth of the opportunity.  But 5G is important because it’s the “two-punch” of a “one-two-punch” driver set, the first of which has already failed to produce.

My original carrier cloud market model suggested that to get full data center realization from the opportunity, operators would need to prime the pump, first with NFV and then with 5G.  NFV hasn’t delivered any significant number of data centers, so 5G is the only “familiar” application operators could aim at with carrier cloud deployments.  All the rest of the carrier cloud drivers are things like advertising, streaming video services, and personalization/contextualization, things that the operators aren’t nearly as comfortable with.  If 5G doesn’t deliver some data center deployments, then these hazy and somewhat frightening drivers are going to have to pull the cart all by themselves.  That would make carrier cloud far less likely.

It would also mean that the network operators would be totally dependent on a combination of cost-reducing measures and the revenue for NaaS-type services to erase their profit-per-bit problem.  Neither of these approaches is ideal.  Cost reduction obviously vanishes to a point; you can only reduce cost so much.  NaaS-type revenues have a significant upside, but they also have a lower ROI than retail services would have.  Augmented reality and “contextual services” that build on what a user might want to know about their surroundings, based on where they happened to be, have a retail opportunity and also a NaaS opportunity.  Operators might find the latter more comfortable, but the former would be more profitable.

Would the profit difference between NaaS and retail OTT-type services be enough to make the difference between profitable operators and operators scraping by?  It’s impossible to answer that with any confidence at this point because we don’t know how much of the retail service could be subducted into NaaS features.  We also don’t know the cost of deploying NaaS, in no small part because there are multiple ways of approaching it.

NaaS is really built around what some (including the ONF) have called “programmable networks”.  If a network’s service features can be composed, then services can be based on this composition process rather than extracted from a common set of device behaviors, as they are now.  To make NaaS truly valuable, though, there has to be a way of absorbing new features into the network, features that today lie outside traditional connectivity features but which are mandatory for the network connectivity process to work.  Things like DNS/DHCP, CDN redirection, and the control-to-user-plane interfaces of 4G and 5G fit into this.

So could the AR and contextual services I mentioned above.  As I’ve said in past blogs, it’s totally unrealistic to assume that somebody is going to deploy a bunch of IoT sensors that could be exploited by anyone.  They would want to deploy services based on their own IoT sensors, and thus earn a respectable return on investment.  To do that, there would have to be a way of building those services, and the thing you built them on would have to be deployed.  That’s why the early applications like NFV or 5G are important to carrier cloud; they put the infrastructure into place to host additional “service middleware” features.

NaaS is important in part because it frames a plausible if not compelling revenue model that’s based on direct evolution from operator connection services of the past and present.  The other reason it’s important is because “network” in any form is, to the network consumer, whatever isn’t on my desk, in my hand, or on my wall in my TV mount.  Whatever services we get remotely can be considered network services, and so the operator could offer them without a culture-wrenching shift.

It’s also a way to transform to a wholesale model, if that’s the goal.  Operators’ resistance to higher-level services seems to be related as much to discomfort with the retail sales-marketing model for those services as to the creation of the services themselves.  NaaS could provide operators with the appropriate experience.

If, that is, vendors provide them with the tools and guidance.  Operators in general seem to believe that they’re bombarded by two opposing forces, the network vendors who want them to stay the course and suck up the declines in profit per bit so they can keep buying gear, and the transformation players who want them to quit the connection business and compete in the OTT space.  They’re not excited about either option, for obvious reasons.  Is there a solution that they can adopt?  If there is, then the cloud infrastructure vendors, the IBMs and Dells and HPEs and Red Hats and VMwares, will probably have to step up and make that solution clear and credible.  Otherwise those hundred thousand data centers are lost.

Ericsson says it will embrace Open RAN, via its “Cloud RAN” initiative.  That’s big news because Ericsson is a bit behind others in embracing the new open model.  But Nokia is planning a restructuring that’s not getting raves from analysts, despite having taken a positive Open RAN stance well before rival Ericsson.  Just how disruptive is the Open RAN model, then?  Is adopting an open-model network a sentence of chronic business illness for network equipment vendors, preferable only to the death sentence that not adopting it would impose?  Does Open RAN have what financial analysts call “Mo”, meaning “momentum”, as some articles suggest?

From a competitive perspective, and from a margin-protection perspective, network equipment vendors who provide mobile infrastructure have focused on the notion of a unified, integrated, mobile deployment, spanning everything from the broadband gateway to the radio network, the RAN.  Even data networking giants have been disadvantaged by this vision, because they’ve lacked the necessary 3GPP elements.  The RAN is a particular problem because of the skill specialization associated with the radio network.

Open RAN (or OpenRAN, whichever you prefer) is an initiative to address the RAN piece of the open-model puzzle.  The goal is to open up the RAN elements for best-of-breed competition, by defining an architecture model with specific interface points.  Logically, then, the best response for a mobile network equipment vendor to take would be one where they could present a best-of-breed solution that’s still “open”.  Like most network standards and models, Open RAN doesn’t dictate the details of application structure, or of the implementation overall.  You’re “open” if you meet the interface requirements.

The reason this is important to operators (and so, to vendors) is that a big part of 5G capex will be in the RAN.  If capex costs can’t be managed there, then there’s a good chance that there’s not much that can be done for capex overall.  Not only that, because you need a RAN in 5G before you need much else, it may well be that Open RAN initiatives will impact the early 5G strategy of operators, and follow along into the rest of 5G infrastructure, and perhaps into network infrastructure overall.

Ericsson and Nokia both seem to recognize that the trick is to be open but not to surrender all differentiation.  Both companies have phrased their support primarily in terms of supporting the interfaces, which is essential to be “open”, but which leaves them with a lot of wiggle room for differentiating with what’s inside those interfaces.  Let me illustrate with a reference I’ve made in the past.  Google’s B4 backbone is an SDN backbone network inside a quagga BGP “emulator” layer.  The interfaces are standard and open, but how the network works under the covers is both invisible to the outside and under the control of Google.

Ericsson’s differentiation strategy might well be emerging just in the name of their approach—“Cloud RAN”.  The term is unfortunate, perhaps, because it also refers to a China Mobile initiative called “C-RAN” or “Cloud RAN” or “Centralized RAN”.  In any event, Ericsson uses the term, and they also promise that they’ll be “cloud-native”.  While we all know by now that cloud-native claims are a dime a dozen in today’s hype-driven market, it does suggest that Ericsson thinks that the fact that they’ll cloud-host their solution to Open RAN is critical.  Some of that, of course, is just riding that hype wave effectively, but there may be more underneath.  One almost-hidden piece of Ericsson’s strategy is that they do not intend to support open fronthaul.

Nokia has been forthright about the “why” of Open RAN, most recently on their earnings call, where the CEO said “Telco operators will continue to need to support massive capacity demands without commensurate cost increases. As a result, we expect capex to remain constrained as operators will look to drive a step-change in cost effectiveness…The broad trend towards open architectures with increasing virtualization will accelerate. This will be driven by cost pressures as well as the need to increase speed and agility. Adoption will vary widely and a full transition is more than a decade away, but the shift to more open interfaces, virtualization and cloudification, network function disaggregation, AI-driven automation and optimization, is well underway.”

What this translates to is an admission that because of profit-per-bit compression, operators are constraining capex until they can adopt cheaper open-model solutions.  The question is what those solutions will look like.  While 5G specs generally admit to “virtual” or “cloud-hosted” solutions, they could be applied to white-box configurations too.  AT&T, in fact, is looking more to white-box RAN than to cloud, and they’re arguably the operator furthest along in the open-model networking space.

Nokia is also focusing on “Cloud RAN” and it says it’s going to support the full suite of Open RAN, Cloud RAN, and O-RAN stuff, including the fronthaul interface.  Nokia is also very active and very vocal in the Open RAN space overall, though the fact that Ericsson had a late start may explain its less-promoting approach.  Substantively, there’s not an enormous difference in their approaches, which opens the question of why Nokia has to restructure and Ericsson (who’s doing better) doesn’t.

Part of the issue here, according to operators, has been that Ericsson is said to have superior execution.  That may be due to the fact that it had a strong proprietary product line that was available for early deals, and had strong sales engagement in no small part because the sales organization understood everything well.  Nokia’s earlier Open RAN commitment might have complicated their own engagements by introducing an open-network approach that buyers might like but that raises a lot of questions.

Paramount among those questions is whether a vendor’s open-model approach means just opening those interfaces, offering their support in their own products but not really pushing on an open strategy overall.  Could Nokia’s sales organization have inadvertently fallen into a trap with the early Open RAN story, raising the possibility that Nokia was going to take a more 5G RAN integrator path forward?  Could Nokia actually be considering that?

What I think might be the problem with Open RAN overall, right now, is that it isn’t nearly as compelling if you can’t assume it marries to “Open Core” in 5G.  We don’t have final 5G Core specs at this point, and the 3GPP is admitting that Release 17 probably won’t be available until 2022 due to a loss of effective collaboration created by the virus.  Quite a bit of early 5G effort has focused on the 5G Non-Standalone (NSA) approach, which combines 5G RAN with 4G IMS/EPC, which is not exactly open.  How a delay in Release 17 might impact full 5G Core availability, open and proprietary, is hard to say at this point.

And, of course, there’s long been a concern that many of the 5G Core features, like network slicing, might be a solution in search of a problem.  How far, and how fast, these native 5G features could drive the market will depend less on standards than on market opportunity.

What about “Cloud RAN” overall?  Nokia quotes an analyst as saying that Cloud RAN is transformational, adding things like agility and dynamism in service creation.  I think this point is one of the many in our modern tech market where what could happen and what will get a bit blurred.

Where are these new services coming from, and what’s their relationship to 5G itself?  If we presume that the services are coming from above, from over-the-top elements, then why is Cloud RAN a factor at all?  If those agile, dynamic, services are part of 5G, isn’t that the same standards set that’s not even been able to deliver on its core schedule?  How dynamic and agile can you be if you depend on standards to drive your technology, or what value is dynamism and agility in feature formulation, if your features are locked to a glacial process?

The 5G stuff we should be watching, then, isn’t the stuff from mobile vendors like Ericsson or Nokia, but stuff from players like Samsung, Red Hat, VMware, Microsoft, Amazon, Google, Rakuten Mobile, Dish, and other non-traditional players on both the vendor and operator sides.  It’s likely that both Ericsson and Nokia have supported Open RAN (and will support further open initiatives) more for objection management.  Mobile networks are ecosystems, and a traditional vendor can’t lose to a concept, they have to lose to another seller of ecosystems.  Blow a kiss at openness, and rake in the bucks while vendors who want to build on it assemble and integrate the pieces, then learn to sell them.

That ties in with operator comments that Ericsson was simply more effective at the sales level.  It’s sales effectiveness that will decide 5G winners, unless the operator buyers themselves commit to an open-model 5G network and are prepared to work with non-traditional players in non-traditional ways.  That why I’m listing all those non-mobile-vendor people as the ones to watch.  If they come up with a 5G approach that’s open, credible, and complete, then it’s going to be tough for the mobile network vendors to compete without facing significant commoditization.