Mục Lục

Architectural Tenets of the 5G Core Network

The evolution of the packet core network from the current 4G Evolved Packet Core (EPC) to the next generation 5G Core Network (5GCN) is transformative.

On the other hand, the voice core network – IMS (IP Multimedia Subsystem) remains largely unchanged, while the packet core network has been re-imagined.

The 5G packet core has been conceptualised to support three major classes of services, namely:

a) eMBB (Enhanced Mobile Broadband)

b) mMTC (Massive Machine Type Communications)

c) uRLLC (Ultra Reliable & Low Latency Communications)

In this article, we review some of the important architectural tenets which drive the core network design.

1. Reference Points & Service Based Interfaces

The 5G core network has been conceptualised as an interconnected system of Network Functions (NFs), which share service based interfaces.

Each network function “exposes” certain functionality and provides services to other network functions – who are the consumers of its service.

The service-based interfaces follow the RESTful paradigm in spirit.

Reference points on the other hand are the formal 3GPP based interfaces completely defined with metadata information that any two network functions share with each other.

While both these concepts are logical in nature, service based interfaces provide the architectural flexibility to consume the “services” being provided by network functions. The producer and consumer facets of the network services are represented by a single service based interface – making it a bi-directional interface.

As shown in the figure above, service based interfaces are labelled as follows:

CAPS “N” prefixed to the short form of the NF

Example: Nnef, Nausf etc.

2. The intra-core network protocol HTTP/2 & the rise of the 5G NRF

One of the most important changes in the core network design has been to retire the DIAMETER protocol.

While in the EPC, intra-core network communication was dominated by the DIAMETER protocol, which in turn was multiplexed through the DRA (DIAMETER Routing Agent) – the 5GCN completely re-architects this design.

A new communication protocol – HTTP/2 has been introduced in the network. While the name of this protocol resembles with the older versions of HTTP (1.0,1.1 etc), the semantics of this protocol fundamentally differ from the older HTTP.

The HTTP/2 protocol was inspired by the SPDY protocol originally developed by Google. At the heart of the protocol design is how it frames information and transmits it.

While HTTP works on a request/response exchange on a TCP connection, the HTTP/2 protocol is completely asynchronous in nature. It allows the server to “push” information to the clients.

HTTP/2 is a binary protocol, as opposed to the text based design of HTTP 1.x. It efficiently streams data between the client and the server, and supports header compression and encryption.

The RESTful interfacing paradigm is interleaved with the HTTP/2 protocol to arrive at the service based interfaces of 5G.

The communication between the Network Functions is no longer multiplexed through a central entity such as a DRA.

The 5GCN introduces the concept of “Network and Service Discovery”. The discovery service is provided by the Network Function Repository Function (NRF). Network Functions register themselves with the NRF, which maintains the overall inventory of active network functions. Other network functions can “discover” services and functions by interfacing with the NRF.

Once the Service Based interface and the NF is discovered through the NRF, the network functions can communicate with each other over HTTP/2.

This design “removes” the dependency of a DRA-type entity which always needs to be in the path of communication between network functions.

3. Control & User Plane Separation (CUPS)

Telecom networks have always had the concept of a control plane and a bearer plane.

As a matter of fact, even in 2G core networks – the Media Gateway Control Function (MGCF) and the Media Gateway (MGW) represented control & user plane separation.

However, in 4G packet core networks, this was not the case with S/PGWs – and certain vendors adopted CUPS at a later stage.

In the 5G core network, CUPS has been formally implemented through the SMF and UPF.

While the SMF is the control plane of packet switching, the UPF actually handles the user plane traffic.

4. Network Slicing

5G network elements will be virtualised by default and will be compliant to the NFV architecture. The specifications introduce another aspect of network tenancy, known as “Network Slicing”.

Network Slicing enables the operator to create dedicated resource pools for specific applications.

For example, Mobile Virtual Network Operators (MVNOs) can provide services in a 5G network through dedicated slices.

We can create slices for mMTC and NB-IoT for M2M services.

Mission critical services such as industrial automation can be served by a specific network Slice which is more latency sensitive.

Use cases may differ, but the 5G core network provides a standardised mechanism to create, maintain and scale-out network slices.

3GPP defines the NSSF (Network Slice Selection Function) as the central anchor point to orchestrate network slicing in conjunction with the PCF (Policy Control Function)

5. Quality of Service in 5G

In 4G EPC networks, QoS classes were represented as QCIs – Quality of Service Class Identifiers.

In the 5G network, the characteristics of the QoS model is similar , but there are certain differences and enhancements over the 4G QoS model.

In the 5G QoS model, we have QoS flows – which may be Guaranteed Bit Rate (GBR) or Non-Guaranteed Bit Rate (Non GBR) flows. This is similar to 4G.

