What is the 5G Session

Management Function
(SMF)?
The 5G Session Management Function (SMF) is a fundamental element of the 5G
Service-Based Architecture (SBA). The SMF is primarily responsible for interacting with
the decoupled data plane, creating updating and removing Protocol Data Unit (PDU)
sessions and managing session context with the User Plane Function (UPF).

The Session Management Function within a 5G Service-Based Architecture

Both the UE and the gNB employs the Next Generation Application Protocol (NGAP) to
carry Non Access Stratum (NAS) messages across the N1 or N2 reference interfaces in
order to request a new session. The Access and Mobility Management Function (AMF)
receives these requests and handles anything to do with connection or mobility
management while forwarding session management requirements over the N11
interface to the SMF. The AMF determines which SMF is best suited to handle the
connection request by querying the Network Repository Function (NRF). That interface
and the N11 interface between the AMF and the specific SMF assigned by the NRF,
use the Service Based Interface (SBI) message bus, to which all Service-Base
Application elements are connected. The SBI message bus employs RESTful API
principles over HTTP/2 -- web technologies that dramatically simplify and accelerate
service deployments.

Basic SBI call flow for SMF registration and discovery, per 3GPP TS 23.502

Messages received over the N11 interface represent a trigger to add, modify or delete a
PDU session across the user plane. The SMF sends messages to the UPF over the N4
reference interface using the Packet Forwarding Control Protocol (PFCP). Similar to
OpenFlow, in nature, PFCP employs a well-known UDP port (8805) and was originally
defined in release 14 specifications to support Control and User Plane Separation
(CUPS).

During session establishment or modification, the SMF also interacts with the Policy
Control Function (PCF) over the N7 interface and the subscriber profile information
stored within the Unified Data Management (UDM) function (N10), which assumes the
role previously performed by the HSS. Employing the SBI Message Bus, the PCF
provides the foundation of a policy framework which, along with the more typical QoS
and charging rules, includes Network Slice selection, which is regulated by the Network
Slice Selection Function (NSSF).
Decoupling other control plane functions from the user plane, while (together with the
AMF) assuming the some of the functionality previously undertaken by the MME, the
SMF performs the role of DHCP server and IP Address Management (IPAM) system.
Together with the UPF, the SMF maintains a record of PDU session state by means of
a 24bit PDU Session ID. The SMF sets configuration parameters in the UPF that define
traffic steering parameters and ensure the appropriate routing of packets while
guaranteeing the delivery of incoming packets, though a Downlink (DL) data notification.
In 4G EPC architectures, this is a SGW to MME message. The SMF is responsible for
checking whether the UE requests are compliant with the user subscription and for
connectivity charging, which is achieved by interacting with a Charging Function (CHF)
defined within 3GPP TS 32.255.

To meet the architectural requirements of 5G, the SMF must be entirely designed and
delivered as a Cloud-Native network function, dynamically deployed and scaled-up on
demand in a completely automated manner. This is a particularly complex proposition
when it comes to high-availability control components with asynchronous call flows
across geo-diverse infrastructures requiring long and short-lived state maintenance for
sessions traversing elements that might quiesce without notice. These functions must
therefore employ established design patterns for building and deploying massively
scalable web applications while adapting to fit the constraints of real-time
communications networks. REST is inherently stateless and the 3GPP has defined a
Structured and Unstructured Data Storage Functions (UDSF), which can be used by
any Network Function to achieve stateless reliability and load distribution. However, a
strong background in these design principles will ultimately be required to deliver on a
truly Cloud-Native 5G Session Management Function.

What is the 5G User Plane

