5G

5G Core based on SBA,REST and HTTP2

Introduction

At the core of most modern networks and services is typically a cloud- and virtualization-based platform. This is also the case for 5G networks. These platforms are programmable, and allow many different functions to be built, configured, connected, and deployed at the scale that is needed at the given time.

The 3GPP defines a Service-Based Architecture (SBA), whereby the control plane functionality and common data repositories of a 5G network are delivered by way of a set of interconnected Network Functions (NFs), each with authorization to access each other’s services. Service-Based Architectures provide a modular framework from which common applications can be deployed using components of varying sources and suppliers.

5G Core SBA

Introduced to improve the modularity of the network system, SBA lets network elements or network functions (NFs) in 5G communicate with each other over a service-based interface. It allows the decoupling of NFs with more precise functionalities. Each NF provides a set of services to another NF in the SBA. These NFs communicate with each other using a more open REST-based interface rather than traditional telco protocols such as Diameter.

The SBA offers a host of benefits, including:

  • Deploys as containers orchestrated by Kubernetes, allowing the core to run on non-proprietary infrastructure.

REST and HTTP2 Methods

To be able to understand the messaging between various 5GC NFs, it is important to understand the concepts of REST and the various HTTP2 methods. Unlike 4G, most of the control plane signaling in 5GC is via HTTP2. The legacy protocols like GTPv2 and diameter are no longer carried
forward in 5GC. All control plane communications are via RESTful APIs using HTTPv2 methods.

What is REST?

REST is popularly defined as: “REST, or Representational State Transfer, is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other. REST-compliant systems, often called RESTful systems, are characterized by how they are stateless and separate the concerns of client and server.” – Roy Fielding in 2000

REST Principles

REST is a set of principles that is constructed around being able to be stateless, to be HTTP-based, and have a standard Create, Read, Update and Delete (CRUD) operation. To be able to have web-scale performance and efficiency, to be scalable, and to be generally simple, readable, and intuitive and client-server model based.

REST Principles

  1. Client-Server: A client-server implementation in which a 5G NF (which is the client) is requesting the service from the server to be able to correlate to the aforementioned concepts of SBA. RESTful APIs are the means by which the SBA is implemented. This is where the two converge, the client is the consumer and the server is the producer of a particular service.
  2. Stateless: The next guiding principle of REST is that the server does not retain any information sent in the request and is therefore stateless.
  3. Cacheable: This guiding principle outlines the fact that the service consumer should be able to cache the contents of the response from the server for use later. This improves the efficiency of the application.
  4. Layered System: With this principle the client is totally abstracted from what is beyond the contacted server. As an example, to provide the service to the client the server may, in turn, need to contact other servers, but this is completely hidden from the consumer/client. This makes the architecture simple.
  5. Uniform Interface:
    Uniform Interface REST principles are:
    Identification of resources: resources (documents, files, images) associated with a network service are uniquely addressed.
    Manipulation of resources based on representation: resources can be updated by a client through a standard set of operations.
    Self-descriptive messages: messages must contain all the relevant information required by a server to fulfill the request.
    Hypermedia as the engine of application state (HATEOAS): allows the client to learn, by means of hyperlinks within a response, which further action can be taken against the resource.

Uniform interface is a closely followed guideline in 5GC implementation. All resources that are associated with a service are uniquely identified.
Manipulation of resources by HTTP2 is via a standard set of operations as follows:

  • POST: requests the server to create a new resource.
  • GET: retrieves the resource addressed by the URI within the request.
  • PUT: replaces (completely) the resource addressed by the URI with the payload (JSON format) of the request.
  • PATCH: updates a resource (partially).
  • DELETE: deletes the resource addressed by the URI in the request.

Types of 3GPP API-Based Communication

There are typically the following types of HTTPv2-based communications:

3GPP API

  • Request/Response: This is the simplest type of HTTPv2-based communication in which the client simply requests a particular service from the producer—for example, a subscriber fetch from the UDM.
  • Subscribe/Notify: In this type of communication, the consumer can subscribe to notifications from the producer via a callback URI. Hence when certain events are triggered, the producer notifies the consumer. For example, SMF can subscribe to NRF for notifications when other NFs go down.

Example RESTful SBA Procedures

The functional split chosen for 5G SBA Network Functions includes e.g. an Access and Mobility Management Function (AMF), which serves as
the single-entry point for user equipment (UE) for all its communication. Once the user decides to use one of the services, e.g. to browse the web, the AMF needs to assign a Session Management Function (SMF) which manages the users session context.
As in 5G, virtual network functions (VNF) can be instantiated and deleted at any time, the AMF first needs to discover an available and suitable SMF, which is achieved via the Service Discovery procedure performed between the AMF and the Network Repository Function (NRF).

To allow for successful discovery, the SMF must have registered beforehand with the NRF. There are three different procedures:

Simplified API calls for example SBA procedures

  1. Service Registration: the SMF registers the services it provides with the NRF.
  2. Service Discovery: the AMF queries the NRF for a suitable SMF and in return receives the address of the SMF registered in step 1.
  3. Session Establishment: the requested session is established on the control plane level by the AMF via the SMF.

Reference

  • 3GPP TS 23.501, ‘System Architecture for the 5G System.
  • 3GPP TS 23.502, ‘ Procedures for the 5G System
  • RESTful APIs for the 5G Service Based Architecture.
  • Service-Based Architecture in 5G, Ericsson.
  • 3GPP 5G CoreNetwork Status, 3GPP

 

 

Related Posts