CES

Cloud Enabler Server

Management →
Introduced in Rel-18

CES is a 3GPP management entity that enables and manages cloud-native network functions by providing a standardized framework for lifecycle management, orchestration, and capability exposure in cloud-based 5G and beyond networks.

Category
Management
Introduced
Rel-18
Where
Services
Specifications
3 specs
CES Description Purpose Related Classification Detected Changes Specifications

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

Part ofNWDAF
Related approachesNEF

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (12 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-18 6 changes

In Release 18, the Cloud Enabler Server (CES) function was formally introduced into the Edge Enabler Layer architecture to facilitate service continuity between Edge and Cloud Application Servers (CAS). It establishes new reference points, including CLOUD-1 for CAS interaction and ECI-4 for communication with the Edge Enabler Server (EES), and re-uses EES service APIs. The release also specifies several CES-enabled procedures, such as the EEC context relocation procedure and ACR parameter information procedures, detailing its role in application context transfer during user mobility.

  • Architecture with CAS and CES TS 23.558CR0167
  • Resolving Editor's Note about CES features TS 23.558CR0282
  • More procedures with CES TS 23.558CR0328
  • CES clarifications and editorial fix TS 23.558CR0342
  • CES functionalities TS 23.558CR0548
  • Update to CES re-used service APIs TS 29.558CR0174
Rel-19 6 changes

In Release 19, the Cloud Enabler Server (CES) function was formally integrated into the Edge Enabler Layer (EEL) architecture to enable cloud applications. Key new capabilities included defining specific CES reference points—such as ECI-3 for CES-ECS interaction, ECI-4 for CES-EES interaction, and CLOUD-1 for CAS-CES interaction—and detailing procedures for capability exposure to CAS and for application context relocation to support service continuity between EAS and CAS.

  • Capability Exposure via CES TS 23.558CR0717
  • Capabilities utilized by EES and CES update TS 23.558CR0603
  • CES consumes EEL services TS 23.558CR0583
  • Clarify CES service TS 23.558CR0585
  • CES consumes EEL services details TS 23.558CR0676
  • Remove EN on capability exposure via CES TS 23.558CR0689

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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.