Function (UPF)?
The User Plane Function (UPF) is a fundamental component of a 3GPP 5G core
infrastructure system architecture. The UPF represents the data plane evolution of a
Control and User Plane Separation (CUPS) strategy, first introduced as an extension to
existing Evolved Packet Cores (EPCs) by the 3GPP in their Release 14 specifications.
CUPS decouples Packet Gateway (PGW) control and user plane functions, enabling the
data forwarding component (PGW-U) to be decentralized. This allows packet
processing and traffic aggregation to be performed closer to the network edge,
increasing bandwidth efficiencies while reducing network. The PGW’s handling
signaling traffic (PGW-C) remain in the core, northbound of the Mobility Management
Entity (MME).
The primary goal CUPS was to support 5G New Radio (NR) implementations enabling
early IoT applications and higher data rates. Committing to a complete implementation
of control and user plane separation, however, is a complex proposition which only
provides a subset of the advantages adopting a 5G User Plane Function affords, such
as network slicing. Deployed within a dynamic cloud native compute infrastructure, the
User Plane Function delivers the packet processing foundation for Service Based
Architectures (SBAs).

Defined in 3GPP technical specification 23.501, the UPF provides:

 The interconnect point between the mobile infrastructure and the Data Network
(DN), i.e. encapsulation and decapsulation of GPRS Tunnelling Protocol for the
user plane (GTP-U).
 The Protocol Data Unit (PDU) session anchor point for providing mobility within
and between Radio Access Technologies (RATs), including sending one or more
end marker packets to the gNB.
 Packet routing and forwarding, including performing the role of an Uplink
Classifier / UL-CL (directing flows to specific data networks based on traffic
matching filters) and a Branching point, when acting as an Intermediate UPF (I-
UPF) multi-homed to more than one PDU session anchor (PSA).
 Application detection using Service Data Flow (SDF) traffic filter templates or 3-
tuple (protocol, server-side IP address and port number) Packet Flow Description
(PFD) received from the SMF.
 Per-flow QoS handling, including transport level packet marking for uplink (UL)
and downlink (DL), rate limiting and reflective QoS (DSCP) marking on the DL.
 Traffic usage reporting for billing and the Lawful Intercept (LI) collector interface

The User Plane Function has four distinct reference points:

 N3: Interface between the RAN (gNB) and the (initial) UPF.
 N9: Interface between two UPF’s (i.e the Intermediate I-UPF and the UPF
Session Anchor)
 N6: Interface between the Data Network (DN) and the UPF
 N4: Interface between the Session Management Function (SMF) and the UPF
 

5G Core Reference Point Architecture 

The protocol employed on the N3 and N9 interfaces could be the GPRS Tunnelling
Protocol (GTP) with header extensions for 5G, segment routing (SRv6 or NSH) or even
an Information Centric Networking (ICN) protocol. The Locator/ID Separation data plane
protocol (LISP-DP) over GTP or Identifier Locator Addressing (ILA) could also be
utilized. A relay function would be performed by an I-UPF, while the UPF PDU Session
Anchor would terminate these protocols.

5G User Plane Protocol Stack, employing STP with 5G header extensions

The UPF identifies user plane traffic flow based on information received from the SMF
over the N4 reference point. The N4 interface employs the Packet Forwarding Control
Protocol (PFCP), which was originally defined within 3GPP technical specification
29.244 for use on Sx reference points in support of CUPS.   PFCP is similar to
OpenFlow but can be limited to only the functionality required to support mobile
networks. PFCP sessions, established with the UPF, define how packets are identified
(Packet Detection Rule / PDR), forwarded (Forwarding Action Rules / FARs), processed
(Buffering Action Rules / BARs), marked (QoS Enforcement Rules / QERs) and
reported (Usage Reporting Rules / URRs).  

Packet processing flow in the User Plane Function (per 3GPP TS29.244) 

To meet 5G’s fundamental mandate for granular capacity or application-driven,

