Ethernet без права на помилку: передача відео, E1 і сигналів керування без затримок і втрат

"Немережеві" сигнали, телеком та відео по Ethernet - порширена практика

Інженерно-технічний розбір від RV-ZAFT: чому в задачах безпеки мережа стає не «швидкою», а «безпечною». Затримка, втрата пакетів і джитер за стеком OSI, норми Y.1541 та EN 50159, передача E1 псевдодротом, застосування на залізниці й у телекомі, вибір обладнання й перевірка тракту.

Коли по Ethernet їде не «інтернет», а живе відео з камери на переїзді, потік E1 між двома постами централізації чи команда на світлофор — мережа перестає бути просто «швидкою» або «повільною». Вона стає безпечною або небезпечною. Втрачений пакет під час веб-серфінгу означає, що сторінка перезавантажилась. Той самий втрачений пакет у цих задачах означає, що оператор на секунду не побачив людину на колії, або що реле спрацювало не тоді. Ставки — не комфорт, а безпека людей і галузева безпека. Тому тут діють інші правила, інші бюджети й інші норми, ніж у звичайній офісній мережі.

Ця стаття — про те, як зробити цифровий тракт придатним для трафіку реального часу: де народжуються затримка, втрати й джитер, на яких рівнях моделі OSI вони живуть і чим лікуються, які цифри й стандарти вважати орієнтиром, і чим це все перевіряти — від міді до готового каналу. Затримки часто неприпустимі на об'єктах критичної інфраструктури та в галузях, від роботи яких залежить безпека персоналу та населення. 

Три вороги реального часу (і четвертий - для E1)

Якість тут — це не одне число «мегабіти». Це керована сукупність трьох параметрів, а для TDM — чотирьох.

Затримка (latency, IPTD). Час проходження пакета в один бік. Складається з поширення в середовищі, серіалізації (час «виштовхування» пакета в лінію), черг у комутаторах, обробки й буфера джитера. Для «живої» картинки й керування PTZ важлива абсолютна величина; для команди керування — гарантована верхня межа.

Втрата пакетів (packet loss, IPLR). Пакети, що не дійшли: відкинуті при перевантаженні черги, зіпсовані бітовими помилками на L1, зрізані полісером. Для відео втрата б'є нерівномірно — про це нижче. Для E1 і команд втрата неприпустима в принципі.

Джитер (jitter, IPDV / PDV). Варіація затримки: пакети виходять рівно, а приходять «рвано». Саме джитер, а не середня затримка, вбиває буфери приймача. Його згладжують буфером джитера — але буфер додає затримку, тож це завжди компроміс.

Для TDM додається вандер і зрив такту. E1 — це постійний бітпотік із жорсткою тактовою частотою. Крім джитера є вандер (повільний дрейф фази), а головне — приймач мусить відновити тактову частоту джерела з нерівномірного потоку пакетів. Ця відновлена синхронізація гине від джитера найпершою. Окремо існує ще й переставлення пакетів (reordering, IPRR) — для потоку E1 воно так само руйнівне.

Чому кожен тип трафіку страждає по-своєму

Відео (H.264/H.265 поверх RTP/UDP). Стиснене відео нерівноцінне: опорний I-кадр важить у рази більше за проміжні P/B-кадри. Втрата одного пакета I-кадру — це не «квадратик», а «розсипана» картинка до наступного опорного кадру, тобто секунди сміття при типовому GOP. Чим агресивніше стиснення, тим дорожчий кожен втрачений пакет. Джитер вимагає буфера, а буфер — це затримка, якої не хочеться на «живому» перегляді й керуванні поворотною камерою. І фундаментальний вибір транспорту: UDP не перезапитує втрачене (бачимо артефакти), TCP перезапитує (отримуємо лавину затримки й блокування черги). Для відеонагляду в реальному часі RTP поверх UDP майже завжди правильніший за TCP.

