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.
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (56 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, the Edge Enabler Client (EEC) function was newly introduced as a logical entity within the UE to enable the consumption of edge computing services. It provides an EDGE-5 reference point for interactions with client applications like the UAE and SEAL clients. Furthermore, the EEC facilitates connectivity to the Edge Enabler Server (EES) in the Edge Data Network, though Release 15 specified that there is no interworking to the ePDG or EPC for Ethernet and unstructured PDU sessions.
- No interworking to ePDG/EPC for Ethernet and unstructured PDU sessions TS 24.501CR0428
In Release 16, the new EEC (Edge Enabler Client) function was introduced to enable the UE to consume edge computing services. The EEC interacts with UAS, UAE, and SEAL clients via the EDGE-5 reference point to communicate with an Edge Enabler Server (EES) in the network. This provides the foundational framework for edge service enablement, distinct from the Ethernet-related enhancements for PDU session interworking, port management information transfer, and header compression for CIoT that were also standardized in this release.
- Interworking of Ethernet PDU session to Ethernet PDN connection TS 24.501CR0936
- Adding support for transfer of Ethernet port management information containers TS 24.501CR1359
- Ethernet header compression for CP CIoT – 5GMM aspects TS 24.501CR2165
- Ethernet header compression for CP CIoT – 5GSM aspects TS 24.501CR2323
In Release 17, the EEC (Edge Enabler Client) function introduced enhancements for Application Context Relocation (ACR), including specific preconditions for ACR and procedures for unique EEC context identification and relocation. The updates also clarified the handling of multiple VLAN tags (S-TAGs) in Ethernet headers and refined the EEC registration update procedure. Furthermore, it was specified that an EES endpoint must be provided in an ACR request to enable the relocation of the EEC context during that process.
- 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
+ 8 more changes
In Release 18, the EEC function was enhanced with a new triggering service and specific procedures for service provisioning and EAS discovery. Key additions included procedures for the EEC to invoke UE ID requests, share UE mobility requirements, and utilize the EES's capability exposure. The updates also defined the EEC's role in Application Context Relocation (ACR) scenarios and refined its interactions via the EDGE-5 reference point for consuming edge services.
- 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 handling EAS instantiation completion timing and for sharing port information to receive EEC triggers. Enhancements were also made to the interaction between the Application Client (AC) and EEC for Application Context Recovery (ACR), and to the verification and trustfulness of EEC-provided information. Furthermore, the release introduced corrections on EEC context relocation information and removed the exposure of a network parameter related to EEC triggering services.
- 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
- Not allowing MPQUIC-E functionality for home-routed MA PDU sessions of type Ethernet TS 24.501CR6939
+ 2 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 |