instantiation and up/down-scaling, the UPF must be implemented as a pure cloud native
network function using modern microservices methodologies and deployable within a
serverless framework. In order to achieve high packet throughputs with complex
pipelines and low latencies, such components have historically been realized using
dedicated hardware and custom silicon. Delivering a cloud native UPF on shared
resources demands solving complex real-time data processing problems and providing
a high degree of flexibility in the pipeline to support emerging traffic tunneling, mobility
and infrastructure overlays. UPF instantiation must also be highly automated and
orchestrated. This means developing or enhancing user-space data plane acceleration,
runtime programmability techniques and tightly integrating with numerous cloud
orchestration systems, such as Kubernetes.

The User Plane Function is a critical new component for supporting the new generation
of service-based architectures. The velocity of innovation in this area, however, should
also allow the early majority of perspective CUPS adopters to adopt the UPF over
interim PGW/SGW-U solutions, smoothing the migration from 4G to 5G.
What is a 5G Access
Gateway Function (AGF)?
The 5G Access Gateway Function (AGF) definition is the result of a joint initiative
between the Broadband Forum (BBF) and the GSMA’s 3 rd Generation Partnership
Project (3GPP). BBF technical report TR-456 specifies the AGF functional
requirements, while the 3GPPs technical specification TS 23.316 is the companion
document detailing wireless and wireline convergence (WWC) access support for the
5G system. 3GPP refers to this component as the Wireline Access Gateway Function
(W-AGF) in its standards and covers not only WWC architectures defined within the
BBF but also CableLabs (WR-TR-5WWC-ARCH).

The adoption of a common core infrastructure supporting both fixed and wireless
access will benefit the majority of operators, who are now actively assimilating the
resources and assets of these previously disparate networks. Moreover, with the advent
of 5G new radio (5GNR), fixed wireless access (FWA) will increasingly complement or
even replace copper alternatives in the last mile. From the perspective of the BBF, the
AGF is an evolution of their technical and deployment specifications for ATM-centric
Broadband Remote Access Servers (BRASs) and Ethernet-based Broadband Network
Gateways (BNGs). These devices are essentially responsible for providing subscriber
authentication, authorization and accounting (AAA) and traffic management in
broadband wireline access networks.

An Access Gateway Function provides AAA services plus hierarchical traffic shaping
and policing for fixed network (FN) and 5G residential gateways (RGs) being served
from a standard 3GPP User Plane Function (UPF) within a common 5G Core (5GC).
While policy and subscriber databases are distinct elements in today’s wireline
broadband networks, the adoption of a 5G Service Based Architecture (SBA) enables
resources, such as the policy control function (PCF) and authentication server function
(AUSF) to be shared across mobile, fixed wireless and wireline access networks. It also
easily supports shared supporting infrastructure, such as the IP Multimedia Subsystem
(IMS) for rich multimedia service delivery.
The Access Gateway Function (AGF) with a 5G wireline wireless convergence (5G-
WWC) infrastructure

Taking into account differing and variable characteristics of each access technique, this
approach guarantees that standardized services and service level agreements (SLAs)
can be applied across all subscribers and when individual users connect over different
access technologies. To facilitate this, the 3GPP QoS model defined within TS 23.501 is
applied across the AGF as if it were an access network. When the AGF receives a QoS
profile from the 5G core with a request for dedicated resources to support a specific
protocol data unit (PDU) session, it is mapped to the AGF’s user plane-level QoS. As
always, each QoS flow is identified by a QoS Flow Identifier (QFI).

Supporting modern control plane and user plane separation (CUPS) philosophies, the
AGF comprises two functional components. The AGF-CP handles control plane data,
exposing an N1/N2 interface towards the AMF, while the AGF-UP is responsible for
handing user plane traffic with an N3 interface to a UPF. The specifics of AGF CUPS
can be found within the complementary BBF WT/TR-458 specification. The N1, N2 and
N3 5G reference interfaces are mandatory requirements on an AGF implementation,
along with the V (or Va) interface to the wireline access network (wAN), defined within
BBF’s TR-178 - Multi-service Broadband Network Architecture and Nodal
Requirements. Wireline access network elements can include digital subscriber line
access multiplexers (DSLAMs) and optical line terminals (OLTs). TR-456 also allows for
UPF functionality to be combined with the AGF, extending the number of interfaces
required to include N4, N6 and N9. This can be likened to the Intermediate UPF (I-UPF)
edge aggregator, outlined within 3GPP TS 23.501.
Other key requirements include the ability to construct a concealed subscription
permanent identifier (SUPI) - or subscription concealed identifier (SUCI) - based on user
identification and authentication information extracted via PPPoE, DHCPv4 option 82 or
DHCPv6 option 18. The SUCI registration request derived from these protocols is
forwarded to the 5G Access and Mobility Management Function (AMF), which is then
proxied to the AUSF and its supporting User Data Management (UDM) server.