E1 / TDM поверх пакета (SAToP, CESoPSN). Тут будь-яка нерівномірність б'є одразу. Буфер компенсації джитера (PDV-буфер) згладжує варіацію ціною фіксованої затримки; якщо джитер перевищив глибину буфера — буфер переповнюється або спустошується, і це негайно бітслипи, помилкові секунди (ES/SES) та зрив кадрової синхронізації E1 з підняттям аварії (AIS, slip). Тип псевдодроту теж має значення: SAToP (RFC 4553) возить нефреймований E1 «як є», з мінімальним оверхедом — оптимальний для вузьких каналів на кшталт SHDSL; CESoPSN (RFC 5086) працює з фреймованим сигналом і дає меншу затримку, коли треба лише кілька таймслотів. І над усім цим — синхронізація: adaptive clock recovery (відновлення такту з потоку) працює, але SyncE чи PTP, де вони доступні, дають на порядок стабільніший такт.

Сигнали керування й сигналізація. Тут не потрібна велика смуга — потрібні детермінізм, обмежена зверху затримка й абсолютна цілісність команди. Один спотворений чи повторений пакет може означати неправильну дію виконавчого механізму. Саме тому для безпекової сигналізації існує окремий пласт норм (нижче), який будує захист поверх ненадійного транспорту.

Прив'язка до моделі OSI: де народжується дефект і де його лікувати

Щоб не боротися з наслідками не на тому рівні, корисно розкласти проблему по стеку.

L1, фізичний. Мідь або оптика: згасання, відношення сигнал/шум, бітові помилки (BER). Саме тут народжуються бітові помилки, що вгорі перетворюються на втрати й зіпсовані пакети, і саме тут — першоджерело джитера й вандера (такт, PLL). На SHDSL це напряму якість лінії; на оптиці — дисперсія й втрати на з'єднаннях. Це фундамент: погана мідь чи поганий сплайс дають BER, який жоден QoS вище не виправить.

L2, канальний. Ethernet і комутація. Тут живе пріоритезація: 802.1p (поле PCP) і поділ на VLAN (802.1Q), а для жорсткого детермінізму — TSN (802.1AS для синхронізації, Qav/Qbv для планування трафіку за розкладом, Qbu для витіснення кадрів, CB для безшовного резервування). Тут же типові біди: помилки CRC/FCS, згубна пастка half-duplex через неузгодження автонегоціації, і flow-control (802.3x pause), який для реального часу зазвичай треба вимикати. На повільному лінку тут проявляється серіалізація — великий кадр надовго займає канал.

L3, мережевий. IP. Кожен зайвий хоп додає затримку й варіацію; фрагментація — ворог реального часу; втрати виникають від переповнення черг (tail-drop) і полісингу. Інструмент керування — DiffServ: маркування DSCP (RFC 2474) і клас EF (Expedited Forwarding, RFC 3246) для трафіку реального часу, плюс дисципліни черг із пріоритетом.

L4, транспортний. Головний вибір — TCP чи UDP. TCP надійний, але його перезапити означають затримку й блокування «голови черги» (head-of-line), а механізм боротьби з перевантаженням душить швидкість під втратами — для «живого» відео й E1 це непридатно. UDP не гарантує нічого, але поверх нього RTP додає порядкові номери й позначки часу (впорядкування + буфер джитера), а RTCP — зворотний зв'язок про якість. Псевдодріт E1 інкапсулюється так само поверх UDP/MPLS/L2.

L5–L7, сеанс, представлення, застосунок. Кодеки (структура GOP, співвідношення I/P — що стисліше, то дорожчий втрачений пакет), шифрування (додаткові затримка й оверхед), і сам застосунок: VMS, RTSP/ONVIF, SIP. Тут же прикладний буфер — знову компроміс «плавність проти затримки».

І поза OSI — площина синхронізації. SyncE (G.8262), PTP/IEEE 1588 (профілі G.8275), TSN 802.1AS — це окремий, ортогональний до даних пласт, що розносить такт і фазу. Без нього не існує ні якісного TDM поверх пакета, ні детермінованих мереж.

Дефект і засіб на кожному рівні стека. Фундамент — L1: без якісної фізики решта не має сенсу.

Норми й цифри: на що орієнтуватися

Параметри тракту формально описані в ITU-T Y.1540 (IPTD — затримка, IPDV — джитер, IPLR — втрати, IPER — бітові помилки, IPRR — переставлення), а цільові пороги — у Y.1541, який задає класи якості:

