EEC

Ethernet Equipment Clock

Other →
Introduced in Rel-8 Also in: Core Network, User Equipment, Radio Access Network

EEC is an Ethernet Equipment Clock, a network function that synchronizes to a timing reference delivered over Ethernet to provide precise frequency, phase, and time synchronization for mobile network nodes.

Category
Other
Introduced
Rel-8
Where
Services › Codecs
Also touches
3 segments
Specifications
24 specs
EEC Description Purpose Related Detected Changes Specifications

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 Requests

Specific 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.

Rel-17 7 changes

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

Rel-18 29 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

Rel-19 7 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.

SpecificationTitleRelease
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
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.