The AGF constructs a SUCI by extracting information from PPPoE or DHCP options

AMF selection is performed per 3GPP TS 23.501. With the AGF also participating in 5G
network slicing, Network Slice Selection Assistance Information (NSSAI) must also be
employed for AMF selection during the initial registration of an RG. In the case of a
combined AGF and UPF, the AMF relays AGF identities parameters to the Session
Management Function (SMF), enabling the SMF to determine if a session employs the
integrated UPF and internal N3 interface. The SBA’s Network Resource Function (NRF)
aids in this discovery process.
What is the 5G Service-
Based Architecture (SBA)?
 
Service-Based Architectures provide a modular framework from which common
applications can be deployed using components of varying sources and suppliers.  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.

Assuming the role of either service consumer or service producer, Network Functions
are self-contained, independent and reusable. Each Network Function service exposes
its functionality through a Service Based Interface (SBI), which employs a well-defined
REST interface using HTTP/2. To mitigate issues around TCP head-of-line (HOL)
blocking, the Quick UDP Internet Connections (QUIC) protocol may be used in the
future. The 5G SBA comprises numerous components, including:

What is the NF Repository Function (NRF)

With Network Functions built using microservice methodologies, the 5G Service Based
Architecture will ultimately evolve into a complete service mesh with service discovery,
load balancing, encryption, authentication and authorization, employing a sidecar for
interservice communication. Currently, however, the Service-Based Architecture
employs a centralized discovery framework that leverages a NF Repository Function
(NRF). The NRF maintains a record of available NF instances and their supported
services. It allows other NF instances to subscribe and be notified of registrations from
NF instances of a given type. The NRF supports service discovery, by receipt of
Discovery Requests from NF instances and details which NF instances support specific
services.

What is the Network Slice Selection Function

(NSSF)
Network slicing is a fundamental new capability of 5G infrastructures, bringing a high
degree of deployment flexibility and efficient resource utilization when deploying diverse
network services and applications. A logical end-to-end network slice has pre-
determined capabilities, traffic characteristics and service level agreements and
includes the virtualized resources required to service the needs of a Mobile Virtual
Network Operator (MVNO) or group of subscribers, including a dedicated User Plane
Function (UPF), Session Management Function (SMF) and Policy Control Function
(PCF).

The Access and Mobility Management Function (AMF) instance serving a piece of User
Equipment (UE) is common to all Network Slices that UE is a member of. This is
currently limited to eight. Identification of a Network Slice is via the Single Network Slice
Selection Assistance Information (S-NSSAI). The Network Slice instance selection is
triggered by the first AMF that receives a UE registration request, which the retrieves
the permitted slices from the Unified Data Management (UDM) element and then
requests an appropriate Network Slice Instance of the NSSF.
What is the Unified Data Management (UDM)
Service
The UDM provides services to other SBA functions, such as the AMF, SMF and NEF.
The UDM is typically recognized as a stateful message store, holding information in
local memory. The UDM, however, may also be stateless, storing information externally
within a Unified Data Repository (UDR). The UDM is analogous to the Home Subscriber
Server (HSS), providing authentication credentials while being employed by the AMF
and SMF to retrieve subscriber data and context.

What is the Policy Control Function (PCF)

