Is it time to look beyond Open RAN? That question may seem strange given all the positive developments, including the story that Mavenir is looking to build radio units, but I think it’s the perfect time. In fact, it may be inevitable at this point that the focus of open 5G starts to shift.
One might ask why RAN (meaning 5G NR) had to be opened in the first place. After all, the 3GPP specs define functional elements with standard interfaces. The reason is that if you’re going to build something based on hosted functionality, you need to define more than just how the functional blocks connect. If the hosting part of the story is too divergent, then the elements may be able to connect with each other nicely, but won’t run on the same infrastructure. Goodbye openness.
Open RAN developed a framework for software-based RAN, which obviously competes with hardware or appliance-based RAN, and appliance RAN favors the big incumbent vendors. Those vendors point out that Open RAN is more work in integration because there’s more moving parts when you add hosting to functionality. Since the radio network needs radios, that marketing pushback from the giant network vendors is likely behind Mavenir’s decision to offer its own radios.
It’s hard not to see the same problem that drove Open RAN not driving open-model network principles deeper into the 5G core. The 3GPP defines functional elements there too, and there are just as many issues with hosting them. Some have suggested that because NFV is cited by the 3GPP as a requirement for function hosting, there’s no need for further work. To that, I say that NFV needs plenty of work in itself. Even the latest NFV specifications on how to make NFV cloud-native simply glues cloud-native elements into an NFV framework that wasn’t working particularly well (look at the onboarding and implementation issues for NFV for proof).
It’s pretty likely that Open RAN principles will be applied to 5G Core, to create (perhaps) Open Core, but because of the NFV association in the standards, it’s not quite as simple. Either we have to undo the NFV association, we have to somehow harmonize NFV with real cloud-native behavior, or we have to forget cloud-native and stick with NFV. The latter, I think, is a guaranteed failure. The second will take too much time, which leaves us with the first option.
As profound an issue as this is, it’s not the major challenge of Open Core (to use the name for convenience). The deeper you go into the mobile network, the more IP-like it becomes. The role of mobility management dips all the way into metro infrastructure, and if 5G really is going to increase network traffic and introduce the requirement for “slices” with specific QoS, then mobile issues touch everything in the IP network, through to the core.
My view here is that as 5G touches IP, the touch is going to come between the IP control plane and the 5G control plane. The 5G user plane is an IP network, and 5G (like earlier IMS/EPC specifications) is drawing on the IP network for service features that don’t exist in IP. For that reason, there are user-plane elements in 5G that are then controlled by the 5G control plane. The question is whether it would be more efficient to establish the “services” that 5G needs from IP as network-as-a-service features of the IP network. If that were done, then it would make sense to think about 5G’s control plane as merging with IP’s control plane.
If you look at the ONF’s recent Aether story, which is directed at private enterprise 5G, you find what I think are the justifications for Open Core, and also a model to support it. Not surprisingly, the ONF is building on its own programmable network model, which is based on SDN, but remember that ONF programmable networks can be said to be the model for producing NaaS. And it’s notable that Aether, in the ONF material, is divided into an “Aether Edge and an “Aether Central” pair, with the latter including (you guessed it) the mobile control plane.
It’s also notable, in my view, that Aether’s specific target is enterprise IoT, which happens to be the most stridently promoted public 5G application that would justify network slicing, and a full implementation of 5G Core. In a way, Aether is almost a case study for what I’ve been calling Open Core, aimed at IoT applications.
Mavenir already offers software-based 5G throughout, but they’ve not addressed as yet the potential in marrying NaaS and combining the IP and 5G control planes. That’s logical given that they don’t make SDN controllers and wouldn’t want to tie their 5G implementation to a massive change in IP infrastructure that they have no product stake in promoting.
Speaking of stakes, though, it’s interesting that the ONF is making such a strong statement on 5G and IoT in a private-5G context. There are a lot of possible reasons for this, and any one of them could be an indicator of a future revolution in 5G infrastructure design.
The first reason, and the one that’s most obvious, is that the ONF sees private 5G as a topic that’s getting a lot of media attention and just might actually be a major market opportunity. There are a couple thousand network operators but there are tens of thousands of enterprises. Not only that, those enterprises have no special loyalty to the big mobile infrastructure vendors, and they have a long history of accepting (even demanding) open source and openness in general.
The second reason is that the ONF may think it’s a bit late to take on established open 5G options in the operator markets. There are a number of established (if proprietary) vendors, a number of open-model players (including Mavenir), and public cloud provider interest too. Given that Aether, if it works for enterprises, would also likely work for operators, the ONF might be making an end run.
That circles us back to Mavenir. If there’s a lot of interest in fielding 5G infrastructure, open or not, then it’s more challenging to sell it as the field gets more crowded. Integration is always a big concern for open-model solutions, and so having its own radios is a way for Mavenir to address the multi-supplier finger-pointing challenge. It’s not a durable way, though. Do they then decide to build white-box switches? Evolve into being an Ericsson-like vendor? Or, do they need differentiation?
What makes all this especially complicated is that it’s hard to differentiate in an open-model space without looking like you’re not part of the open-model strategy. One of the things I think we can look forward to in 2021 is progress on the question of just how open networks are differentiated. I think the answer is going to come from the disaggregated plays of both startups like DriveNets and incumbents like Cisco and (most recently) Juniper. Whether the jousting will create a final answer can’t be known right now, but it’s going to be fun to watch.