If you read my blog yesterday, you know my views on the importance of making telecom software into hosted functions. You might then think that the Ericsson/Google pact, covered by Light Reading, is proof this is already happening. A few have asked me about this, but I respectfully disagree with the “already done” theories.
A simplistic view of 5G’s infrastructure would divide it into three pieces. You have the actual towers and radios. You have an on-ramp to the “public network”, and you have the mobility management piece in between. This last of the three is divided into a control plane and user plane, with the latter carrying the traffic. You could say that the gateway, end-piece, here is the 5G Core. And, as it happens, this is what the Ericsson deal with Google is providing, as Ericsson’s own release on the deal shows.
5G Core isn’t in the scope of Open RAN, or involved in the real meat of mobile networking, the other two pieces of the pie. What the deal is focusing on is the UPF, the User Plane Facility, of 5G Core. This doesn’t mean that the deal isn’t useful or perhaps a critical step, but it does mean that critical 5G features, both in the sense of importance to mobile network operation and in the sense of having stringent latency requirements, aren’t covered. That’s not surprising for two reasons.
One reason is the not-often-cited issue of competitive market behavior. Does Ericsson want to surrender infrastructure for 5G hosting completely? Not hardly. Embracing Open RAN is one thing, but embracing a model that allowed providers to pick cloud feature/service elements on a best-of-breed basis is problematic for any of the major mobile network vendors, whose control of the market has depended on buyer unwillingness to self-integrate their infrastructure.
The other reason is latency. The outer layers of 5G functionality, close to the actual radios, are often latency-sensitive. Open RAN’s RAN Intelligent Controller (RIC) has a non- and near-real-time component, the latter being for those latency-sensitive functions. In most public cloud 5G missions, these outer layers aren’t run in the cloud at all, but rather run on telco premises using cloud-extension devices that run cloud provider platform tools. In short, you need edge computing, not cloud computing, to host these things, and we don’t have public edge services at this point.
The UPF is a logical place to inject public cloud, because the User Plane in 5G is where user traffic flows, and because the cloud is a logical point for an on-ramp to global connectivity could be hosted. Google, in particular, has an enormous private network with global reach, and provides content hosting and other services itself, and Google Cloud can draw on these facilities on behalf of what it hosts. So there is value here, but the deal isn’t moving 5G to the cloud…yet. Will it? That depends on implementation, which is only slightly malleable in 5G and not yet defined for 6G.
One thing I think is essential is to recognize that everything in the User Plane of either standard should mandate handling with ordinary IP routers, not any augmented appliance. If there’s a need to provide a User Plane link to the Control Plane for things like mobility management, the link and protocol should be standardized by the IETF and incorporated in routers.
The second thing is that all the features and functions for the Control Plane should be defined as hosted components with APIs. The hosting requirements should be explicit, including any delay/latency constraints, but the responsibility for meeting those requirement should be part of the hosting platform software and not part of either generation’s standards. We should not have a RIC at all (of course we do in 5G Open RAN, but we’ll get to that).
For 5G RAN, we should break out the non- and near-real-time stuff so that the former can simply be cloud-hosted using traditional platforms/tools and the latter offered as middleware for a low-latency hosting option. If coordination between the two is needed, that coordination should be provided as part of the low-latency middleware.
I don’t think any of these things present a realistic technical barrier, but there are surely market/competitive issues. The most profound are that the 3GPP is, like most bodies, really vendor-dominated because vendors fund their work in it better than operators do. Further, big vendors have more money, more at stake, and more technical resources to make available. Things like Open RAN are really confederation of the second tier, and since the basis for their suggestions is the standard itself, they may find there’s limited support for any real original work left to them. That’s been the case with 5G.
My own personal preference, based on my experiences with things like ExperiaSphere, is that a user in 5G or 6G is represented by a database entry. This entry defines its state and links to all the functions that the network provides. Anything that changes its state has to update that entry, and the entry is hosted by the network operator entity that currently controls the user’s connection. This could, as I noted in a previous blog, necessitate a lag in service functionality when a user moves to a different cell or even a different access method, but at this point, almost everyone is familiar with the symptoms of this sort of lag in everything from calls to content delivery. Buffering, anyone?
The alliance doesn’t deliver what some have claimed it does (note that neither Ericsson nor Google do), which is cloud-based 5G, but value of the Ericsson/Google deal is that it could lead to consideration of the technical paths to actually and fully hosting a RAN in the cloud. But just how it might do that isn’t really clear. Will other cloud providers jump in to propose a broader strategy, or will the others simply continue to rely on their own “hybrid” model that uses outpost-servers on premises (in this case, telco premises)? Could O-RAN do something, now or with 6G? And finally, do we really need “cloud RAN” or just a cloud-centric model for future service hosting, something that could arise in many ways? We’ll have to wait to see how this develops.
