The Microsoft purchase of Affirmed Networks is yet another indicator that much of the transformation operators plan will be implemented not on “carrier cloud” but on public cloud providers. This might be very bad for vendors who’d hoped to fill all those carrier cloud data centers with equipment and software, but good news for 5G. The operative word, of course, is “might”.
Affirmed Networks is a virtual-mobile-infrastructure player, in somewhat the same space as Metaswitch, a company I’m familiar with from the older days of NFV. They provide both current 4G mobile network and 5G network support, and also offer mobile-edge computing, IoT, and WiFi virtualization. In my analysis of carrier cloud, the mobile space accounts for about 16% of the total opportunity driver through 2030, and for almost 20% of the driver in the next three years. Of the “traditional” or “evolutionary” drivers of carrier cloud, the ones that relate to services network operators already offer and are comfortable with, it’s the best of the near-term lot.
That makes mobile services particularly critical to carrier cloud, because without near-term deployment support, the less-comfortable application classifications, including IoT and contextual services, would have to justify the early carrier cloud data center buildout, which my modeling says would be unlikely.
Operators liked the idea of a carrier-cloud-hosted mobile network because it would generate more competition and lower prices. The challenge has always been defining exactly how one created the software, and for that, operators have depended on vendors. All the major mobile infrastructure vendors (Ericsson, Nokia, Huawei) have their strategies, and innovative players like Affirmed and Metaswitch do too.
Mobile cores work pretty much the same way at the functional level, meaning that they accommodate the fact that smartphone users and other mobile users have to be reached in the cell they’re currently located in. The packets addressed to a phone have to be routed to the cell site, not the phone directly. This is handled through the use of tunneling between the packet network gateway (to the Internet) and the cell sites. This process is facilitated by mobility management and registration, and of course by the tunnel management.
The big difference between 5G Core and the 4G Evolved Packet Core is that the latter is based on the traditional “network appliance” model. Virtualization and hosting are fine, but you virtualize/host the software instance of the appropriate EPC device. 5G Core is based on a service model, wherein physical interfaces or ports give way (at least in terms of specification) to APIs. A service-based mobile core is of course more elastic and resilient, and it fits better with the notion of network slicing, which creates what are effectively virtual mobile networks on top of a single set of radio/backhaul/network facilities.
It’s easy, though, to lose sight of the forest of carrier cloud servers in the trees of mobile function software instances, so to speak. The big capital investment for mobile operators would be the carrier cloud data centers. Since we’ve seen (and I’ve blogged about) a growing number of partnerships between operators and cloud providers that at least suggested the former might be very happy to offload carrier cloud data centers to the public providers, it’s not surprising that one such provider, Microsoft, has bought a mobile infrastructure function player in Affirmed Networks.
Any cloud provider should love the idea that they might be the recipient of carrier cloud data center outsourcing, and all the more so if they could support operators’ outsourcing entire carrier cloud applications. Microsoft should love the idea more than most, perhaps, because mobile network functions are not direct enterprise services but services that enable other services—mobile communications, in this case. Any public cloud provider would be a credible option to host them, because it’s not likely the implementations would require any of the web services that cloud providers use to differentiate their specific hosting options. Google, eager to elbow its way to the top 2 or the absolute top of the cloud market, would be especially eager.
Cloud players would love mobile infrastructure software wins for another reason, which is the already-noted point that 4G/4G infrastructure was the dominant driver for carrier cloud deployment through 2023. If network operators outsource the 5G function hosting to cloud providers, that largest driver of deployment for carrier cloud disappears, making it much more likely that operators will at least start their later-developing carrier cloud projects in the public cloud instead. Then, of course, it’s more likely that those projects will stay in the public cloud, which will then make it harder to start the next wave on carrier cloud infrastructure. That could shift most of the carrier cloud applications to public cloud providers.
All of this raises an interesting question, though. Do the public cloud providers have a truly effective implementation of the kind of function hosting 5G would drive? We hear about “cloud-native” all the time, but there’s no broadly accepted definition of what the term means, and no objective way to apply it to products whose details are not available for inspection. A big part of the problem is that when we’re talking about infrastructure that’s shared among multiple users, there are multiple layers in even the term “service”, which obviously impact service lifecycle management.
Back in the 2000s, the first body I know to have encountered this issue took up the debate. The IPsphere Forum, responding to the interests of the EU operators who were members, started to look at how the principles of IPsphere could be applied to mobile/IMS/EPC. The paramount question was what the “service” was. Clearly, doing lifecycle management on individual mobile calls wouldn’t be practical. Do you do lifecycle management on customers/phone numbers, or do you lifecycle-manage IMS/EPC itself?
The view that emerged was that the “service” in a shared-infrastructure relationship was collective, meaning that you applied lifecycle management to the components of the infrastructure and not to the commitment those components made to individual customers or customer experiences. I think this is how 5G would have to be supported too, but that decision would seem to disconnect 5G from the concept of “service modeling” and a “service contract” that I’ve always said was the centerpiece of modern thought on service lifecycle management. What does the TMF concept of the “NGOSS Contract” mean to the collective 5G core?
In my ExperiaSphere project, I called these collective network functions “foundation services” because, once deployed, they became a part of the infrastructure. Foundation services, IMHO, look more like applications than like network functions in the familiar sense. You don’t deploy a bank deposit and check application (“demand deposit accounting” or DDA) every time someone makes a deposit or cashes a check. It’s there, available for use. The same would be true of mobile-network-related functions from 4G (IMS/EPC) or 5G (Core). Thus, there’s less a TMF-like service contract for them than an application model.
There’s no reason why this application model couldn’t serve the same role as that NGOSS contract, though. A lot of the elements might not seem to make sense (there’s a commercial side and a resource side to the TMF data model), but if you think about the notion of network slicing, you could see that a slice might well have a commercial side and a resource side. If you want symmetry, you could say that the commercial side of an on-us service would be a null, but the central point of the NGOSS contract approach is the fact that the “contract” mediates between events and processes, and so it defines how lifecycle management works.
The design of this event-coupling piece will, of course, determine the way the processes have to be developed. If, as I’ve presumed in ExperiaSphere, the processes are fed their portion of the data model when they’re activated, then the processes have all the information they need to run. To paraphrase programming nomenclature, result=functionof(inputs). There is no dependency on data stored by the function, so it doesn’t need to store any, and that means that the processes can be true stateless functions, or lambdas, or microservices, depending on what term you like.
This is what would be needed for an implementation of a 5G core to be “cloud-native”. You need stateless processes that can be spun up or replaced as needed. You need to have some mechanism for orchestrating these processes through stateful analysis of event streams. The model approach provides all of that.
What’s not clear is whether Affirmed used the model-and-function approach. If they didn’t, then Microsoft would have to do what might turn out to be a significant amount of software maintenance to create something that’s cloud-native. If they didn’t, they would risk having a competing public cloud provider build a solution for 5G that’s clearly better.
It’s possible Microsoft would take that risk. It’s possible Microsoft would expend the effort needed to optimize Affirmed’s stuff for 5G. It’s possible they don’t even care about 5G and bought Affirmed for another reason (I doubt there is another reason good enough, but hey, it’s their company). We’re not going to know all the details till we see more of what Microsoft does with its new acquisition, but carrier cloud could justify a hundred thousand global data centers, it could sure boost revenues for public cloud providers too. If there’s a race among public cloud providers to get 5G and other carrier cloud applications implemented, we might see progress a lot faster than we’d see if we waited for the telcos or their traditional vendors.