Опишите процессы синхронизации в компьютерных сетях
Обновлено: 07.07.2024
Существует два способа передачи информации в физической передающей среде: цифровой и аналоговый.
При цифровом способе данные по проводнику передаются импульсно, путем смены текущего напряжения: нет напряжения - "0", есть напряжение - "1".
Передать цифровые данные по аналоговому каналу можно, управляя одним из параметров сигнала несущей частоты: амплитудой, частотой или фазой. Поскольку необходимо передавать данные в двоичном виде (последовательность единиц и нулей), то можно предложить следующие способы управления (модуляции): амплитудный, частотный, фазовый.
Амплитудная модуляция "0" - отсутствие сигнала, т.е. отсутствие колебаний несущей частоты; "1" - наличие сигнала, т.е. наличие колебаний несущей частоты. Есть колебания - единица, нет колебаний - нуль:
Частотная модуляция Частотная модуляция предусматривает передачу сигналов 0 и 1 на разной частоте. При переходе от 0 к 1 и от 1 к 0 происходит изменение частоты колебаний сигнала:
Фазовая модуляция При переходе от 0 к 1 и от 1 к 0 меняется фаза колебаний, т.е. "направление" колебаний.
Канал передачи данных
Канал передачи - это комплекс технических средств и среды распространения, обесп5ечивающий передачу сигнала электросвязи в определенной полосе частот и с определенной скоростью передачи между сетевыми станциями и узлами сети.
В зависимости от среды распространения сигналов каналы могут быть проводными, радио, спутниковыми.
В зависимости от частотного диапазона различают каналы узкополосные и широкополосные.
Канал называется узкополосным, если по нему передаются данные только на одной частоте.
Канал называется широкополосным, если он пропускает много частот, т.е. каждый абонент работает в пределах этого канала на своей собственной частоте.
Каналу передачи присваивается название "аналоговый" или "цифровой", в зависимости от способа передачи сигналов электросвязи. Если на разных участках канала применяется тот и другой методы, канал передачи называется смешанным.
Характеристики процесса передачи данных
Для характеристики процесса передачи данных в компьютерной сети по каналам связи используются следующие понятия: режим передачи, код передачи, тип синхронизации.
Режимы передачи данных
Симплексный - передача данных только в одном направлении (телевидение, радио); Полудуплексный - прием и передача информации осуществляется поочередно (рация); Дуплексный - одновременные передача и прием данных (телефон).Дуплексный режим является наиболее скоростным режимом работы и позволяет эффективно использовать вычислительные возможности быстродействующих ЭВМ в сочетании с высокой скоростью передачи данных по каналам связи.
Коды передачи данных
Информация передается по каналам связи в виде специальных кодов. Коды эти стандартизованы и определены рекомендациями ISO (International Organization for Standardization) - Международной организации по стандартизации или международного консультативного комитета по телефонии и телеграфии (МККТТ).
Наиболее распространенным кодом передачи по каналам связи является код ASCII , принятый для обмена информацией практически во всем мире (отечественный аналог - код КОИ-7).
Если для передачи кодовой комбинации используется столько линий, сколько битов эта комбинация содержит, т.е. каждый бит передается по отдельному проводу, то это - параллельная передача или передача параллельным кодом. Предпочтение такой передаче отдается для внутренних связей ЭВМ и для небольших расстояний между абонентами сети. Передача параллельным кодом обеспечивает высокое быстродействие, но требует повышенных затрат на создание физической передающей среды и обладает плохой помехозащищенностью.
Типы синхронизации данных
Процессы передачи или приема информации в компьютерных сетях могут быть привязаны к определенным временным отметкам, т.е. один из процессов может начаться только после того, как получит полностью данные от другого процесса. Такие процессы называются синхронными.
В то же время существуют процессы, в которых нет такой привязки и они могут выполняться независимо от степени полноты переданных данных. Такие процессы называются асинхронными.
Синхронизация данных - согласование различных процессов во времени. В системах передачи данных используются два способа передач данных: синхронный и асинхронный.
При асинхронной передаче каждый символ передается отдельной посылкой. Стартовые биты предупреждают приемник о начале передачи. Затем передается символ. Для определения достоверности передачи используется бит четности (бит четности равен 1, если количество единиц в символе нечетно, и 0 в противном случае). Последний бит ("стоп-бит") сигнализирует об окончании передачи.
Преимущества: несложная отработанная система; недорогое (по сравнению с синхронным) интерфейсное оборудование. Недостатки: третья часть пропускной способности теряется на передачу служебных битов (старт/стоповых и бита четности); невысокая скорость передачи по сравнению с синхронной; при множественной ошибке с помощью бита четности невозможно определить достоверность полученной информации.
Асинхронная передача используется в системах, где обмен данными происходит время от времени и не требуется высокая скорость передачи данных. Некоторые системы используют бит четности как символьный бит, а контроль информации выполняется на уровне протоколов обмена данными.
При использовании синхронного метода данные передаются блоками. Для синхронизации работы приемника и передатчика в начале блока передаются биты синхронизации. Затем передаются данные, код обнаружения ошибки и символ окончания передачи. При синхронной передаче данные могут передаваться и как символы, и как поток битов. В качестве кода обнаружения ошибки обычно используется циклический избыточный код обнаружения ошибок ( CRC - Cyclic Redundance Check ). Он вычисляется по содержимому поля данных и позволяет однозначно определить достоверность принятой информации. Если код, сформированный при приеме, совпадает с кодом, сформированным при передаче - ошибок нет. Блок данных принят. Если же последовательности не совпадают - ошибка. Передача повторяется до положительного результата проверки. Если повторные передачи не дают положительного результата, то фиксируется состояние аварии.
Преимущества: высокая эффективность передачи данных; высокие скорости передачи данных; надежный встроенный механизм обнаружения ошибок. Недостатки: интерфейсное оборудование более сложное и, соответственно, более дорогое.
Если вы решили написать собственный синхронизатор, то скорее всего столкнётесь с рядом вопросов. В этой статье мы поделимся опытом написания такого компонента и рассмотрим требования, предъявляемые к нему. В основу этих требований легли всевозможные пожелания, полученные нами от пользователей, и реальные сценарии использования синхронизатора событий планировщика XtraScheduler. Потому в качестве примеров кода будем приводить фрагменты кода от указанного продукта.
Для начала определим, какие объекты будут участвовать в процессе синхронизации.
Это два набора данных (исходный и целевой/конечный) и синхронизатор, который выполняет ряд операций над этими наборами, в результате которых целевой набор должен измениться в соответствии с реализуемым сценарием.
Объект синхронизатор
Сценарий синхронизации будет определять, каким функционалом будет обладать ваш синхронизатор. Если синхронизация подразумевает только одну «главную» копию и будет выполняться полным замещением содержимого другой, то подойдет простой вариант вида импортер/экспортер. Если же планируется выполнять синхронизацию наборов независимых записей, то придется делать более сложную реализацию синхронизатора.
Базовый класс
Создайте базовый класс синхронизатора, определяющий общее для всех наследников поведение и интерфейс методов, свойств и событий. Назовем такой класс, например, SynchronizerBase. Такой класс может определять строго определенный порядок вызовов абстрактных методов для выполнения основных необходимых действий синхронизации в нужной последовательности. Функционал будет расширяться путём наследования. Наличие базового класса освободит вас от дублирования кода. Такие общие операции, как инициализация внутренних структур и свойств, могут быть реализованы один раз в этом классе.
Дополнительным плюсом такого подхода будет являться то, что вы получите единый стройный API для всех реализуемых впоследствии наследников.
Разделение обязанностей
В зависимости от сценариев работы с наборами данных, вы можете реализовать соответствующих наследников SynchronizerBase, которые «умеют» выполнять последовательность заложенных в сценарии действий, заранее «зная», какой набор является «главным». Такие специализированные классы будут гораздо проще в использовании, чем настройка и использование единственного, но «умеющего всё и сразу».
Таким образом, вы можете создать несколько наследников, например, ImportSynchronizer и ExportSynchronizer, реализующих основную логику синхронизации для каждого из сценариев. Эти классы могут остаться абстрактными, если в дальнейшем вы планируете реализовывать их конкретных наследников для различных наборов данных.
Например, в XtraScheduler у нас получилась следующая схема базовых классов:
Выделение алгоритмов в подклассы
Чтобы не делать объект синхронизатора слишком нагруженным, имеет смысл организовать архитектуру, отделив реализацию алгоритма синхронизации от интерфейса самого синхронизатора. Выделите подкласс в классе-синхронизаторе, не забыв при этом наладить взаимодействие между этими объектами.
Операции над объектами наборов данных
- создать новую копию объекта на целевом наборе на основании объекта из исходного набора данных;
- обновить соответствующий объект в целевом наборе с учетом изменений объекта в исходном наборе;
- удалить «лишние» объекты на целевом наборе, которые отсутствуют в исходном.
Описанные действия должны быть реализованы в том или ином виде в каждом из наследников вашего синхронизатора. При этом необходимо учесть важный момент, какую копию данных считать «главной». В зависимости от выбора исходный и целевой наборы могут меняться местами. Именно поэтому классы ImportSynchronizer и ExportSynchronizer будут выполнять противоположные действия над наборами данных.
Поддержка событий
Несомненно, при выполнении любого действия над объектами наборов пользователь захочет иметь возможность получить доступ к этим объектам «до» и «после» выполнения операции. Организуйте пару событий Synchronizing и Synchronized в базовом классе.
Определите аргументы обработчика событий SynchronizingEventArgs и SynchronizedEventArgs и добавьте туда поля и свойства для соответствующих объектов из синхронизируемых наборов. В случае, когда в базовом классе это невозможно сделать сразу, воспользуйтесь наследованием аргументов и сделайте недостающие свойства в наследниках.
Рассмотрите необходимость наличия событий на обработку исключений. Например, вы можете реализовать событие OnException и перенаправлять полученные исключения туда. Дайте возможность пользователю решать — стоит ли продолжать процесс синхронизации после возникновения исключения. Дополните аргументы события всей необходимой информацией.
Сохранность данных
Поддержите для выполнения каждой операции над объектами наборов возможность отмены. Это можно сделать путём добавления свойства Cancel в аргументы события SynchronizingEventArgs.
Будьте уверены, что это обязательно пригодится для выполнения сценария «объединения» двух независимых наборов данных, когда имеет смысл отменять все операции на удаление при выполнении сначала синхронизации сначала в одну сторону, а потом в другую.
Покрытие всех сценариев манипуляции с объектами
Предусмотрите ситуацию не только отменять предложенное «по умолчанию» действие над объектом, но и дать возможность выполнить другую возможную операцию.
Например, добавьте в аргументы дополнительное свойство SynchronizeOperation < Create, Replace, Delete >и дайте пользователю возможность указать желаемое значение. Тем самым, вы получите возможность удалить объект на целевом наборе данных вместо замещения его копией из исходного набора.
Такой подход даёт возможность более точно обрабатывать «конфликты правок» в наборах данных.
Элементы UI
Кэшировние данных
Иногда имеет смысл загрузить набор данных, сохранив его объекты в синхронизаторе. Это имеет смысл, когда желательно избежать повторных обращений к реальному набору данных. К тому же, в процессе выполнения синхронизации целевой набор данных может меняться, что потенциально может проявиться в проблемах, связанных с итерированием по этому набору из кода синхронизатора.
Параметризация набора данных
Рано или поздно пользователь захочет синхронизировать не весь набор, а только его часть, ограниченную, к примеру, временным интервалом или специфическим параметром.
Решением будет являться написание провайдера исходных данных с возможностью пользователю «подсунуть» свой провайдер, определяющий свою логику. При этом синхронизатор должен получать данные не напрямую, а через провайдер. В этом случае придётся использовать описанное выше кэширование данных внутри синхронизатора.
Завершение процесса
Предусмотрите возможность завершить процесс синхронизации по желанию пользователя. К примеру, заведите метод Terminate в базовом классе SynchronizerBase. Такая функция может быть полезна, когда при синхронизации больших наборов данных возникло исключение или объект набора не удовлетворяет неким условиям и необходимо немедленно прервать дальнейшее выполнение. В таком случае пользователю уже не придётся дожидаться окончания процесса.
Расширяемость
Может случиться так, что пользователь захочет синхронизировать свойства, отличные от тех, которые синхронизирует ваш компонент. Предоставьте возможность определять это на уровне задания пользовательских свойств или объектов и предоставьте всё необходимое API для этого.
Дайте возможность пользователям наследоваться от вашего синхронизатора для переопределения какой-либо функциональности. Предусмотрите это при проектировании классов и методов.
Вспомогательные классы
Создайте методы для получения параметров инициализации синхронизатора (например каталог, указываемый на конкретный календарь) или любой другой необходимой для синхронизации информации. Для более удобного использования вынесите их в отдельные вспомогательные классы или сделайте доступными прямо в компоненте.
Очень надеемся, что приведённый выше «сборник советов» поможет вам наилучшим образом определить объём необходимой вам функциональности перед написанием синхронизатора и даст возможность избежать ошибок в процессе его реализации.
Для обеспечения качественной работы цифровых сетей требуется битовая синхронизация, с помощью которой передатчик и приемник работают с импульсами одинаковой длительности. Другими словами, битовая синхронизация определяет, что каждый кадр передается на 125 мсек и каждый импульс имеет соответствующую длительность.
С битовой синхронизацией связаны два распространенных типа помех – вставки и выпадения. Они получаются за счет того, что тактовая частота, на которой работает передатчик, неточно совпадает с частотой работы приемника. Так, если приемник сканирует принимаемый сигнал несколько чаще, чем их выдает передатчик, то вскоре окажется, что на интервал одного бита попадет два синхроимпульса, и, таким образом, этот бит как бы раздвоится, т.е. произойдет вставка бита, что и вызовет ошибку при приеме. Другой тип ошибки – выпадение – происходит, если частота приемника меньше частоты передатчика. В этом случае произойдет ситуация, когда на один из битов не придется ни одного синхроимпульса. Очевидно, что чем более совпадают частоты передатчика и приемника, тем меньше будет встречаться вставок и выпадений.
Чтобы предотвратить ошибки такого рода, необходимо обеспечить синхронную и синфазную работу передатчика и приемника. Это можно осуществить двумя способами. На верхнем уровне сети вводится высокостабильный главный тактовый генератор, на частоту и фазу которого настраиваются тактовые генераторы всех станций. Известен и другой метод, при котором синхронизация достигается за счет взаимной регулировки тактовых генераторов сети. При этом каждый тактовый генератор устанавливает свою частоту, усредняя фазы тактовых сигналов, поступающих от других генераторов. В этом случае для устранения различий в фазах на входах приемников также необходимы запоминающие устройства.
Таким образом, для точной работы цифровых каналов и сетей необходимо выполнять, во-первых, протокольные методы синхронизации (битовой или цикловой) и, во-вторых, осуществлять чисто физическую синхронизацию взаимодействующих устройств. Для этого на сети необходим очень точный тактовый генератор. Так, главный тактовый генератор имеет атомный эталон частоты, стабильность которого равна 10 11 Гц. При такой стабильности ошибки, связанные с синхронностью и синфазностью, встречаются столь редко, что средний коэффициент ошибок остается в допустимых пределах.
Вопросы для самопроверки
1. Можно ли цифровые сигналы передавать по аналоговым каналам связи?
2. Может ли пропускная способность канала быть ниже ширины спектра канала?
3. Для восстановления сигнала необходимо знать значение несущей частоты и значения гармоник. Верно ли это утверждение, если да, то сколько гармоник необходимо знать?
4. Какая пропускная способность канала является основой для цифрового телефонного сигнала?
5. Зачем используется кодирование информации перед передачей ее по каналам связи?
Примечание. Н/н — не нормируется.
Плохая синхронизация оказывает крайне негативное влияние на работу сетей мобильной связи. Так, при плохой синхронизации сужается полоса пропускания сетей LTE-A CoMP, в сетях LTE-A eICIC усиливаются помехи между сотами, в сетях LTE-TDD прерываются звонки, а также уменьшается спектральная эффективность этих сетей.
Синхронизация систем автоматизации работы электрических подстанций
Для выполнения передовых функций автоматизации работы электрических подстанций, включая широкомасштабный контроль комплексных амплитуд тока и напряжения, а также передачу выборочных измеренных значений тока и напряжения по шинам процессов, современному оборудованию подстанций требуется временная синхронизация с точностью не хуже 1 мкс, тогда как традиционному оборудованию обычно достаточно точности 1–2 мс. Для синхронизации защитных реле и других устройств с точностью не хуже 1 мкс в качестве технологии временной синхронизации применяется протокол PTP. На Рисунке 2 представлен пример Ethernet-сети электрической подстанции с осуществлением временной синхронизацией по протоколу PTP.
Рисунок 2. Локальная сеть подстанции с осуществлением временной PTP-синхронизации
Альтернатива сетевой синхронизации
Альтернативой передаче сигналов синхронизации по сети связи является оснащение каждого нуждающегося в синхронизации сетевого устройства (например, каждой базовой станции) приемником ГНСС (или ПЭИ на базе такого приемника). Достоинством данного способа синхронизации является то, что приемник ГНСС может выдавать высокоточный синхросигнал, который соответствует самым строгим требованиям к частотной и фазово-временной синхронизации. Системы ГЛОНАСС, GPS, Galileo и BeiDou обеспечивают фазовую синхронизацию с точностью ±100 нс. Однако с реализацией этого способа связан ряд трудностей: необходимо гарантировать постоянную прямую видимость нескольких навигационных спутников для антенн всех установленных приемников ГНСС, что не всегда возможно; сигналы ГНСС могут быть подавлены преднамеренными и не преднамеренными помехами (помехи могут создаваться погодными условиями и отражением сигналов ГНСС от высоких зданий); высокая стоимость установки и обслуживания многочисленных приемников ГНСС. Все это повышает актуальность применения сетевой синхронизации.
Методы синхронизации в пакетных сетях
Пакетные сети являются асинхронными, но в синхронизации нуждаются определенные виды оборудования, подключаемого к этим сетям, например базовые станции мобильной связи и защитные реле электрических подстанций. Для высокоточной синхронизации по сетям Ethernet широко используются технология SyncE и протокол PTP.
Технология SyncE
Данная технология обеспечивает частотную синхронизацию устройств-потребителей по физическому уровню Ethernet с привязкой к синхросигналу эталонной частоты от ПЭГ (см. Рисунок 3).
Рисунок 3. Синхронизация по физическому уровню Ethernet
SyncE отличается от обычной технологии Ethernet только наличием функции синхронизации, такой же как в сетях SDH. В сети синхронизации по технологии SyncE используются ВЗГ по тем же самым причинам и правилам проектирования, что и в сети SDH (см. Рисунок 1).
Технология SyncE специфицирована в ряде рекомендаций MCЭ-T:
- G.8261: Timing and synchronization aspects in packet network.
- G.8262: Timing characteristics of Synchronous Ethernet equipment slave clock.
- G.8264: Distribution of timing through packet networks.
В рекомендации G.8261 определены основные аспекты синхронизации в пакетных сетях, заданы предельно допустимые характеристики джиттера и блуждания фазы синхросигнала в сети SyncE и другие характеристики.
Синхронизация на базе пакетов
Протокол PTP, соответствующий стандарту IEEE 1588v2, считается самым эффективным синхронизирующим решением, работающим поверх пакетной сетевой инфраструктуры. Он выполняет все требования по точности частотной, фазовой и временной синхронизации. Представляя собой решение типа «ведущий/ведомый» (master/slave), данный протокол обеспечивает очень точную синхронизацию времени — до нескольких сотен наносекунд. Для успешной работы протокола PTP вариация задержки пакетов (PDV) и асимметрия задержки пакетов должны находится в определенных пределах.
Телекоммуникационный профиль для частотной синхронизации
Данный телекоммуникационный профиль, определенный рекомендацией МСЭ-T G.8265.1, предназначен для обеспечения частотной синхронизации с использованием протокола PTP по не поддерживающим этот протокол существующим пакетным телекоммуникационным сетям. Используя одноадресные IP-пакеты, ведомые часы PTP, находящиеся далеко от центрального синхронизатора — ведущих часов PTP, называемых грандмастером, получают информацию, нужную для частотной синхронизации. Должны соблюдаться ограничения на PDV.
Профили для частотной и фазовой синхронизации
Для реализации этих профилей, определенных в рекомендациях МСЭ-Т G.8275.1 и G.8275.2, центральные ведущие часы PTP передают PTP-потоки по сети, все элементы которой поддерживают протокол PTP (G.8275.1) или этот протокол поддерживает только часть сетевых элементов (G.8275.2).
Для реализации частотной и фазовой синхронизации с гарантированным качеством в рекомендации МСЭ-Т G.8275.1 требуется, чтобы для уменьшения PDV все сетевые элементы имели функционал прозрачных или граничных часов PTP и поддерживали технологию SyncE. Выполнить это требование на существующей сети (где нет устройств с поддержкой SyncE и PTP) сложно и дорого. В рекомендации МСЭ-Т G.8275.2 содержится более мягкое требование: допускается, чтобы функционал граничных часов был только в части сетевых элементов. Для успешной синхронизации при использовании этих профилей нужно соблюдать ограничения по PDV и асимметрии задержки пакетов.
Центральные ведущие часы PTP
При таком подходе к синхронизации, чтобы достичь нужных ведомых часов, пакеты PTP обычно проходят через множество транзитных сетевых элементов. Данная архитектура системы синхронизации (см. Рисунок 4) эффективна для частотной синхронизации, поскольку только создаваемая сетью PDV должна быть ограничена.
Рисунок 4. Сеть с центральными ведущими часами PTP
Для обеспечения и поддержания точной фазовой синхронизации на периферии сети в соответствии с требованиями по синхронизации сетей LTE-TDD и LTE-Advanced нужно ограничение не только PDV, но и асимметрии задержки пакетов. В архитектуре с центральными ведущими часами PTP вся пакетная транспортная сеть должна поддерживать PTP, то есть каждый элемент сети должен работать как граничные или прозрачные часы, что проблематично обеспечить в большинстве ныне действующих сетей.
Лучший подход: распределенные мини-грандмастеры
Существует альтернативный подход к обеспечению синхронизации по протоколу PTP, предполагающий размещение недорогих мини-грандмастеров на периферии сети (см. Рисунок 5). При таком подходе средних характеристик производительности и емкости центральных ведущих часов PTP достаточно для обслуживания меньшего числа ведомых часов, каковыми для центральных ведущих часов являются мини-грандмастеры. Размещение их на первом уровне агрегации трафика позволяет начать распределение синхронизации по протоколу PTP ближе к местам установки ведомых часов (например, подключенных к базовым станциям).
Рисунок 5. Сеть с центральными ведущими часами PTP и мини-грандмастером
Передача пакетов PTP через небольшое число транзитных устройств между мини-грандмастером и ведомыми часами имеет два достоинства. Во-первых, это упрощает обеспечение надежности PTP-синхронизации, а во-вторых, избавляет от необходимости реализовывать поддержку PTP по всей сети.
Концепция APTS и автокалибровка
Согласно концепции APTS (Assisted Partial Timing Support), мини-грандамастер использует ГНСС в качестве первичного источника информации о времени, но при отказе своего приемника ГНСС может переключиться на опорный сигнал, восстановленный с использованием PTP-пакетов, посланных центральными ведущими часами PTP. Концепция APTS определена рекомендацией МСЭ-Т G.8275.2.
Использование синхронизации по сигналам ГНСС и сетевой PTP-синхронизации также обеспечивает автокалибровку алгоритма восстановления PTP. Автокалибровка используется для активной компенсации динамической асимметрии сети и мониторинга годности синхросигнала, восстановленного посредством PTP-синхронизации с центральными ведущими часами PTP.
Концепция APTS и автокалибровка значительно смягчают требование по использованию поддерживающих протокол PTP сетевых элементов на пути следования пакетов PTP от ядра до периферии сети.
Мониторинг качества синхронизации в пакетных сетях
Для оперативного выявления проблем с сетевой синхронизацией нужно постоянно контролировать параметры ее качества. Чтобы реализовать такой контроль, в ряд моделей оборудования PTP встроены функции пробника синхронизации. Существуют и внешние аппаратно-программные пробники. В рекомендации МСЭ-Т G.8273 предусмотрены активный и пассивный пробники синхронизации (см. Рисунок 6).
Рисунок 6. Варианты подключения активного и пассивного пробников синхронизации
Пассивный пробник контролирует качество синхронизации, получая трафик PTP, снимаемый с линии сети с помощью ответвителя. Возможен и вариант контроля с использованием сигнала 1PPS. В обоих случаях пассивный пробник выступает в роли «стороннего наблюдателя» за работой системы синхронизации. Активный же пробник участвует в обмене пакетами PTP и проводит измерения параметров качества синхронизации, передавая и принимая эти пакеты. Для гибкости установки на сетевые инфраструктуры желательно, чтобы встроенный пробник поддерживал работу в активном и пассивном режимах.
Лабораторное тестирование оборудования PTP
Тестирование ведомых часов для частотной синхронизации
Методы тестирования ведомых часов при использовании протокола PTP для частотной синхронизации представлены в Дополнении 6 в составе рекомендации МСЭ-Т G.8261. В данной рекомендации определены топологии испытательных стендов и 17 различных вариантов тестирования (тестовых примеров), моделирующих «поведение» сети. В каждом из вариантов тестирования измеряются параметры ОВИ, МОВИ, МООВИ, точность частоты, PDV, точность ToD. Результаты тестирования должны соответствовать сетевым ограничениям, изложенным в разделе 9 данной рекомендации.
Согласно МСЭ-Т G.8261, в качестве сети с коммутацией пакетов, по которой передаются пакеты PTP между ведущими часами и тестируемыми ведомыми часами, в составе испытательного стенда надлежит использовать «цепочку» из 10 коммутаторов GE с двумя генераторами фонового трафика — в прямом и обратном каналах. Построение модельной сети из десяти коммутаторов требует значительных временных и денежных затрат. К тому-же, ее параметры не воспроизводимы в различных реализациях. Лучше использовать специальный тестер синхронизации, имитирующий эти десять коммутаторов. Хорошим дополнением к указанным в рекомендации тестам является проверка работы ведомых часов PTP в реальных условиях. Для этого используется тестер синхронизации, способный захватывать профиль PDV в действующей сети и воспроизводить его в лаборатории.
Тестирование граничных часов для синхронизации времени и фазы
Для нормальной работы ряда технологий RAN (включая TDD-LTE и LTE-A) требуется высокоточная фазовая синхронизация базовых станций в дополнение к их частотной синхронизации (см. Таблицу 2). Но большинство современных сетей IP/Ethernet имеют слишком большие PDV и асимметрию задержки передачи пакетов для реализации высокоточной фазовой синхронизации по протоколу PPP. Чтобы обеспечить высокую точность фазовой PPP-синхронизации, нужно использовать граничные часы в сети, что и предусмотрено рекомендацией МСЭ-Т G.8275.1 (первый профиль для синхронизации времени/фазы).
Если точность синхронизации базовых станций должна быть ±1,5 мкс, то таким же является бюджет временной ошибки сети на пути от ведущих часов до ведомых. Этот бюджет состоит из постоянной временной ошибки (Constant Time Error, cTE) и динамической временной ошибки (Dynamic Time Error, dTE). В рекомендации МСЭ-Т G.8271.1 на 10 граничных часов и одни ведомые часы выделена часть cTE размером ±550 нс. Таким образом, cTE одних граничных часов должна быть в пределах ±50 нс. Если сTE какой-либо модели граничных часов находится в пределах ±100 нс, то можно последовательно соединить не более пяти таких устройств. Поэтому крайне важно точно измерять cTE граничных часов.
В рекомендации МСЭ-Т G.8273.2 нормированы показатели генерации и передачи временной ошибки, устойчивости к временным ошибкам, а также Transients и Holdover performance. Эти параметры подлежат тестированию на соответствие требованиям данной рекомендации. Тестирование лучше проводить с помощью специального прибора, заменяющего собой целый стенд с тестовым оборудованием. Применение такого прибора упрощает процесс испытаний, способствует повышению точности и воспроизводимости результатов измерений.
Тестирование прозрачных часов
Прозрачные часы рассчитывают время (в наносекундах), в течение которого PTP-пакет находится внутри них, и помещают полученное значение времени в поле коррекции PTP-пакета. Используя это значение, ведомые или граничные часы эффективно устраняют PDV, добавленную прозрачными часами. Основная задача тестирования прозрачных часов заключается в измерении точности содержимого поля коррекции. Требуемая точность — не хуже 50 нс. Тестирование желательно проводить с помощью специального прибора, имитирующего работу ведущих и ведомых часов. Также для создания нагрузки на тестируемые прозрачные часы потребуется генератор трафика.
Полевое тестирование сетевой инфраструктуры
При необходимости перейти на новую технологию RAN, требующую высокоточной фазовой синхронизации базовых станций, сотовый оператор должен проверить готовность сетевой инфраструктуры к внедрению этой технологии. То есть важно знать, имеет ли сетевая инфраструктура, по которой будет передаваться PTP-трафик, нужный бюджет временной ошибки. Для этого рекомендуется использовать высокоточный портативный тестер синхронизации, который измеряет временную ошибку на PTP-потоках, работая в режиме монитора или ведомых часов PTP (см. Рисунок 7).
Рисунок 7. Проверка пригодности сети к высокоточной синхронизации фазы/времени
Портативный тестер должен быть оснащен приемником ГНСС и рубидиевым источником синхросигнала, чтобы обеспечить нужную точность измерения фазы при работе источника в режиме удержания, когда сигналы ГНСС недоступны. Подобный тестер нужен также для поиска неполадок в работе действующей системы сетевой синхронизации и ее аудита.
Читайте также: