The cloud will not simply be part of the 5G network, it will be a foundational element; the network will be “cloud native.”
As we get closer to a full 5G 3GPP specification, it is clear that the cloud will not simply be part of the 5G network, it will be a foundational element; the network will be “cloud native.” This became apparent in later releases of the 4G spec, including release 14, in which certain cloud and virtual architectural options began pointing toward a preferred direction on the road to 5G.
As I highlighted in a previous article, 5G services such as augmented and virtual reality, HD video, IoT, and critical machine-to-machine communications (MTC, or sometimes just M2M) such as autonomous vehicles and industrial automation, will be more varied than traditional network services. Some services will have more stringent requirements in terms of bandwidth capacity, latency, and reliability, while also being less predictable in terms of demand, location, revenues, etc. Existing call models simply won’t apply.
Access networks are those that connect subscribers to their communications providers; the core is comprised of the networks that connect the providers. Access networks are being virtualized so that they are programmable. In order to respond quickly and adapt to changing service demands and requirements, the new 5G core must likewise be programmable.
A key attribute of this programmable core is support for network slicing – the ability to logically isolate segments of the networks. This will enable network resources for access, transport/backhaul and core to be dynamically allocated either vertically or horizontally.
Vertical slices will support a specific service or set of common service characteristics (e.g., narrowband-IoT, non-IP data, power-savings mode devices). Horizontal slices can be reserved for specific enterprise customers, for instance a public utility (think smart grid or intelligent transport systems), or a private company’s extended intranet. This sharing of a common pool of network resources through programmability and network slicing is more efficient and cost effective than building traditional overlay networks or over-engineering the network capacity to account for unpredictable spikes in demand.
In order to meet these new service requirements, the 5G core must be built from a cloud-native design. That involves taking the best practices, concepts and technologies from the IT and webscale environment and applying them to the design of the core network. A simple software upgrade of the existing packet core into a virtualized environment won’t do.
User and control plane separation
In today’s mobile network, the mobile gateway (GW) performs several functions in the data path between the applications/services and the end user device. It performs as the serving gateway (SGW) and/or packet data network gateway/gateway GPRS support node (PGW/GGSN) — as the user device anchor point and the packet forwarding function. It can also perform the traffic-detection function (TDF) for packet inspection and traffic classification.
These functions will be instantiated in software – they’ll be virtualized. Virtualization enables one of the key features of the cloud-native core architecture – the complete separation of the control and user plane functions within the mobile gateway. In 3GPP release 14, this feature is specified as control/user plane separation (CUPS) in the evolved packet core (EPC) nodes (TS 23.214).
With this feature (Figure 1), the mobile gateway function essentially splits into two: the gateway control (GW-C) function, which handles session/bearer and IP address management for end-user devices, as well as signaling communications between itself and the other core network functions; and gateway user (GW-U) functions, which do the packet forwarding, marking, deep packet inspection, policy control, lawful intercept, and charging. In a virtualized environment, the GW-C and GW-U would be separate virtual network function (VNF) instances.
With the CUPS architecture, the GW-C and GW-U can be independently scaled and located wherever they are needed. Depending upon the architecture and requirements of the core network, these functions can also be separate or combined within the same virtual instance.
As shown in Figure 1, the GW-C can interface with more than one GW-U function. The communication service provider (CSP) determines which GW-U is selected by the GW-C. It will either be dynamically selected, based upon load, or can be statically configured, based upon various parameters such as capacity, location, or access point name (APN) that match the specific user-device session. This gives the CSP the deployment flexibility to select, from the available pool of GW-U resources, one that meets the requirements of that service, which could be either a virtual or a physical function (Figure 2).
With 3GPP Release 15, the new 5G core reference architecture is defined (TS 23.501). In this release (Figure 3), a new session management function (SMF) is defined, which combines the session management of the mobility management entity (MME) and the GW-C in the Release 14 CUPS architecture, plus additional features to support Ethernet PDU sessions and determine the session service continuity mode and other policy-related functions.
Likewise, in Release 15, the user plane function (UPF) is the anchor point for mobility and external session connectivity to the data network. It also handles the packet forwarding and QoS (quality of service), packet inspection, policy rules enforcement, traffic usage reporting, and lawful intercept.
[Continue reading on EDN US: Key differences between 5G and 4G]
David E. Nowoswiat is a Senior Product and Solutions Marketing Manager with over 25 years of telecom industry experience in both wireless and wireline technologies. He is currently in Nokia’s IP and Optical Business Group supporting cloud and 5G next generation packet core Marketing.