Synchronizace frekvence - na zbytkovém fázovém posuvu nezáleží
Cílem tohoto textu je shrnout několik témat, která navzájem souvisí poměrně volně, ale u firmy Meinberg jsou v tuto chvíli aktuální (prosinec 2015), přestože se obecně nejedná o žhavé novinky. Jedná se tedy o dobovou aktualitku, předem odsouzenou k rychlému zastarání.
V úvodní teoretické části uvedeme na pravou míru několik buzzwordů.
Následně se ve druhé části podíváme na vybrané aplikační oblasti,
ve kterých se firma Meinberg snaží poslední dobou prosadit.
V souvislosti se synchronizací v telekomunikacích je často zmiňována synchronizace frekvence. Frekvence a tečka - žádný další požadavek. Rozumí se, že různá zařízení v komunikační síti potřebují běžet "přesně stejně rychle", aby si navzájem dokázala předávat isochronní proud dat s minimálním až nulovým bufferingem, tzn. se zanedbatelnou a konstantní latencí. V tradičních telekomunikacích závisí na minimální a konstantní latenci spousta věcí: srozumitelnost hovoru (ve smyslu přímého zkreslení i odečítání echa), zamezení "skákání si do řeči" (lidští účastníci nesmí zaznamenat přenosové zpoždění), u pronajatých digitálních okruhů chybovost přenosu dat a "rychlost" některých síťových aplikací, které závisí na obrátce transakcí dotaz/odpověď. Konstantní latence a bezeztrátový isochronní tok dat jsou například také podmínkou správného fungování asynchronních JTS modemů a faxů (protokol V.34 a příbuzné) - a přesně toto je např. důvod, proč se modem nebo fax málokdy protlačí skrz VoIP, přestože je použit "bezeztrátový" kodek G.711. (Přesný důvod: není dodržena bitwise bezeztrátovost hovorového kanálu, konstantní latence a vzorkovací frekvence.)
|
Synchronizace frekvence - na zbytkovém fázovém posuvu nezáleží |
Přesnost frekvence lze vyjádřit různými způsoby, třeba jako povolenou odchylku v jistém časovém horizontu, nebo jako spektrální čistotu.
Člověk by selským rozumem řekl, že pokud je synchronizován "lidský"
přesný čas, vyplyne z toho i přesná frekvence nějakého základního taktu
zařízení, případně i naopak, z přesné frekvence lze odvozovat přesný čas
(po jistém počátečním nastavení) - ale jsou v tom jisté praktické nuance,
ke kterým se dále v textu dostaneme. Obecně v teoretické rovině to jistě
platí, ale jakmile začnete uvažovat o konkrétních "strojních" způsobech
synchronizace, zjistíte, že různé formáty a rozhraní určené pro
synchronizaci "lidského" denního času vykazují různou reálnou míru
(ne)přesnosti, a naopak vysoce přesné zdroje dobře definovaných hran
(nebo právě frekvence) nenesou úplnou informaci o "lidském" datu a čase,
která třeba není ani bezezbytku algoritmicky odvoditelná z nějaké
počáteční hodnoty a přírůstků (konkrétně přestupné sekundy).
Pokud se pokusíte vyrobit přesnou frekvenci fázovým závěsem,
kde jako referenci použijete relativně nepřesný zdroj hran nebo
tak něčeho, dopadnete jak? (žáku Nyquiste?) No ale nechme planého řečnění,
žerty a konvergenci regulačních smyček stranou... Naznačili jsme si,
že ďábel se skrývá v detailech a pokročme dále.
Jako "druhý nejjednodušší" styl synchronizace bývá uváděna synchronizace fáze. Slovo "fáze" má v různých kontextech mírně různý význam: jinak mu rozumí elektrikář na nízkém napětí, jinak projektant přenosové soustavy VVN, jinak návrhář anténní a VF techniky, jinak specialista na zpětnovazební regulaci...
V našem kontextu synchronizace času v telekomunikacích můžeme začít jednoduchým pohledem na nějaký základní takt/hodiny = od synchronizace frekvence: synchronizovat fázi může znamenat, snažit se o nulový fázový rozdíl základního hodinového signálu mezi body A a B:
 Synchronizace fáze - základní představa (synchronní frekvence i fáze) |
