Description
An Ethernet Equipment Clock (EEC) is a logical functional block defined by 3GPP and ITU-T that resides within network elements like base stations (gNBs, eNBs), routers, or switches. Its primary purpose is to recover, generate, and distribute precise timing information (frequency, phase, and potentially time-of-day) when the source is an Ethernet-based synchronization signal. The EEC operates by synchronizing its internal oscillator to an incoming timing reference, typically delivered via two main methods: Synchronous Ethernet (SyncE) for frequency synchronization or IEEE 1588 Precision Time Protocol (PTP) for phase and time synchronization (often in conjunction with SyncE for robust frequency support).
Architecturally, the EEC consists of several key components: a clock recovery unit that extracts timing from the physical layer (for SyncE) or from PTP event messages, a phase-locked loop (PLL) or digitally controlled oscillator (DCO) to discipline the local clock, and a clock distribution unit to provide the synchronized timing to internal subsystems or downstream ports. In a base station, the EEC's output is used to synchronize the radio carrier frequency and, for Time Division Duplex (TDD) and New Radio (NR), the precise transmission timing and frame structure. The EEC can operate in different clock types as defined by ITU-T G.826x and G.827x series, such as an ordinary clock (OC), boundary clock (BC), or transparent clock (TC), depending on its role in the synchronization network.
How it works involves continuous measurement and adjustment. For PTP, the EEC acts as a PTP slave, exchanging timing messages with a PTP master clock to compute offset and delay, adjusting its local clock accordingly. For SyncE, it recovers the clock signal directly from the physical Ethernet line code. The EEC often implements algorithms to filter out network jitter and wander, and it may support holdover functionality, where it can maintain stable timing for a period after losing the reference, using its high-quality internal oscillator. Its role is fundamental in modern packet-based mobile backhaul and fronthaul networks, replacing legacy synchronization sources like GPS or T1/E1 lines, thereby enabling cost-effective, scalable, and reliable delivery of stringent synchronization requirements for 4G and 5G radio access networks.
Purpose & Motivation
The Ethernet Equipment Clock concept was developed to address the challenge of delivering high-precision synchronization over packet-switched networks as mobile operators migrated from TDM-based backhaul (using SDH/SONET or T1/E1 lines with inherent timing) to cost-effective, but asynchronous, Ethernet and IP networks. Previous cellular technologies like FDD LTE primarily required frequency synchronization, which could be loosely derived. However, the deployment of TDD-LTE, LTE-Advanced features (e.g., eICIC, CoMP), and especially 5G NR with its tight phase alignment requirements for features like massive MIMO and ultra-reliable low-latency communications (URLLC), created a critical need for precise phase and time synchronization at every base station.
The motivation for standardizing the EEC was to ensure interoperability and performance consistency across multi-vendor networks. Without a standardized clock function, each vendor's equipment might interpret or handle Ethernet-based timing signals differently, leading to synchronization failures and degraded network performance. The EEC specifications define the performance requirements (noise tolerance, holdover stability, etc.) and functional behavior, enabling operators to build reliable synchronization distribution networks using IEEE 1588 PTP and SyncE. This solves the core problem of how to distribute accurate, traceable timing from a central source (like a Grandmaster clock) through a potentially complex packet network to hundreds or thousands of radio sites, which is essential for network functionality, spectral efficiency, and preventing interference in dense deployments.
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (43 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 17, enhancements for the Edge Enabler Client (EEC) function introduced specific procedures for EEC context relocation and Application Context Relocation (ACR), including unique identification of the EEC context and preconditions for ACR. The updates also defined the provision of an Edge Enabler Server (EES) endpoint in ACR requests to facilitate this relocation and refined the EEC registration update procedure. Furthermore, the specification detailed the management of subscriptions to the Core Network (CN) within the EEC context.
- Corrections for AC and EEC initiated ACR scenario TS 23.558CR0003
- EEC context relocation TS 23.558CR0008
- ACR preconditions for EEC TS 23.558CR0036
- Provide EES endpoint in ACR request to enable EEC context relocation during ACR TS 23.558CR0044
- List of subscriptions to the CN in EEC context TS 23.558CR0054
- Unique identification of the EEC context in ACR procedures TS 23.558CR0088
+ 1 more changes
In Release 18, the EEC function was enhanced with a new triggering service and procedures, including a specific AC-EEC procedure to invoke a UE ID request, even for NATed IP addresses. The EEC's role was expanded to support EAS discovery and service provisioning via triggers, and its context was updated to share UE mobility requirements and constrained UE indications. Furthermore, the specifications now explicitly cover the exposure of EES capabilities to the EEC and detail the EEC's supporting functions for executing Application Context Relocation.
- EEC triggering service TS 23.558CR0138
- New AC-EEC procedure to invoke UE ID request TS 23.558CR0155
- Updating UE Identifier API procedure to enable EEC invoke UE ID request for NATed IP address TS 23.558CR0156
- EEC sharing UE Mobility requirement TS 23.558CR0207
- Explaining usage of EES’s capability exposure by EEC TS 23.558CR0230
- EEC selected ACR scenario for EAS bundles TS 23.558CR0254
+ 23 more changes
In Release 19, the EEC function was updated with new procedures for its interaction with the Application Client (AC) for ACR, and for handling the EAS instantiation completion time. Enhancements were also made to the mechanisms for sharing port information to receive EEC triggers and for verifying EEC-provided information. Furthermore, corrections and updates were applied to the EEC context relocation information and to the EEC's own functionalities.
- Remove EN on EEC triggering service parameter TS 23.558CR0607
- AC and EEC interaction for ACR TS 23.558CR0630
- Handling of EAS instantiation completion time at EEC TS 23.558CR0686
- Sharing port information to receive the EEC triggers. TS 24.558CR0113
- Functionalities of EEC update TS 23.558CR0604
- EN on EEC-provided information verification and trustfulness TS 23.558CR0707
+ 1 more changes
Explore further
Broader topics and technologies where EEC plays a role.
Defining Specifications
3GPP specifications that define or reference EEC, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.255 vj50 | UAS Application Layer Support | Rel-19 |
| TS 23.548 vj50 | 5G System Edge Computing Enhancements | Rel-19 |
| TS 23.558 vk00 | Architecture for Edge Applications | Rel-20 |
| TS 23.700 vk00 | XR Services Application Enablement Layer | Rel-20 |
| TR 23.758 vh00 | Study on Edge Application Architecture | Rel-17 |
| TR 23.958 vj00 | EDGEAPP alignment with ETSI MEC and GSMA OP | Rel-19 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 24.558 vj50 | Edge Enabler APIs Stage 3 | Rel-19 |
| TS 26.115 vj00 | 3GPP TS 26115: Echo Control Requirements | Rel-19 |
| TS 26.131 vj00 | Terminal Acoustic Performance Requirements | Rel-19 |
| TS 26.132 vj00 | Terminal Acoustic Test Methods | Rel-19 |
| TS 26.506 vj20 | Real-Time Media Communication Architecture for 5G | Rel-19 |
| TS 26.510 vj10 | Media Delivery APIs for 5GMS and RTC Systems | Rel-19 |
| TR 26.803 vh00 | 5G Media Streaming Extensions for Edge Processing | Rel-17 |
| TS 26.804 vj10 | 5G Media Streaming Extensions Study | Rel-19 |
| TR 26.941 vj01 | 5G Media Slicing Extensions | Rel-19 |
| TS 28.879 vj10 | OAM for Service Management Exposure Study | Rel-19 |
| TS 29.558 vj40 | Enabling Edge Applications | Rel-19 |
| TS 33.127 vj50 | Lawful Interception Architecture and Functions | Rel-19 |
| TR 33.739 vi10 | Study on security enhancement of support for | Rel-18 |
| TS 33.749 vj00 | Study on security aspects of edge computing enhancement | Rel-19 |
| TR 33.839 vh10 | Edge Computing Security Study for 5G Core | Rel-17 |
| TS 36.401 vj00 | E-UTRAN Overall Architecture Description | Rel-19 |
| TS 43.050 vj00 | GSM Transmission Planning for Speech Services | Rel-19 |