The QoS Flow ID (QFI) is used to identify a QoS Flow in the 5G Network. Data Plane traffic with the same QFI within a session receives the same traffic forwarding treatment.

A given QoS flow consists of the following attributes –

a) QoS Profile

b) One or more QoS rules

c) One or more UL/DL PDRs

A QoS profile may be GBR or non-GBR in nature depending upon the application in question.

A given QoS profile consists of the following QoS parameters:

a) 5QI (5G QoS Identifier) – which defines and maps the QoS characteristics presented in the figure below.

b) ARP (Allocation & Retention Policy) – contains information about the priority level, the pre-emption capability and the pre-emption vulnerability, which essentially represents the “relative” importance of a resource. For example, when a new QoS flow is requested, it may be rejected in case of resource limitations in favour of a QoS flow with a higher ARP value.

c) RQA (Reflective QoS attribute for non GBR) – which signifies that the non GBR traffic is subject to Reflective QoS (explained later)

d) Guaranteed Flow Bit Rate (GFBR) for UL/DL

e) Maximum Flow Bit Rate (MFBR) for UL/DL

f) Maximum Packet Loss Rate (MPLR) for UL/DL

g) Notification Control – a parameter that tells the SMF to notify the PCF in case the GFBR can no longer be guaranteed.

The 5QI defined above further characterises the QoS parameters as a scalar, known as QoS Characteristics.

There are six QoS Characteristics of a 5QI –

a) Resource Type (GBR, Delay critical GBR or Non-GBR)

b) Priority Level for scheduling

c) Packet Delay Budget (PDB) (including Core Network Packet Delay Budget)

d) Packet Error Rate (maximum permissible)

e) Averaging window (for GBR and Delay-critical GBR resource type only) – duration over which the GFBR and MFBR are calculated.

f) Maximum Data Burst Volume (for Delay-critical GBR resource types only) – the maximum data volume that can be served in a given packet delay budget.

The possible 5QI granularities and Characteristics are denoted in the table below from 3GPP TS 23.501:

6. Reflective QoS

As mentioned above, one of the parameters of a 5G QoS Profile is RQA (Reflective QoS attribute).

Reflective QoS is a phenomenon where the UE derives the uplink QoS to be applied based on the downlink QoS information received from the network.

In order to apply reflective QoS, the 5G UE needs to support this feature.

Reflective QoS is applicable only for non GBR bearers and QoS flows.

7. State & Data Storage Architecture in 5G

While we are familiar with network elements storing state and context information for data sessions, we are also aware of the complexities associated with it.

When a network node stores transient state, it has an impact on its High Availability architecture.

The state for sessions and other information has to be replicated in realtime across the cluster of nodes. This leads to various race conditions during HA and failover scenarios.

5G provides a new network function known as the Unstructured Data Storage Function (UDSF). The UDSF provides service interfaces to store, update, read and delete network function data.

Due to the UDSF, other network functions such as the PCF, SMF and AMF can remain largely stateless.

Structured Data on the other hand can also be stored external to the NF. Structured data is defined as those attributes which have been specified by 3GPP in the respective procedures of a given network function.

Structured Data can be stored and retrieved from the UDR (Unified Data Repository).

The 5G System architecture allows the UDM, PCF and NEF to store data in the UDR, including subscription data and policy data by UDM and PCF, structured data for exposure and application data (including Packet Flow Descriptions (PFDs) for application detection, AF request information for multiple UEs) by the NEF.

8. Service Communication Proxy (SCP)

The SCP provides a single point of entry for a cluster of a given type of Network Functions.

When a network function deployment is discovered through the NRF, the entry point to the NF cluster is the SCP.

The SCP can also be configured as an exit point of traffic for a given Network Function cluster.

This allows the creation of a service mesh architecture between network functions rather than a point to point mesh architecture amongst hundreds of instances of network functions.

The SCP can perform additional functionality such as load balancing, auto failover, failback and can be the single entry point for a NF FQDN.

9. Network API Exposure via NEF

The 5G NEF has been positioned as a standardised entity to expose 3GPP service capabilities through APIs.

For this purpose, the standards have defined a northbound interface towards a generic Application Function (AF), and a southbound interface towards the various network functions of the 5GCN.

One of the primary use cases of the NEF is to integrate with the SCEF and IoT platform over the northbound interface to enable IoT services.

On the southbound, the integration points consist of the UDR, PCF, SMF and the SMSF (potentially).

10. Full list of 5G Network Functions (3GPP Release 16)

The complete list of 5G network functions is provided below for reference. It is possible that more network functions may be defined by the standards in due course of time –