Bližší realitě je ale patrně jiné vysvětlení: "fáze" znamená přesný soulad
nějakých pravidelných událostí, které mohou a nemusí odpovídat sekundám
reálného času, a v dané aplikaci nám na těchto událostech záleží "ještě
nad rámec" základního hodinového kmitočtu, případně nám o základní hodiny
nemusí jít vůbec. Pro jednoduchost uveďme jako příklad sekundový pulz.
To je hrana s pravidelným výskytem na hranici celé sekundy,
jejíž požadovaná přesnost záleží na aplikaci. Používá se například
jako rozhraní mezi rádiovým přijímačem časových značek a NTP serverem
(software běžící na PC nebo jiném počítači). Pravda je, že protokol NTP
slouží primárně k distribuci "lidského" reálného času (včetně přestupných
sekund), PPS slouží k přesnému "usazení" vlastní časové základny
NTP serveru, která běží v softwaru - dosažitelná přesnost NTP je běžně
ve stovkách až desítkách mikrosekund (PPS o tři řády níž).
Zrovna u NTP naopak naprosto nezáleží na konkrétní základní hodinové
frekvenci použitých čítačů/časovačů v PC HW, která se nakalibruje podle
použitého hardwaru a průběžně "dokalibrovává" podle externí sekundové
reference (PPS nebo NTP). Údaj o zlomku sekundy (mezi hranami PPS)
v časových značkách vracených NTP serverem se běžně interpoluje podle
TSC čítače, který tiká podle frekvence jádra procesoru - tato je
na každém počítači jiná, má nějakou jmenovitou hodnotu, ale nebývá
příliš přesná ani stabilní (proto se průběžně hlídá, a zjištěné
vandrování lokálního krystalu/syntezátoru se softwarově zohledňuje).
Jinak řečeno, u NTP se snažíme o pokud možno přesné globální "fázové"
sladění PPS, přitom si neklademe žádné zvláštní nároky na konkrétní
frekvenci, detailní fázi a dokonce ani přesnost a stabilitu lokálního
krystalu. Výrobci PC motherboardů totiž přesnost hlavního krystalu
v centrálním hodinovém syntezátoru nijak moc neřeší.
(Ano, je možné tento krystal svépomocně vyměnit za "něco přesnějšího".
Otázkou je, zda to má smysl - záleží na podrobnostech aplikace.)
Vedle samotného PPS věnujme odstavec ještě kombinaci sekundového
pulzu (PPS) a základního taktu daného krystalem - v kontextu synchronizace
fáze. Některé aplikace vyžadují kombinaci základní krystalové
frekvence a z ní odvozeného PPS, navíc s podmínkou tzv. "fázové synchronnosti"
obou signálů. Klasickým příkladem je synchronizace vysílacího řetězce
DVB/DAB. Vysílací řetězec přenáší poměrně složitý multiplex datových
streamů, které jsou na některých úrovních isochronní - zejména fyzická
rozhraní běží v pevném taktu "synchronním" stylem. Požadavek na
"fázově synchronní" PPS vůči základním hodinám 10 MHz zde znamená,
že hrana PPS přijde vždy přesně jednou za 10 000 000 tiků základní
frekvence. Zároveň je pochopitelně vyžadována vysoká stabilita
základního 10MHz taktu. Častým zdrojem signálu je GPS přijímač
s lokálním oscilátorem tikajícím přímo na 10 MHz, který je servosmyčkou
jemně dolaďován na maximální možnou shodu s globálním časem (UTC).
Požadavek na takto definovanou "fázovou synchronnost" se může zdát
nadbytečný, samozřejmě splněný - ale jako obvykle se čertovo kopýtko
skrývá v detailech. Pro správnou funkci servosmyčky je prakticky
potřeba teplotně stabilizovaný = vyhřívaný krystalový oscilátor,
což je součástka relativně už trochu drahá a taky maličko žravá.
Pro běžnou funkci časoměrného přijímače GPS, a taky třeba pro
řízení NTP serveru, postačují i méně přesné krystalové oscilátory,
které nelze servosmyčkou plně doladit - proto základní modely
časoměrných přijímačů GPS kompenzují vandrování krystalu
skokově, vkládáním či vynecháváním tiků (nebo zlomků tiku)
základního kmitočtu generovaného "nedostatečně krotkým" krystalem.
Na osciloskopu to vypadá, jako že se PPS jednou za pár (desítek)
sekund skokově "posune" o část periody základního signálu.
 Synchronizace fáze - základní takt a k němu fázově synchronní PPS |