Правила маркування й обробки DiffServ описані в RFC 4594 та RFC 3246; для здачі каналу з нормативом по пропускній здатності, затримці, джитеру й втратах використовують RFC 2544 або Y.1564. Для E1 поверх пакета діють свої часові маски: G.823 (джитер і вандер тракту 2048 кбіт/с) і G.8261 (бюджет джитера/вандера для псевдодроту в пакетних мережах).

Що реально робити: інженерія тракту

Норми задають ціль, а витягують її кількома конкретними важелями.

Розділяй трафік. Відео, E1, керування й менеджмент — в окремі VLAN із різним пріоритетом. Терміновий трафік не повинен стояти в одній черзі за резервним копіюванням чи оновленнями.

Тримай запас смуги. Ніколи не вантаж канал під 100%. Для реального часу ціль — завантаження не вище 70–80%; черги починають рости й давати джитер задовго до формального «100%».

На повільному лінку — малий MTU. Фрагментація з чергуванням (interleaving), щоб великий кадр не блокував терміновий пакет на час своєї серіалізації. Це прямий наслідок нюансу Y.1541 вище.

Пріоритезуй на кожному переході. 802.1p на L2, DSCP на L3 — і послідовно, від порту камери до сервера. Один вузол без пріоритету зводить нанівець усю схему.

Прибери типові вбивці. Вимкни flow-control pause для реального часу. Полюй на half-duplex через неузгодження автонегоціації — він провалює швидкість у рази й маскується під «погану лінію». Мінімізуй кількість хопів.

Для E1 — правильний псевдодріт і синхронізація. SAToP на вузькому каналі (найменший оверхед), CESoPSN коли треба кілька таймслотів із меншою затримкою. Глибину PDV-буфера підбирай як компроміс «джитер проти затримки». І де є можливість — розноси такт по SyncE/PTP, а не покладайся лише на adaptive clock recovery.

Резервуй зі швидким перемиканням. Кільце з G.8032 (ERPS) відновлюється швидше за 50 мс; для безшовного резерву без жодної втрати — TSN 802.1CB. На магістралі, де потрібна жорстка межа затримки, — TSN цілком.

Галузі: залізниця й телеком

Залізниця

Тут поєднуються всі три типи трафіку й найвищі вимоги. Відео на платформах, переїздах і борту; потоки E1 між станціями й релейними по існуючій міді (legacy TDM, який тепер їде псевдодротом поверх пакета); дані сигналізації й централізації; GSM-R; SCADA тягового живлення. Ключове — безпека, і вона тут виражена нормами прямо.

Профільний стандарт для передачі відповідальних даних — EN 50159 («Safety-related communication in transmission systems»). Він описує саме те, що нас цікавить: як забезпечити безпечний обмін по каналу, який не проєктувався під безпеку. Його захисні механізми — порядкові номери, позначки часу, тайм-аути, ідентифікатори, криптозахист — це відповідь рівно на ті дефекти пакетної мережі, про які вся ця стаття: видалення (втрата), спотворення (бітова помилка), повтор, затримка, переставлення й підміна повідомлень. EN 50159 працює у зв'язці з EN 50126/50128/50129 (RAMS та рівні цілісності безпеки SIL). А електромагнітну стійкість задають EN 50121-4 (стаціонарне обладнання вздовж колії) і EN 50155 (рухомий склад). Тут «недопустима затримка» — не маркетинг, а вимога норми; наведення від контактної мережі 25 кВ псують L1, множать BER і втрати, тож захист і якість міді/оптики стають частиною функції безпеки.

Телеком

Класичні задачі: доставка E1 «останньої милі» по міді чи Ethernet; мобільний backhaul, де потоки E1 від базових станцій 2G/3G возять псевдодротом (тут adaptive clock recovery відновлює тактову частоту для стільникового обладнання); емуляція виділених ліній замість оренди фізичних E1; carrier Ethernet із класами обслуговування (CoS); і розподіл синхронізації (SyncE/PTP) як окрема інфраструктурна послуга. Скрізь той самий принцип: пакетна мережа за своєю природою не гарантує ні смуги, ні часу, тож якість забезпечується прицільно — пріоритетом, буферизацією й синхронізацією.

