Migration to Cloud-Native 5G Core

One of the major issues for the mobile networking industry going into 2020 is the deployment of 5G core networks and the migration to 5G standalone operation. One of the major issues for the mobile networking industry going into 2020 is the deployment of 5G core networks and the migration to 5G standalone operation. There are several reasons why this is important. First, it is to support new service types -- for example, services such as ultra-reliable low-latency communications, network slicing, edge services and converged access. A second reason is to modernize network infrastructure and operations -- which means cloud-native, SDN, edge compute/cloud, API-driven operations, automation and so forth. As I discussed at our recent 2020 Vision Executive Summit in Vienna, we should think about 5G core in terms of a system and services strategy. This means thinking about RAN, about devices, about transport and about integration with cloud providers. These domains need to be aligned and integrated for the 5G system to deliver the desired services. In the migration from 5G non-standalone, anchored and controlled by an LTE host network, to a 5G standalone network controlled by a 5G core, the industry has standardized several options -- known as Options 3x, 4, 5, 7 and 2 -- in Release 15. I've taken soundings widely across the industry over the past two years on which of these has most ecosystem support and will be deployed commercially. Right now, as I outlined over a year ago, the industry has settled on two options, Option 3x, deployed for non-standalone 5G, and Option 2 for standalone 5G. As today’s commercial deployments show, Option 3x works well where operators have limited 5G coverage and has a relatively small impact on the core network infrastructure. From here, operators can migrate directly to Option 2, where the devices connect directly to a 5G core over a 5G radio. Options 4, 5 and 7, for one reason or another, haven't been adopted by the industry and don’t currently have support from equipment vendors, or from chipset and device manufacturers. I wouldn't rule out that they come back at some stage -- we may see an Option 5 or Option 7 at some point in the future -- but that doesn't look imminent. Option 2 requires extensive radio coverage and so is dependent on the operator’s RAN strategy, which is in turn dependent on spectrum. Most operators with live 5G have deployed in highband or midband spectrum. Highband (mmWave) is unlikely to work for standalone with a 5G core outside of areas such as stadiums or factory facilities where signal can be reliably provided across the service area. Midband spectrum -- for example, 3.5GHz, 2.6GHz and 2.5GHz, depending on the market -- can work for 5G standalone in wide-area outdoor networks, but will require dense basestation deployments to deliver good enough cell edge and uplink performance. Probably most common will be to deploy a 5G core in association with lowband spectrum -- e.g. the 600MHz, 700MHz or 800MHz bands -- either deployed as fresh spectrum or in existing lowband re-farmed from prior generations. Dynamic Spectrum Sharing (DSS) is an attractive option for lowband LTE/NR sharing and will one of the most important 5G developments in 2020. As of right now, DSS technology is working in the lab and in field trials but isn't quite yet available commercially. Regardless of radio strategy, it is clear the 5G core should be "cloud native" (which, at the moment, means containerized micro-services deployed on bare metal and managed by Kubernetes). But how will this be done? In many cases I think we'll see operators deploy 5GC as an overlay, perhaps with a view to moving to a converged 4G/5G core over time. For early deployments this is likely to mean containerized 5GC applications deployed in VMs on the same infrastructure used for 4G core. This may sound perverse, but from an operating point of view it is probably too early to go direct to bare metal. Operators now have stable virtualized infrastructure capable of running virtual core at reliability levels required and it would make sense to re-use this platform for 5GC. Given also that 4G core applications are to date virtualized, but not containerized, and there are tight links between 4G and 5G core, this looks the most obvious strategy for initial deployments. It may make sense, at the edge, to go direct to bare metal containers because operators don’t have existing platforms to re-use. The intent, of course, is to move network-wide to cloud-native 4G and 5G core over time. This content is sponsored by Huawei. — Gabriel Brown, Principal Analyst, Mobile Networks & 5G, Heavy Reading