Synchronizace fáze ale může znamenat něco ještě trochu jiného.
Například pokud je třeba sfázovat více vysílačů v DVB-T SFN,
jde o to, aby vysílaly ve shodném okamžiku (s definovanou přesností)
tentýž signál. To znamená, aby stream variabilních datových rámců
či modulačních sekvencí, distribuovaný na vysílače, vycházel z vysílačů
v přesném časovém souladu/zákrytu. Nejedná se o pevný takt ani
periodu událostí, jedná se vlastně o řetězec událostí s proměnlivým
rozestupem, který potřebujeme přesně zrcadlit a časově sladit
ve více zařízeních. Technicky se k tomu samozřejmě použije
přesně sladěná časová základna, synchronní na všech vysílačích,
na kterou se distribuční stream odkazuje. Jednotná "fáze" bude
na úrovni lokálních časových základen patrně představována sekundovým
tikáním (PPS).
 Synchronizace fáze - soufázová komunikace datovými rámci |
V souvislosti se synchronizací fáze si lze představit ještě složitější
scénáře: například můžeme chtít, aby se některý vysílač v rámci
SFN naschvál trochu předcházel - s ohledem na optimální vykrytí
určitého cílového území s dodržením ochranného intervalu.
Nebo se můžeme snažit o beamforming či MIMO napříč několika vysílači.
Tyto techniky využívají záměrný přesný posuv modulovaných rámců
mezi vysílači - a vzájemný fázový posuv mezi vysílači se může lišit
pro různé "příjemce" vysílaných dat. Vlastně se jedná o jednoduchý
případ "antény se syntetickou aperturou".
V těchto složitých scénářích budou opět základem fázově synchronní
lokální hodiny na všech vysílačích, a potřebné fázové posuvy
se budou do datového streamu či do modulace zavádět "ve vyšších
vrstvách" zpracování signálu. Základní systémová časová základna
tiká na všech uzlech jednotně.
Vedle frekvence a fáze se používá ještě třetí úroveň synchronizace: lidmi užívaný letopočet, datum a čas.
 Synchronizace času - obecná představa |
Základní frekvence+PPS, ale často ani další průmyslové synchronizační "datové formáty" tuto informaci nepřenášejí a není z nich bezezbytku odvoditelná. Jedná se vlastně o specifický druh nebo nadstavbu "fázové" synchronizace, s konkrétní sadou atributů a některými svéráznými elementy chování: s přestupnými dny a sekundami. A zatímco přestupné dny se vyskytují pravidelně (1 den za 4 roky), přestupné sekundy nelze odvodit algoritmem, kompenzují jakési částečně chaotické geofyzikální děje a o vložení přestupné sekundy ve finále rozhoduje shromáždění expertů. Informaci o přestupných sekundách je proto třeba šířit nějakými komunikačními kanály.
Konkrétně starší varianty průmyslového formátu IRIG přenášejí datum a čas, ale nikoli letopočet.
Relativně moderní synchronizační protokol zvaný IEEE1588 = PTP běží interně v časové doméně zvané TAI (mezinárodní atomový čas), která nezohledňuje přestupné sekundy - a proto za ní doména UTC zaostává o celočíselný počet sekund, který v průběhu let postupně narůstá. Jedná se o projev hlavního účelu, pro který byl protokol PTP vytvořen - tím je průmyslová synchronizace elektronických a strojních zařízení. Těm jde primárně o pravidelný chod časové základny (vlastně o přesnou fázi, vymezenou podle potřeb aplikace) a přestupné sekundy představují nepravidelnost, která není algoritmizovatelná, musí se nějak dálkově komunikovat, a proto je vhodné, aby se rutinní provoz systému obešel bez ní. PTP grandmaster jako doplňkovou informaci udává i ofset UTC/TAI, takže si PTP slavové mohou UTC čas dopočítat, pokud o něj stojí. (Pikantní jsou situace, kdy by o UTC čas velmi stála obsluha nebo systémový integrátor = dodavatel řešení, ale konkrétní model průmyslového hardwaru s UTC neumí pracovat.) PTP grandmastery Meinberg umí pracovat i v časové doméně UTC, je to konfigurovatelná vlastnost - a také prohřešek proti standardu IEEE1588.
Informaci o přestupných sekundách přenáší například tyto
protokoly/rozhraní/signály: GPS, DCF77, NTP a mnohé sériové
řetězce (např. Meinberg Standard Time String). NTP server zavěšený
na GPS nebo DCF77 tedy řeší přestupné sekundy zcela automaticky.
Pokud je třeba provozovat např. NTP server zcela autonomně,
podle přesné lokální PPS reference, existuje možnost aktualizovat
seznam přestupných sekund nakopírováním souboru.
Prakticky nejvíc problémů s přestupnými sekundami mívají v průmyslovém
řízení a regulaci koncová zařízení (klienti/slavové). Ve chvíli,
kdy se na hodinách objeví sekunda=60, ještě relativně zdvořilou
reakcí je "chyba času - ale jede se dál". Přesně to je důvod,
proč PTP jede nativně v doméně TAI.
Pro některá použití nám informace o datu a čase stačí sama o sobě, tzn. "zhruba na vteřinu přesně". Jindy tuto informaci potřebujeme jako doplněk/nadstavbu jemnější synchronizace - v praxi ji tedy zejm. v průmyslové synchronizaci kombinujeme s přesnou frekvencí a PPS:
 Synchronizace času - úplná: základní takt, soufázové PPS a denní čas |