The Policy Control Function (PCF) supports a unified policy framework, within the 5G
infrastructure, for governing network behavior. The PCF accesses the subscription
information, required to make policy decisions, from the UDM and then provides the
appropriate policy rules to the control plane functions so that they can enforce them.
The PCF is analogous to the PCRF in EPC architectures.

What is the Service Communication Proxy

(SCP)
Appearing in the second specification iteration of 5G, or release 16 in 3GPP parlance,
the Service Communication Proxy (SCP) was defined within TS23.501 - System
architecture for the 5G System. It’s the sort of function that is born of necessity. The
SCP is not required to make a 5G SBA work but is required to make it work in a highly
distributed multi-access edge compute cloud environment. The Service Communication
Proxy provides a single point of entry for a cluster of network functions, once they have
been successfully discovered by the NRF. This allows the SCP to become the
delegated discovery point in a data center, offloading the NRF from the numerous
distributed services meshes that would ultimately make-up a network operator’s
infrastructure. Together with the NRF, the SCP forms the hierarchical 5G Service Mesh.
What is the 5G Access and
Mobility Management
Function (AMF)?
With the functionality of the 4G Mobility Management Entity (MME) now decomposed,
the 5G Core Access and Mobility Management Function (AMF) receives all connection
and session related information from the User Equipment (UE) (N1/N2) but is
responsible only for handling connection and mobility management tasks. All messages
related to session management are forwarded over the N11 reference interface to the
Session Management Function (SMF).

As a mobile network comprises many AMF instances, a Globally Unique AMF Identifier
(GUAMI) is employed. The UE specifies this in the first Non-Access Stratum (NAS)
message it sends, which is routed to the required AMF by the Radio Access Network
(RAN). Applicable to both 3GPP access and non-3GPP access, the GUAMI also
ensures that messages from a UE, registered through both access networks, get
forwarded to the same AMF. The Non-3GPP Interworking Function (N3IWF) is
responsible for routing messages outside the 5G RAN.

Performing the role of access point to the 5G core, thereby terminating RAN control
plane and UE traffic originating on either the N1 or N2 reference interface, the AMF
implements NAS ciphering and integrity protection algorithms. Following the initial NAS
message, the AMF sends an Authentication and Key Agreement (AKA) request in an
equivalent manner to the MME in Evolved Packet Core (EPC) infrastructures. This
precedes the UE authorization process, in which the 5G Core Service Based
Architecture (SBA) Unified Data Management (UDM) function supersedes the Home
Subscriber Server (HSS).  This is performed over the N8 reference interface and
therefore employs the HTTP/2 Service Based Interface (SBI) message bus. Lastly, in
order to send applicable and appropriate event information, the AMF connects to Lawful
Intercept (LI) systems.
While the information could be stored in another manner, the AMF typically queries the
5G Service-Based Architecture’s (SBA’s) Network Repository Function (NRF) to
discover and select available SMF instances. These can be identified by IP address or
Frequently Qualified Domain Name (FQDN). This process is outlined in further
detail here.

Assuming the responsible for mobility management, the AMF is in charge for managing
handovers between gNodeB’s (gNB’s), within the Next Generation Radio Access
Network (NG-RAN). Formally referred to as an X2 handover, in 5G it is termed an Xn
handover. This represents the updated reference interface application protocol (XnAP)
employed between gNB base stations, which is defined within the 3GPP’s Technical
Specification (TS) 38.423.

UE handover between source and target gNB’s within 5G infrastructures

With the data flowing from a UE via a source gNB to the data plane of the 5G Core
(User Plane Function / UPF), Radio Resource Control (RRC) signaling is employed to
continuously measure and report on signal quality. When the source node detects that a
handover is required, it connects with the target gNB to commence the switching
process. Once the tunnels have been moved across to the target gNB, the UE performs
a handover and connects to that same target node. A path switch request is made from
the target gNB to the AMF and, once acknowledged, the data can flow from the UE
through that target node and on to the prescribed UPF.
What is Multi-access Edge
Computing (MEC)?
Topics

 Network Functions Virtualization (NFV),

 

 Mobile Infrastructure,
 

 5G
