Everything seems to be a trade-off, particularly with technology. Planners and CIOs are always balancing risk and reward, upside and downside. One place where that balancing act is especially important is in 5G, and especially 5G’s RAN, New Radio or NR. I’ve noticed that telco planners and some of the vendors engaged with them are starting to realize just how critical striking the right 5G RAN balance is, but most still don’t see their risks and rewards fully.
We’re hearing about two aspects of the 5G RAN trade-off in the tech media. One aspect is the O-RAN versus proprietary 5G RAN, though right now most vendors seem to be coming down on some open-model approach (except Huawei). The other aspect is the public-versus-carrier-cloud deployment, and that one is just getting started.
Mixing with these two factors is the release of a position paper outlining the “requirements” of a dozen big telcos. The paper seems on the surface to be a good thing; why not get buyer requirements for a change instead of pushing the sale of whatever was convenient to create? The problem is that the telco buyers have historically been inept at stating their own requirements, and this document is no exception.
I’ve worked with the telcos for decades, and for the last two of those decades they’ve been guilty of multiple-personality-disorder thinking with respect to open technologies. On the one hand, they hate vendor lock-in and thus tend to support things like white boxes and open source. On the other hand, they hate integration, so as soon as they have an open model to play with, they demand somebody single-source the integration of the components. Some of my telco friends tell me that this is different; they can always demand the integrator change out a piece they don’t like, and they can change integrators. I’m not sure about that line, but let’s move on.
The logical response to a buyer community that wants openness in order to somewhat-close it is to make a commitment to open-model yourself and provide your own “open elements” in critical places. Other than Huawei, who seems bent on keeping their original business model of proprietary gear, this is the approach that seems popular in the 5G space. Both Ericsson and Nokia have taken this tack, though it appears that Nokia has been more aggressive in their moves, and taken things further beyond the pretty-billboard PR starting point.
Ericsson and Nokia have two advantages; they are incumbents who know the telco space well and who are well-known in it, and they understand the challenges 5G evolution poses for operators because they’ve provided much of what operators are evolving from. No little player could hope to address either of these points, important as they are to operators. Only a giant non-traditional network vendor could have a shot.
There’s no shortage of players who’d like to be that giant non-traditional supplier. On the cloud software side you have Red Hat and VMware, in hardware you have Dell and HPE, both of which have software bundles they can link with their hardware. In this space (so far), I think VMware has the best initial position, but they’ve been preoccupied with executive changes and they’ve not moved as fast or positioned as aggressively as they should have. Thus, there’s a little wiggle room for others to creep in, providing they are truly aggressive in contrast, and that they do their thing before VMware gets its management act coordinated.
There’s another option, of course, and it opens the second of my two media-visible 5G RAN aspects, the role of the public cloud versus carrier cloud. If you want open technology in a pre-integrated form, and if you want to avoid vendor lock-in above all, what better option could you get than 5G-as-a-service? In fact, this approach is getting so much traction (and publicity) that it’s spawned a secondary trend, which is a kind of “5G commune” where operators share a single 5G deployment, presumably sliced in conformance with 5G specs, and whoever builds that collective network bears the risks.
Some players, like the antenna providers, are logical entrants in this second space. Others, like IBM and Cisco, are rumored to have looked at the approach, seeing it as a kind of managed-service network that (in Cisco’s case) would be congruent with their expense-everything-as-a-subscription-service approach. But let’s return to the real giants here, the public cloud providers.
Public cloud providers could theoretically mix all the model options for 5G. They could host arbitrary functionality the operators provided, they could provide their own software functionality and then either let the operators host it, or host it in their own (or someone else’s) cloud. They could also offer hosted 5G-as-a-service with or without shared network resources and slice-based tenant separation.
Microsoft may be the one who’s thought about this all the most, and taken the most steps to realize all the options. They’ve done some serious M&A (my favorite 5G software player, Metaswitch, was one) and they’ve talked up hosting operator 5G, but they still sell the software they’ve acquired. I’m also getting serious indications that they’d like to offer a shared-by-slices 5G model, and that they’re more serious than rivals Amazon and Google.
In a way, all this happy explosion of choices of supplier and form of service could be compromised by the buyers themselves, specifically that requirements paper. Apart from the fact that the paper isn’t the best piece of technical composition the world has known, it’s also suggesting things that would tend to pull O-RAN away from the cloud and more into the world of NFV and ONAP. This might play well in Europe, the source of the paper, but I’m not hearing hymns of praise for that in other market geographies. One Asian operator told me that “This looks like an attempt to guide and promote O-RAN by burying it in bureaucracy”.
That’s the biggest issue facing open-model networking in a nutshell. The future of networking is the cloud, period. Operators, at the planning levels associated with their standards initiatives, don’t get the cloud, period. To the extent that they attempt to assure their real issues are covered in a cloud migration, they introduce box-network concepts to explain those requirements and move away from the function-network concepts that they should be embracing. For the vendors who want to see O-RAN and open-model networking succeed, countering this unfortunate bias is the most important thing they’ll need to accomplish, both in product design and in positioning.