Prakticky je pro přenos této kompletní informace obvykle zapotřebí použít několik souběžných rozhraní: klasicky 10 MHz, PPS a třeba NTP (nebo nějaký textový řetězec na sériovém rozhraní).
Konkrétní množina dostupných/použitelných vstupních a výstupních rozhraní pro synchronizaci, a stejně tak možnost jejich vzájemné kombinace, závisí na konkrétní průmyslové aplikaci a modelu hardwaru.
Horní dvě patra synchronizace pokrývá protokol PTP (IEEE 1588).
A přestože nedosahuje chirurgické přesnosti, kterou vykazuje
klasická synchronizace frekvence v jednotkách MHz, pro mnohé
aplikace jeho přesnost dostačuje. Vedle charakteru aplikace
záleží také na použitém síťovém hardwaru, nakolik je protokolu
PTP nakloněn. Dokonce existuje "ITU-T G.8265.1 Telecom Profile
for Frequency", což naznačuje, že pomocí PTP lze synchronizovat
i frekvenci (ačkoli to na první pohled nezní zrovna samozřejmě).
Přesnost "fáze" poskytované PTP je na poměry paketových sítí
velmi dobrá, pro mnohá použití dostatečná. Ve srovnání s NTP
dává PTP jednak o několik řádů lepší přesnost (díky podpoře
v hardwaru), jednak má od přírody mnohem rychlejší konvergenci
(ustálení) časové základny na cílovém zařízení (což plyne
z návrhu, byl to jeden z cílů).
Kam až je možné vyladit PTP v ethernetové síti,
ukazuje otevřený/akademický projekt White Rabbit,
vyvíjený skupinou subjektů, z nichž nejznámější je patrně CERN.
Projekt používá otevřený software a hardware,
konkrétně má vedle grandmasteru a slavů (a dalšího ne-časovacího
hardwaru, jako jsou rychlé I/O karty) také svůj vlastní switch.
Právě absence vhodných switchů je obecným problémem PTP snad
ve všech oblastech potenciálního nasazení.
Využitím Sync-E a dalších technik z kategorie fázového závěsu,
v kombinaci s PTP, se údajně v rámci tohoto projektu daří
dosahovat přesnosti synchronizace napříč sítí pod 1 ns.
Popravdě aktuální PTP grandmaster od Meinbergů by toto
patrně dokázal taky - specialitou projektu White Rabbit je to,
že dokonalé fungování PTP řeší napříč celou sítí, tj. od A do Z.
Patrně to plyne z motivace a potřeb hlavních účastníků projektu,
kteří staví a provozují velké částicové urychlovače.
Zbytek tohoto textu se bude věnovat několika konkrétním aplikačním oblastem, které mají specifické požadavky na synchronizaci času. A také konkrétním produktům, které pro tyto oblasti nabízí firma Meinberg.
Mezi tradiční cílové trhy firmy Meinberg patří všeobecně synchronizace
nad TCP/IP protokolem NTP, fázově-synchronní kombinace 10 MHz + PPS
pro DVB/DAB, a obecně synchronizace průmyslových zařízení protokolem
IRIG, binárními signály (pulzy) a dalšími způsoby.
Kromě uvedených tradičních segmentů trhu se firma Meinberg nově snaží
prosadit i v synchronizaci telekomunikačních sítí (pevných a mobilních)
a profesionálního audia.
Zdá se, že expanzi do těchto oblastí umožnila nová generace časových ústředen firmy Meinberg: rodina IMS šasi LanTime M3000, M1000 a dalších.
 Zadní = konektorové čelo šasi LanTime M3000 s velkým počtem modulů |