Reflecting the natural evolution of mobile Base Stations and the Radio Access Network
(RAN), Multi-access Edge Computing (MEC) first emerged as an ETSI Industry
Specifications Group (ISG) in early 2016. Originally defined as Mobile Edge Computing,
the descriptor was updated in September, of that year, to reflect the fact that the same
concepts described in the early requirements were relevant to fixed wireless, Wi-Fi and
wireline access. The evolving ETSI MEC ISG documents can be found here.

Multi-Access Edge Computing infrastructures allow the implementation of software-only

mobile functions or Software-as-a-Service (SaaS) applications that operate entirely
within a standardized virtualization platform which is deployed in or close to the network
edge.
Multi-Service Edge Computing reference architecture, per ETSI GS MEC 003 v1.1.1

The Multi-Access Edge Computing reference architecture consists of two functional

areas -- Host and Management -- with the management layer comprising both host and
system-level administrative entities. The combination of these functional elements
provides the foundation required to operate a distributed environment for instantiating
and scaling mobile applications and services in a highly granular and dynamic manner.

At the core of the mobile edge host is the virtualization infrastructure, which supplies
compute, storage and network resources to the mobile edge applications. Data plane
functionality, within the virtualization infrastructure, applies rules and enforces access
control lists while routing traffic between network services and mobile applications.
These may be local to the host or external on hosts residing within other networks.

The mobile edge platform, within the host, provides service and application assistance
for mobile applications. This includes the authentication and authorization of mobile
edge services, along with their discovery, advertisement and notification of any state
changes. Under the direction of the mobile edge platform manager, the mobile edge
platform controls the spin-up, quiesce and graceful termination of mobile edge
applications. All data related to each mobile edge application instance is stored within
the platform, including any transport dependencies, traffic rules and DNS rules.
 Mo
bile Edge Application Start up

The mobile edge platform manager is responsible for the entire application lifecycle and
informs the mobile edge system of any relevant application-level events. It also receives
and processes status reports and performance measurement information from the
virtualization infrastructure manager (VIM). The VIM is a critical component of ETSI
NFV ISG architecture specifications, being responsible for allocating, managing and
releasing virtualized compute, storage and networking resources -- generally preparing
the infrastructure to run a software image.

A core element within the overlying mobile edge system, the mobile edge orchestrator
maintains a holistic view of the mobile edge hosts, including their available resources
and services. The mobile edge orchestrator on-boards and records applications,
performing integrity checks while confirming the rules and requirements, for running the
software packages, comply with operator policies. With a complete topological view of
the entire mobile edge system, the mobile edge orchestrator can select the most
appropriate mobile edge host from which to instantiate an application. This is generally
based on the available services, required resources and infrastructure demands, such
as latency.

External operations support systems (OSS) interface with the mobile edge orchestrator
over mobile edge management reference point one (Mm1), the requirements for which
are detailed within ETSI GS MEC 010-2. Additional Mm reference points are defined
between orchestration elements, management functions and host platforms, while two
Mx reference points interface with external entities. Mobile edge platform (Mp) reference
points, to local or remote applications, provide service registration, discovery and
communications interfaces. This reference point group also interfaces with the data
plane, instructing the underlying infrastructure on how to route traffic between
applications and network services.
What is an Open Radio
Access Network (O-RAN)?
Topics

 5G
An Open Radio Access Network (O-RAN) is a totally disaggregated approach to
deploying mobile fronthaul and midhaul networks built entirely on cloud native
principles. O-RAN is an evolution of the Next Generation RAN (NG-RAN) architecture,
first introduced by the GSMA’s 3GPP in their release 15 (5G version 1) technical
specification TS 38.401. The O-RAN Alliance formed to undertake the advancement of
NG-RAN philosophies, expanding on the scope of what was originally outlined by the
3GPP. Comprising over 1601 member companies, the O-RAN alliance issues
specifications and releases open source software under the auspices of the Linux
Foundation.