Обладнання під різні потреби

Реальний час по існуючій міді, із сегментацією. Керовані SHDSL-екстендери з VLAN і кільцями: Phoenix Contact TC EXTENDER 6004, Westermo Wolverine (з класифікацією EN 50121-4/50155 під залізницю), Moxa IEX. Дозволяють розділити відео, керування й менеджмент по VLAN на тонкому каналі; важку політику QoS при цьому тримають комутатори навколо.

E1 поверх Ethernet. Шлюзи псевдодроту: RAD IPmux-24 / IPmux-216 (SAToP, CESoPSN, TDMoIP; апаратний ASIC із мінімальною затримкою; adaptive clock recovery; QoS за 802.1p та DSCP; кільце G.8032 з відновленням до 50 мс) — робочий інструмент для кількох чи кількох десятків E1. Для простіших задач під конкретну лінію є легші TDMoE-шлюзи. Тип псевдодроту обирай під сервіс: SAToP для нефреймованого потоку на вузькому каналі, CESoPSN — коли потрібні окремі таймслоти.

Детермінована магістраль. Керовані промислові комутатори з QoS, TSN і PTP (Hirschmann/Belden, Moxa, Westermo) — там, де потрібна гарантована верхня межа затримки й точна синхронізація.

Синхронізація й оптична магістраль. Джерело SyncE/PTP (grandmaster), коли якість такту критична. І волоконно-оптичне обладнання — медіаконвертери, CWDM — коли відстань чи якість вимагають оптики: це середовище з практично нульовим джитером і несприйнятливе до 25 кВ поруч.

Тестери: фундамент, а не аксесуар

Усе вищесказане тримається на одному: якість тракту треба виміряти, а не припустити. І робити це знизу вгору.

Спершу — фізика (L1). Мідну лінію кваліфікуй кабельним рефлектометром: довжина, дефекти, неоднорідності, опір шлейфа, а через них — очікуваний SNR і BER. Бо бітова помилка на міді — це втрата нагорі, і жоден пріоритет її не поверне. Базовий набір вимірювань закриють кабельні тестери з TDR, схемою пар і трасуванням.

Оптичну магістраль — окремо. Втрати, відбиття та якість зварювань перевіряй оптичним рефлектометром (OTDR): один поганий сплайс сипле помилки на весь тракт, яким їдуть і відео, і E1.

Відеоендпоінти — на місці. Бітрейт, втрати, ping, PoE, потоки RTSP/ONVIF зручно перевірити прямо на камері CCTV-тестером — ще до того, як картинка піде в мережу.

Готовий Ethernet-тракт — під здачу.  Базові функції визначай мережевим тестером. Пропускну здатність, затримку, джитер і втрати з кінця в кінець за RFC 2544 або Y.1564 більш просунутими мережевими приладами — з протоколом, який стає документом, а не «повірте, працює».

Коротко про головне

Якість передачі відео, E1 і сигналів керування — це не «швидкість каналу», а керована сукупність затримки, втрат і джитера (а для TDM — ще й синхронізації), прив'язана до конкретного трафіку, узгоджена з нормами Y.1541 та EN 50159 і підтверджена вимірюванням. Проблему вирішують не на одному рівні, а по всьому стеку — від пріоритезації на L2/L3 і правильного транспорту на L4 до синхронізації поза OSI. Але фундамент завжди внизу: без якісної фізики на L1 будь-який QoS вище безсилий. Тому починається все не з налаштування, а з вимірювання міді та оптики — і закінчується протоколом здачі тракту.

Часті питання

Далі - маленький бонус для прихильників нашого блогу:

Пусконалагодження каналу E1 / відео через SHDSL-екстендер: польовий чек-лист

Практична послідовність приймання каналу «екстендер + шлюз псевдодроту»: які кадри ганяти, які пороги затримки й джитера вважати робочими для E1, і як усе це лягає на PDV-буфер. Друкована версія з полями для запису — у PDF.

Наскрізна логіка одна: якість міді на L1 → джитер пакета (PDV) у мережі → буфер джитера мусить його поглинути → глибина буфера задає затримку. І єдиний критерій приймання: 0 бітових помилок і 0 slip'ів на витримці, яка включає найгірший момент (для залізниці — прохід поїзда). Не «картинка є», а чисті лічильники.