Firma Meinberg touto modulární platformou vychází vstříc zákazníkům, kteří potřebují redundantní napájení, větší počet výstupů v zakázkových kombinacích, možnost servisu výměnou jednotlivých modulů přímo "v poli" (tzn. v místě instalace). IMS šasi je téměř pasivní "vana", která obsahuje pouze backplane a displej. Všechny ostatní díly mají podobu zásuvných karet: napájecí zdroje, CPU karta (management+NTP), rádiové přijímače a moduly výstupních rozhraní. Jedním takovým modulem (konfigurovatelným jako výstup nebo vstup) je aktuální PTP grandmaster firmy Meinberg, který podporuje snad úplně všechny vlastnosti a "profily", které si lze přát, při poměrně vysokém transakčním výkonu. Některá IMS rozhraní (typicky výstupy PPS a frekvence) lze opatřit redundantním přepínáním mezi dvěma moduly časové základny (typicky dva moduly GPS přijímače, každý se svým lokálním oscilátorem).
Firma Meinberg patří tradičně mezi hlavní sponzory konferencí ISPCS (součástí je PTP plugfest) a účastní se např. také setkání International Telecom Sync Forum jehož ročník 2016 proběhne na podzim v Praze.
 IMS-LIU = karta výstupů pro telekomunikace |
Sítě PDH a SDH si předávají hodiny kaskádně v hierarchii. Jedná se o klasický příklad "synchronizace frekvence". V síti menšího operátora stačí jediná časová ústředna o normou určené jakosti, která dává takt nějakému centrálnímu multiplexeru. Ostatní (podřízené popř. sousední) multiplexery v hierarchii jsou nakonfigurovány tak, aby přebíraly (fázovým závěsem) hodiny od synchronizačního masteru - kaskádním způsobem. Jako rozhraní nesoucí hodinovou informaci se dá použít buď vstup určený výhradně pro externí hodiny, nebo některý synchronní port nesoucí payload - prostě se na něm nastaví, že nemá hodiny dávat, ale přebírat.
Zda nasadit pro konkrétní síť jednu či více časových ústředen, to je téma na delší debatu. Z technických kritérií bude hrát svou roli jednak hloubka kaskády, ve smyslu kaskádního řazení smyček fázových závěsů (sčítá se regulační zisk i "časová konstanta reakce"), druhak aspekt provozní spolehlivosti - časová ústředna a vlastně i vyšší multiplexery v kaskádě představují potenciální "single point of failure". Určitě je vhodné vzít v potaz i geografickou strukturu sítě, dopad případného výpadku dálkové konektivity mezi regionálními uzly (na interní synchronizaci "odříznuté oblasti") apod.
Do nové rodiny Meinberg IMS šasi patří také nová karta výstupního rozhraní pro synchronizaci PDH/SDH sítí: zatímco starší generace uměly pouze holé hodiny 2048 kHz (obdélník), nový výstupní modul umí kromě toho také framing E1/T1 (HDB3/B8ZS), a to na obou fyzických rozhraních obvyklých pro G.703 (symetrický pár i BNC koax).
V situaci, kdy klasické SDH/PDH/ISDN/JTS sítě stagnují a napohled "vycházejí z módy", firma Meinberg nabízí své zdroje času jako cenově příjemnější alternativu k synchronizačním produktům konkurenčních výrobců, kteří jsou v telco odvětví dobře zavedení. Pokud je třeba udržet SDH/PDH hierarchii ještě nějakou dobu v provozu, a stará synchronizační ústředna přesluhuje, možná právě firma Meinberg nabízí řešení.
Oblast synchronizace SDH/PDH sítí se tradičně vyznačuje vysokými nároky na přesnost hodin = na jakost oscilátorů. Firma Meinberg má na svém webu přehlednou tabulku, kde jsou objednatelné oscilátory seřazeny podle kvality (a zároveň podle ceny). Pro nasazení v SDH/PDH se tradičně používá Césium nebo Rubidium, ale pokud srovnáte parametry Rubidia s Meinbergovic OCXO-HQ a DHQ, možná zjistíte, že v některých ohledech na tom Rubidium už není o tolik líp. Pravda je, že Rubidium je lepší v udržení přesnosti frekvence (a času) po delší době volnoběhu, což je v této aplikaci zřejmě klíčový parametr. Špičkové varianty vyhřívaných krystalových oscilátorů mají naopak lepší některé "krátkodobé" parametry (přesnost frekvence, fázový šum).
LTE je zatím poslední generací mobilní datové sítě, kterou nasadili a dále rozvíjejí i naši tři původní "GSM" operátoři. Přesněji řečeno, jak už akronym LTE napovídá, jedná se vlastně o několik generací pod společným označením, nebo o jakýsi základ, který je postupně rozvíjen a vylepšován podle postupných pokroků technologie polovodičů a firmwaru.
Páteřní pevná síť LTE technologie je založena (nejenom) na Ethernetu a TCP/IP. Nijak ovšem nepřekvapí, že vysílací infrastruktura rádiového segmentu potřebuje synchronizaci na několika vrstvách. Jako první se zjevně řešila synchronizace frekvence - teprve v souvislosti s vývojově novějšími variantami LTE-TDD a LTE-Advanced se mluví také o potřebě synchronizovat fázi.
RAN v rámci LTE-TDD pracuje v časovém duplexu a v tomto režimu je vhodné koordinovat cyklus TDD mezi sousedními buňkami.
V rámci LTE-Advanced jsou již k dispozici také vysílací schémata
jako multi-cell MIMO a beam forming, která pracují se skládáním
signálů z více vysílačů "na míru" pro jednotlivé účastníky...
Také zde vyvstává silná analogie s DVB-T SFN: sousední buňky
na shodné frekvenci, OFDM, ochranný interval...
Zde je pochopitelně synchronizace fáze časové základny
jednotlivých BTS klíčová pro správnou funkci těchto
"mezibuněčně koordinovaných vlnových efektů".
Konkrétní požadavky různých variant a scénářů LTE na přesnost synchronizace (čísla v nízkých jednotkách mikrosekund) lze snadno dohledat v mnoha white-paperech, kterými tapetuje web konkurenční Symmetricom (Microsemi) - viz klíčová slova pro Google na posledním řádku v odkazech.
Velice užitečným nástrojem synchronizace je zde PTP. Implementace PTP v BTSkách a nejlépe taky ve switchích po cestě je levnější a praktičtější alternativou ke scénáři "GPS přijímač na každé BTSce" (ne všechny BTS mají výhled na oblohu, zejm. interiérové dokrývače mají smůlu), a zároveň přesnější alternativou k jiným metodám synchronizace času a fáze přes paketovou síť.
 IMS TSU-GBe = karta PTP výstupu (nebo vstupu) |
