Description
The Cloud Enabler Server (CES) is a core architectural component introduced in 3GPP Release 18 within the framework of the 5G System (5GS) and its evolution. It operates as a management function, specifically designed to bridge the gap between traditional network management systems and cloud-native, distributed computing environments. The CES provides a set of standardized northbound Application Programming Interfaces (APIs) and southbound interfaces to facilitate the automated deployment, configuration, scaling, and termination of network functions and applications that are packaged as containers or virtual machines. Its primary role is to abstract the underlying heterogeneity of cloud infrastructure (e.g., from different vendors or across multiple data centers) and present a unified management plane to higher-level orchestration systems like the Network Function Virtualization Orchestrator (NFVO) or Service Management and Orchestration (SMO) framework.
Architecturally, the CES is defined to interact with several key entities. On its northbound side, it exposes management services to consumers such as the Management Data Analytics Function (MDAF), Network Data Analytics Function (NWDAF), or third-party application service providers. These interfaces, standardized in specs like 29.558, allow for the provisioning of compute, storage, and networking resources, as well as the instantiation and lifecycle management of workloads. On its southbound side, the CES communicates with Cloud Infrastructure Management Systems (CIMS), which could be based on platforms like Kubernetes or OpenStack, to execute the actual resource allocation and workload scheduling on physical or virtualized infrastructure. The CES itself may comprise sub-functions for inventory management, policy enforcement, fault and performance monitoring, and security credential management for the workloads it manages.
From an operational perspective, the CES works by receiving intent-based requests from a management service consumer. For example, a request may specify the need to deploy a User Plane Function (UPF) instance at a specific edge location with certain compute, latency, and bandwidth guarantees. The CES translates this high-level intent into concrete actions. It consults its inventory and policy engines to select a suitable host cloud infrastructure point-of-presence (e.g., a central office or an edge data center). It then interacts with the local CIMS at that site to reserve resources, pull the necessary container images, configure networking (potentially involving the Network Exposure Function (NEF) or Policy Control Function (PCF) for network policies), and finally instantiate the workload. Throughout the workload's lifecycle, the CES monitors its health and performance, collecting metrics and events which it can report back to the consumer or use to trigger automated scaling or healing actions.
Its role in the network is pivotal for enabling true cloud-native principles in telecommunications. By providing a standardized, automated, and infrastructure-agnostic management layer, the CES reduces vendor lock-in, accelerates service deployment from weeks to minutes, and enables efficient resource utilization through elastic scaling. It is a foundational enabler for network slicing, where each slice may require a unique set of functions deployed on-demand across a shared cloud infrastructure. Furthermore, it supports the vision of distributed compute from the core cloud to the far edge, allowing applications and network functions to be placed optimally to meet stringent latency and bandwidth requirements of use cases like industrial IoT, augmented reality, and autonomous vehicles.
Purpose & Motivation
The Cloud Enabler Server was created to address the significant operational challenges arising from the transition of mobile networks to cloud-native architectures. Prior to its standardization, the management of Virtualized Network Functions (VNFs) and Cloud-Native Network Functions (CNFs) was often handled through proprietary interfaces and scripts tied to specific cloud platforms (e.g., a particular vendor's implementation of OpenStack or Kubernetes). This led to fragmentation, high integration costs, and an inability to automate service deployment across multi-vendor, multi-cloud environments. The lack of a common management abstraction layer hindered the agility promised by Network Function Virtualization (NFV) and software-defined networking, making it difficult for operators to rapidly launch new services or dynamically scale resources in response to demand.
Historically, the 3GPP management architecture, centered around the Network Management System (NMS) and Element Management System (EMS), was designed for physical network elements with relatively static configurations. The dynamic, ephemeral nature of containerized workloads in a microservices-based 5G core required a new paradigm. The CES was motivated by the need to extend 3GPP's management framework to natively support cloud infrastructure. It solves the problem of how to uniformly manage the lifecycle of software workloads that are fundamental to the 5G system—such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and UPF—when they are deployed not as monolithic appliances but as collections of microservices that can be independently scaled and updated.
Furthermore, the rise of edge computing and network slicing created additional complexity. Deploying a network slice instance requires the coordinated instantiation of multiple functions across potentially geographically dispersed cloud resources. Without a standardized entity like the CES to act as a single point of control for cloud resource provisioning and workload management, slice orchestration would be immensely complex and non-interoperable. Thus, the CES exists to provide the necessary glue between the service/network orchestration layer and the diverse cloud infrastructure layer, enabling the automated, policy-driven, and efficient realization of the 5G vision for a flexible and service-based network architecture.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (23 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 18, the CES (Cloud Enabler Server) function was formally introduced into the architecture to enable interactions between edge applications and Cloud Application Servers (CAS). This included defining new procedures for Application Context Transfer (ACR) between edge and cloud environments to support service continuity. The release also provided clarifications and updates to the CES functionalities and its re-used service APIs.
- Architecture with CAS and CES TS 23.558CR0167
- Architecture for ACR between edge and cloud TS 23.558CR0222
- Enabling ACR with cloud applications TS 23.558CR0264
- Resolving Editor's Note about CES features TS 23.558CR0282
- More procedures with CES TS 23.558CR0328
- Resolve EN for interworking with cloud services TS 29.558CR0151
+ 8 more changes
In Release 19, the Cloud Enabler Server (CES) function was enhanced to explicitly consume services from the Edge Enabler Layer (EEL). Furthermore, the release focused on clarifying and detailing the CES's own service and its role in capability exposure, while also removing extraneous network entity references from this exposure process.
- Instigating ACR at the edge enabler server (EES) TS 23.558CR0561
- Capability Exposure via CES TS 23.558CR0717
- Capabilities utilized by EES and CES update TS 23.558CR0603
- Correction on Edge Enabler Using Satellite Access TS 23.558CR0738
- Correction on Edge Enabler Using Satellite Access TS 23.558CR0742
- CES consumes EEL services TS 23.558CR0583
+ 3 more changes
Explore further
Broader topics and technologies where CES plays a role.
Defining Specifications
3GPP specifications that define or reference CES, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.558 vk00 | Architecture for Edge Applications | Rel-20 |
| TS 23.700 vk00 | XR Services Application Enablement Layer | Rel-20 |
| TS 29.558 vj40 | Enabling Edge Applications | Rel-19 |