Крок за кроком

0. Бюджет смуги — до всього. Один E1 через псевдодріт це ≈ 2,2–2,8 Мбіт/с Ethernet (залежно від розміру пакета й VLAN). SHDSL має синхронізуватися помітно вище — орієнтир ≥ ~1,5× цієї смуги. Перевір реальну швидкість синхро на своїй лінії: якщо вона дає ~2,3 Мбіт/с, один E1 не влазить із запасом — потрібен 4-дротовий режим, товща жила або коротше плече.

1. Ethernet-тракт: RFC 2544 + витримка. Прожени мережевим тестером кадри 64/128/256/512/1024/1518 Б, але головний замір — на розмірі, що дорівнює пакету псевдодроту (для SAToP типово 256–300 Б). Дивись throughput без втрат, затримку і, критично, варіацію затримки (PDV). Далі — витримка: постійне навантаження на рівні смуги псевдодроту на години, обов'язково через прохід поїзда. Фіксуй loss і max PDV у часі: п'ять хвилин наводок від 25 кВ не покажуть.

2. Підняти псевдодріт із запасним буфером. Старт із великим PDV-буфером (16–32 мс) — свідомо безпечно, без under/overrun. Тип: SAToP для нефреймованого E1 (найменший оверхед — на вузькому каналі це важливо), CESoPSN — якщо возиш окремі таймслоти.

3. Виміряти під навантаженням. З лічильників шлюзу: втрачені й переставлені пакети, underrun/overrun буфера, поточний і max PDV. Знову — через прохід поїзда. E1-аларми: 0 × AIS/LOF, slips = 0.

4. Підтягнути буфер до мінімуму. Знижуй буфер крок за кроком до «виміряний max PDV + 2–3 мс запасу», стежачи за першими under/overrun. Зупинись вище цього порогу. Менший буфер = менша затримка, але й менший запас проти сплесків. Не жени буфер у нуль заради затримки: E1 легше переживе десяток зайвих мілісекунд, ніж один slip.

5. Синхронізація. Adaptive clock recovery локається на прибуття пакетів, тому чутливий до PDV. Якщо є спільна опора (зовнішній такт, SyncE або loop timing від самого E1) — бери її: на вузькій джитерній лінії вона стабільніша за ACR. На залізниці опора зазвичай є.

6. BERT на E1. Зашлейф дальній E1 (апаратно або loopback шлюзу), пусти BERT із шаблоном 2¹⁵−1 / 2²³−1 (O.151): мінімум 15 хв для швидкої перевірки, 24 год для приймання. Критерій — 0 помилок, slips = 0, вкластися в ESR/SESR за G.826 / M.2100.

Пороги (робочі орієнтири)

Відео на тому ж каналі

Відео толерантніше за E1 (є буфер, UDP переживає артефакти), тож якщо лінія пройшла E1 — відео пройде. Але E1 мусить мати строгий пріоритет над відео: окремі VLAN + 802.1p/DSCP. Великий відеокадр серіалізується на повільному лінку кілька мілісекунд і додає E1 джитер — тому обмеж MTU. Ендпоінт перевір CCTV-тестером (бітрейт, втрати, RTSP) і глянь на артефакти втрати I-кадру під навантаженням.

Протокол вимірювань (що зафіксувати)

Для доказової здачі фіксуй: об'єкт і лінію (тип кабелю, довжина); швидкість синхронізації SHDSL і режим (2/4-дрот); смугу псевдодроту й отриманий запас; результати RFC 2544 (втрати на розмірі пакета псевдодроту, max PDV); обраний PDV-буфер і виміряну односпрямовану затримку; лічильники under/overrun, E1 slips та AIS/LOF; параметри BERT (шаблон, тривалість, помилки, ESR/SESR); джерело синхронізації; налаштування VLAN/пріоритету для відео; підсумок «прийнято / доопрацювання» та підпис.

Друкована PDF-версія цього чек-листа містить ці поля з місцем для запису виміряних значень — зручно брати на об'єкт.