Frekvenci lze v LTE zjevně synchronizovat i přes PTP, jak naznačuje "ITU-T G.8265.1 Telecom Frequency Profile" - přesto se v souvislosti s LTE stále častěji mluví také o SyncE (synchronním Ethernetu). Viz např. prezentace v odkazech na konci. Meinbergovic rozhraní IMS TSU-GBe umí oboje :-) stejně tak jako špičkové konkurenční produkty.
Existují další dva "telekomské" ITU profily PTP pro synchronizaci času a fáze: ITU G.8275.1, který předpokládá "full on-path support", a ITU G.8275.2, který předpokládá "partial on-path support".
Ejhle další buzzword! Copak je vlastně ten "on-path support"? Inu je to
jenom zkratka pro dávnou/učebnicovou PTP moudrost, že "pokud má PTP
vykazovat jmenovitou přesnost, musí všechny switche po cestě PTP
hardwarově podporovat". Této situaci odpovídá "full on-path support".
Potíž je, že taková situace se v reálném nasazení moc nevyskytuje.
Ze switchů po cestě mají podporu PTP pouze některé (a to je ještě
dobrá varianta). Tomu se říká "partial on-path support".
Ve stávajících sítích je velmi dobře možné, že PTP nepodporuje
žádný switch po cestě - což je kupodivu základní premisa
profilu "ITU-T G.8265.1 Telecom Frequency Profile".
Profil G.8265.1 vtěluje postřeh, že transportní zpoždění mezi koncovými uzly na zatížené síti má tvar velmi sešikmeného statistického rozdělení, a že v situaci bez hardwarové podpory PTP v aktivních prvcích sítě je vhodné, posílat pokud možno vysokou frekvenci PTP dotazů (chudák grandmaster), vybírat si jenom transakce s nejkratším průchozím zpožděním a pouze ty považovat za směrodatné pro časovací funkce = určitě nepočítat průměr ze všech transakcí. Existuje praktické pozorování, že pro dosažení požadované přesnosti cca 1 us stačí, pokud délka cesty v ethernetové síti bez podpory PTP nepřesáhne cca 5 hopů.
Další zajímavá věc je, že "telekomské" profily, včetně G.8275.1
(full on-path support) nepočítají s nasazením Transparent Clocks,
ale vyžadují, aby všechny switche po cestě, které podporují PTP,
fungovaly v režimu Boundary Clock.
To je ovšem velice zajímavý názorový vývoj. V době kdy PTPv2
(IEEE1588-2008) platilo za novinku, zdálo se, že Transparent Clocks
(nová vlastnost PTPv2) v režimu "end to end" jsou cestou kupředu,
protože v kaskádě switchů vykazují TC (ve srovnání s BC) menší sklon
k nestabilitě na vzdáleném konci, vzdálený konec méně "vandruje",
výsledkem je vyšší přesnost. Byl na to takový grafík.
Kde se tu berou zpátky BC, typické pro zastaralé PTPv1 ?
Tuto záhadu mi objasnil Heiko Gerstung, mladší obchodní šéf firmy
Meinberg Funkuhren. Ona ta učebnicová poučka je už pár let stará,
a založená na jedné sadě testů na konkrétním hardwaru, nebo snad
na nějakém statistickém modelu. Mezitím se ukazuje, že kvalitní
implementace BC dává srovnatelně dobré výsledky, jako kvalitní
implementace TC - což bylo nově otestováno na kaskádě až 16 switchů
(tohle v reálné síti nejspíš nepotkáte) a chovalo se to dobře,
časové základny "byly prostě stabilní". Kromě toho BC vlastně
představuje ve srovnání s TC více "distribuovaný" model:
každý switch fungující jako BC obsahuje přesný lokální
oscilátor, vybavený filtrem servosmyčky, ve kterém lze
lstivou statistikou omezit vliv chyb (jitteru) vznikajícího
při přenosu času paketovou sítí. Lokální oscilátor BC také
poskytuje časově omezené vykrytí výpadku konektivity
na grandmaster (nebo upstream BC) = poskytuje tzv. "holdover"
svým slavům a podřízeným BC. TC sám o sobě neodpovídá na
PTP dotazy a tedy ani nenabízí holdover. V modelu s BC se
klienti tážou svého upstream BC, což řádově snižuje transakční
zatěž grandmasteru (= ani při rychlejší periodicitě dotazů
od jednotlivých slavů není grandmaster úplný chudák).
Použití BC s kvalitním oscilátorem blízko koncovým slavům
(BTS různé "velikosti") také umožňuje použít jednodušší
a levnější implementaci PTP v koncových slavech
(přesnost podrží první nebo blízký upstream BC, kde je větší "finanční
prostor" pro kvalitní oscilátor a kvalitně implementovanou
servosmyčku).
No a nakonec: jak říká Douglas Arnold (spolupředseda pracovní
skupiny IEEE pro 1588 a technický ředitel J-Time / Meinberg USA),
model s BC více připomíná tradiční "telecomské"
schéma distribuce přesné frekvence v sítích PDH/SDH.
TC jakožto "feed-forward" varianta může být bližší některým
oblastem průmyslového měření a regulace apod.
Původně jednoznačný učebnicový požadavek, aby při použití PTP všechny
switche v síti měly hardwarovou podporu PTP, je zjevně dodnes oním
"slonem v místnosti", o kterém dříve nikdo nechtěl moc mluvit - až to
ITU vzalo do vlastních rukou a snaží se o realistický přístup
k reálně tristní situaci, co se podpory PTP v hardwaru dostupných
a používaných switchů týče.
Hardwarová podpora PTP v ethernetových switchích je totiž problém.
Má ji několik výrobců switchů kancelářských i průmyslových, ale i v průmyslu
má každý výrobce tak jednu modelovou řadu koncentrovaných switchů
do 19" racku a tím to končí. V periferních DIN-rail switchích
pro "satelitní" pozice se PTP v zásadě nevyskytuje (výjimkou je
PLCčkoidní modulární Hirschmann MICE MS20, který nemusí pro
konkrétní použití vyhovovat v jiných ohledech). V kancelářských
switchích se PTP vyskytuje tak v "midrange enterprise" a některých
carrier-grade modelech - menší periferní switche opět podporu
postrádají.
Má-li přijít podpora do širokého spektra malých a specializovaných
ethernetových switchů, musí tato podpora vzejít od výrobců křemíku
pro tyto switche (switchovací matice, vícenásobné PHY transceivery)
= od značek jako IC+, Realtek, Marvell, Vitesse... což bude zřejmě
ještě nějakou dobu trvat, přestože Heiko Gerstung tvrdí, že mnozí
tito výrobci už podporu PTP v některých "industrial" variantách
svých čipsetů mají/testují. Dokud jedinou cestou, jak zařídit podporu
PTP, bude programování FPGA a mangling MII komunikace,
nestane se PTP běžnou výbavou "dostupných" malých switchů.
Zatím např. v energetice (IEC61850 a konkrétně GOOSE) je
PTP a "on-path support" stále oním slonem v místnosti, o kterém
se nesmí mluvit, nebo v lepším případě se měří/hodnotí přesnost
fungování PTP skrz "nepodporující" switche apod.
Pokud se týče podpory PTP v telekomunikačních páteřních sítích,
není možná úplně správné se domnívat, že běží striktně na Ethernetu.
Patrně bude třeba provozovat PTP synchronizaci taky nad SDH/PDH
(enkapsulace POS, HDLC apod.) - rozumí se PTP na třetí vrstvě (UDP/IP).
A třeba POS nebo HDLC rozhraní těžko budou mít hardwarovou podporu...
takže jsme zpátky u "on-path support".
Heiko Gerstung k tomu říká, že firma Mienberg už PTP v L3 režimu nad
synchronními spoji u některých zákazníků řešila, dokonce mají
vyřešenu autodetekci přepnutí SDH kruhu na zálohu - prostě když
PTP servosmyčka zjistí skokové trvalé zvýšení "statisticky nejkratšího"
zpoždění, nezohlední tento skok do časové základny, ale pracuje
s ním nadále jako se "systematickým/stabilním chybovým vlivem" (bias).
A že tato schopnost firmwaru Meinberg se následně velice hodí,
"když se teď začínáme bavit o APTS" (Assisted Partial Timing Support).
 IMS VSG = karta výstupů pro video studia |
