SyncE + NTP. Что? Да!

Семён сохраняет полезное_)

Продолжаем тему синронизации то как вместе с SyncE используют другие протоколы для универсального решения. Ранее я писал о SyncE+PTP - https://telegra.ph/Sync-E-i-PTP-Kak-oni-zhivut-vdvoem-v-telekome-10-05

Сегодня хочу рассказать вам про совместное применение SyncE + NTP. Данное решение применяется для FDD сетей оператора. На таких базовых станциях часто нет возможости PTP синхронизации, или же в PTP профиле время не выровнено с эпохой. Именно тогда на помощь приходит SyncE + NTP.

В FDD-сетях uplink и downlink используют разные частоты, а не чередуются по времени, как в TDD.

Поэтому:

жёсткая временная или фазовая синхронизация между сотами не требуется (нет риска взаимной интерференции по таймингу);
но частотная синхронизация обязательна — чтобы несущие и поднесущие разных eNB/gNB не «уплывали» по частоте (особенно для handover, carrier aggregation, MIMO);
а временная синхронизация “time-of-day” полезна для:
журналирования, логов, KPI, OSS;
меток времени (timestamp) при X2/Xn интерфейсе;
общего согласования системного времени.

К примеру оператор не хочет ставить GNSS на каждой eNB, но хочет обеспечивать частоту через SyncE и общее системное время через NTP:

Тогда как SyncE (от транспортного коммутатора) имеет точность порядка ±16 ppb что удовлетворяет - 3GPP для FDD.

Тогда как NTP имеет точность порядка ±1–10 ms и используется лишь для логов, OSS, handover trace.

OSS (Operations Support System) — это подсистема или набор серверов оператора связи, предназначенных для управления, мониторинга и анализа состояния сети.

Handover trace — это механизм (или тип логов) для анализа передач обслуживания (handover) между сотами, сектором или разными узлами сети.

Он используется инженерами OSS или SON для:

отладки handover-параметров (например, слишком ранние/поздние переключения);
анализа провалов (failures) и задержек;
оптимизации соседних сот (neighbor relations).

Когда UE (телефон) выполняет handover между eNB/gNB, базовая станция генерирует trace record.

В этой записи содержится:

IMSI / IMEI (идентификаторы);
Cell ID, eNB ID, TAC, частота, PCI;
Timestamp (время события);
Тип handover (intra-frequency, inter-frequency, inter-RAT);
Причины и результат (успешный/ошибка).
Эти записи отправляются на OSS или trace server (через интерфейс Itf-N или FTP/HTTP API).

Без точного времени (UTC/NTP) такие логи невозможно корректно сопоставить между сотами, поэтому NTP нужен для того, чтобы все handover traces имели согласованное время.

Важные критерии

Когда мы говорим о связке SyncE + NTP (а не SyncE + PTP), то обычно речь идёт о системе, где требуется частотная синхронизация для радиоинтерфейса и временная согласованность (time-of-day) для управления, логов, OSS и анализа событий.

Давай разберёмся чётко:

какие именно критерии критичны,
что нужно проверять/гарантировать,
какие параметры считаются «нормой» для базовой станции (eNB/gNB, FDD-режим, без фазовых требований).

Критерии корректной работы связки SyncE + NTP

Стабильность и точность частоты (SyncE)

Что проверяем:

наличие Ethernet-линка, поддерживающего Synchronous Ethernet (PHY-level clock recovery);
базовая станция (или RU/DU) должна быть slave к SyncE-мастеру (EEC / ESMC-source);
PLL в устройстве должна «захватывать» внешний SyncE-такт и удерживать частоту в требуемом диапазоне.

Нормативные параметры:

ПараметрТребованиеИсточникFrequency accuracy≤ ±0.05 ppm3GPP TS 36.104 §6.6.2Holdover stability≤ ±0.1 ppm за 24чITU-T G.8262MTIE / TDEVв пределах G.8262-EEC specITU-T G.8262 Appendix I

Практически:

На Linux-устройствах (DU/eNB) можно проверять состояние SyncE через ethtool --show-eee или ethtool -T ethX, а также через драйвер PHC (/dev/ptpX), если PLL доступен.

Согласование времени суток (NTP)

Цель: чтобы логи и OSS-записи имели одинаковые временные метки в UTC.

Что проверяем:

eNB/gNB имеет корректный NTP-клиент (обычно chronyd или ntpd);
используется надежный источник NTP, например stratum-1 сервер с GNSS-опорой;
задержка (offset) относительно NTP-сервера не превышает допустимого порога.

Практически:

Проверяем командой chronyc tracking или ntpq -p.
Offset в пределах ±5 ms — отлично.
Offset > 50 ms — уже заметно в trace-логах между сотами.

Отсутствие конфликтов между SyncE и NTP

Эти два протокола не конкурируют напрямую, но возможны проблемы, если:

системные часы (system clock) и PHC (hardware clock от SyncE) не согласованы;
NTP пытается корректировать системное время слишком резко, вызывая скачки timestamp’ов.

Решения:

Использовать phc2sys (если SyncE clock доступен как PHC-устройство) для плавной синхронизации системного времени от аппаратных часов;
Настроить NTP/chrony на режим «slew only» (не делать резких «step»-коррекций);
Проверить, чтобы chronyd и phc2sys не синхронизировали одно и то же направление (во избежание петли).

Качество источников (Reference hierarchy)

SyncE:

Используется Ethernet Equipment Clock (EEC) с качеством PRC (Primary Reference Clock);
Информация об источнике качества передаётся через ESMC (Ethernet Synchronization Messaging Channel).

NTP:

Используется stratum-1 сервер с GNSS/atomic опорой;
Структура:

GNSS → NTP stratum-1 → Transport network → eNB NTP client

Главное правило:

все узлы получают частоту от одного PRC-источника, а время от одного stratum-1 NTP-сервера.

Если SyncE временно теряется (link down):

PLL устройства должен удерживать частоту (holdover mode);
отклонение не более ±0.1 ppm в течение 24 часов.

Если NTP-сервера недоступны:

система продолжает работать (нет влияния на радиочасть);
но метки логов могут начать дрейфовать — рекомендуется контроль alert при offset > 100 ms.

Что мониторить оператору:

SyncE lock state - проверяем что значение "locked" и NTP offset не более ±10 ms и System clock drift не более ±0.1 s/day, а также SyncE ESMC quality (его статус должен быть в норме).

ESMC (Ethernet Synchronization Messaging Channel) — это служебный механизм в стандарте ITU-T G.8264, который используется в сетях SyncE (Synchronous Ethernet) для передачи информации о качестве тактового сигнала (Synchronization Quality Level, QL) между устройствами.

Он работает на уровне Ethernet L2, используя специальные EtherType 0x8809 (OAM PDU) кадры, которые передаются периодически по каждому линку (обычно раз в 1 с).

Как это работает на практике

Каждый коммутатор или базовая станция:

Получает ESMC от соседа → читает его QL (например, QL=PRC).
Сравнивает этот QL с качеством своих других портов.
Выбирает лучший (с наивысшим QL).
Передаёт дальше ESMC со своим собственным QL (обычно пониже, чтобы не образовать замкнутую петлю).