O-RAN Logical Architecture Diagram

TS 38.401 decomposed the existing Baseband Unit (BBU) into two functional
components, a Distributed Unit (DU) and Central Unit (CU). Conforming to modern
control user plane separation (CUPS) constructs, the Central Unit can be further
decoupled into distinct control plane (CU-CP) and user plane (CU-UP) functions.
Replacing the monolithic BBU with the CU/DU allows for new deployment models which
feature centralized packet processing functions, while laying the groundwork for
separating baseband functions from the (remote) radio unit (RRU/RU).

This affords numerous technical and operational advantages, regardless of whether the
RRU, DU and CU remain co-located within a 5GNodeB (gNB), like existing NodeB
RRU/BBU implementations, or the CU is physically deployed to a more centralized
location. The centralization of the CU in an aggregation site reduces costs and
accelerates the implementation of dynamic and highly automated multiaccess edge
compute (MEC) clouds for the RAN (aka C-RAN). This functional decoupling will also
enable the adoption of modern transport protocols which can also align with the 5G core
user plane (i.e. SRv6) while easing the addition of new latency, high-bandwidth, AI/ML-
driven applications.

The deployment of NG-RAN components is defined as being with or between the

fronthaul, midhaul and backbone network. Open interfaces are described as either
lower-layer splits (LLS), in the case of the RU to DU connection, or higher-layer splits
(HLS) as with the link between the DU and CU. This nomenclature is descriptive of the
OSI layer (i.e. L1/L2/L3) exposed by the interface and handled by the NG-RAN function.
Where components are instantiated will depend on the requirements of the service
slice. A low latency service might demand a CU be co-located with the DU in the access
layer while a slice supporting a simple machine to machine communications application
would scale more cost effectively with a CU within the network core.

NG-RAN Lower-Layer and Higher-Layer Split

NG-RAN clearly defines the DU and CU plus the F1, E1, Xn and NG between them and
the core network but stops short of outlining the service management framework and
interfaces required for the RAN to operate within an orchestrated and automated cloud
environment. TS 38.401 also fails to address the RU-DU interface.  Without further
definition, it would be logical to adopt the exiting Common Public Radio Interface (CPRI)
defined between the RRU-BBU. Although theoretically a standard, this interface has
been heavily modified by individual vendors, effectively locking their RRU to their BBU.

While CPRI is a high-speed serial interface, the bandwidth demands of 5G will stretch
the limits of local fiber and increase the need for more radio units. Current
implementations do not allow for the DU to reduce this burden by offloading some of its
functionality to the RU. While the enhanced CPRI (eCPRI) interface was originally
proposed as an alternative, this specification was also developed by just four 2 large
vendors. The O-RAN Alliance has therefore taking on the task of defining new Open
Fronthaul user and management plane interfaces between the DU and RU.

To ensure openness, O-RAN decouples hardware and software into 3 layers: The
commercial off the shelf (COTS) merchant silicon (including x86), a hardware
abstraction layer and an application layer, where the RAN functions reside. Ensuring
each layer is vendor agnostic, the O-RAN alliance has specified a list of requirements
for a cloud platform which supports the execution of O-RAN network functions. This is
referred to as the O-RAN Cloud Platform, or O-Cloud. Deploying O-RAN functions on
x86 hardware in cloud native environments using lightweight (OS virtualization)
containers demands a strong emphasis on data plane acceleration. This must be
achieved at the application level, as these functions will not have access to the Kernel.
As such, solutions may be specific to each O-RAN CNF but leverage standard
techniques such as DPDK and FD.io or employ more advanced techniques, such as the
Metaswitch Composable Network Applications Platform Packet Processing Engine
(CNAP/CPPE).