V nahrávacích a střihových studiích umožňuje synchronizace hodin pokud možno bezeztrátový přenos audio dat a např. synchronní přepínání obrazu z jednoho zdroje na druhý (bez chvilkového rozpadu obrazu).
Pro synchronizaci digitálního audio řetězce se tradičně používá
distribuce vzorkovacího taktu (word clock) - často na úrovni TTL
koaxiálním kabelem. Kromě tohoto prostého formátu v základním pásmu
existuje také možnost přenášet referenční takt nad spojem AES3.
Firma Meinberg pro generování vzorkovacích hodin nabízí kartu
IMS-SCG
(Studio Clock Generator). Má 4 BNC výstupy (TTL do 50 Ohmů)
s konfigurovatelnými výstupními frekvencemi v rozsahu 24 Hz
až 24,576 MHz. Jedná se o prostý obdélníkový výstup (nikoli AES3).
V synchronizaci videa se uplatní několik signálů: z dob analogových
a SD je velice rozšířený synchronizační formát zvaný "dvoustavová
synchronizace", známá též jako "black burst" (nebo black and burst).
V modernější době HD rozlišení ji nahradila "třístavová synchronizace".
Svoje využití naleznou také prosté signály řádkové a snímkové synchronizace
(HSYNC a VSYNC).
Firma Meinberg pro synchronizaci videa nabízí kartu
IMS-VSG
(Video Sync Generator) která na svých čtyřech výstupech umí nabídnout
současně třístavovou (HD) a dvoustavovou (SD) synchronizaci + další dva
TTL signály (např. HSYNC a VSYNC).
Zdá se, že vývoj komunikací ve studiových technologiích poslední dobou směřuje k Ethernetu - a jistě není překvapivé, že pro synchronizaci je i v tomto oboru logickou volbou PTP. Opět se tedy uplatní karta rozhraní IMS TSU-GBe od firmy Meinberg (PTP grandmaster, konfigurovatelná též jako slave).
Meinberg IMS šasi dokáže nabídnout všechna tato výstupní rozhraní pohromadě v jedné zakázkové sestavě. Všechny výstupy pak běží podle společné lokální časové základny.
Meinberg white paper: Time Synchronization in Telecom Networks
Meinberg Tutorial: Telecom Profile with Full On-Path Support
Meinberg Tutorial: The PTP Telecom Profile for Frequency Synchronization
The Wikipedia entry on IEEE1588 = PTP
Suggested Google queries: "LTE Time Sync", "LTE multi-cell", "LTE inter-cell"
Timing is everything - důkladná vysvětlivka k bi-level a tri-level sync
Helmut Imlau (Deutsche Telekom) on SyncE
Helmut Imlau (Deutsche Telekom) : plán migrace synchronizační sítě
International Telecom Sync Forum - pravidelná každoroční konference, ročník 2016 proběhne na podzim v Praze
ISPCS - pravidelná každoroční konference o PTP spojená s plugfestem
Seznam veřejných přednášek ISPCS 2015 obsahuje
několik ukrytých skvostů: třeba povídání o cyklickém vysílání kritických přenosů ve vyhrazeném
časovém intervalu (hybrid Ethernetu s prvky TDM - používá např. Profinet) v přednášce od člověka
z Broadcomu, nebo povídání o nasazení PTP v čínské národní infrastruktuře LTE...
White Rabbit project: Heslo na wikipedii, Oficiální homepage, Podrobnější přehled hardwarových produktů, Technické podrobnosti o synchronizaci, Tutorial (slideshow)