A jól ismert Network Time Protocolról (NTP) sok cikk született, néhányan megemlítik a Precision Time Protocolt, amely állítólag nanoszekundumos idejű szinkronizálási pontosságot tesz lehetővé (például és). Nézzük meg, mi ez a protokoll, és hogyan érhető el ez a pontosság. És lássuk az ezzel a protokollal végzett munkám eredményeit is.
Bevezetés
A "Precise Time Protocol"-t az IEEE 1588 szabvány írja le. A szabványnak 2 változata van. Az első verzió 2002-ben jelent meg, majd 2008-ban felülvizsgálták a szabványt, és megszületett a PTPv2 protokoll. A visszafelé kompatibilitás nem maradt meg.A protokoll második verziójával dolgozom, rengeteg fejlesztés van az elsőhöz képest (pontosság, stabilitás, ahogy a wiki is mondja). Nem fogok összehasonlítani az NTP-vel, a szinkronizálási pontosság puszta említése, és a PTP pontossága „vas” támogatással valóban eléri a több tíz nanoszekundumot, előnyről beszél az NTP-vel szemben.
Az „Iron” protokoll támogatása a különböző eszközökben eltérő módon valósítható meg. Valójában a PTP megvalósításához a minimálisan szükséges, hogy a hardver képes legyen lenyomni az üzenet porton való fogadásának pillanatában az időbélyeget. A beírt idő a hiba kiszámításához lesz felhasználva.
Miért van felforgatva az óra?
A hibák bárhonnan megjelenhetnek. Kezdjük azzal, hogy az eszközök frekvenciagenerátorai különbözőek, és nagyon valószínűtlen, hogy két különböző eszköz tökéletesen működik órajelről órajelre. A generált frekvenciát befolyásoló, folyamatosan változó környezeti feltételek is tulajdoníthatók.Mire törekszünk?
Tegyük fel, hogy van egy ideális körülmények között működő készülékünk, valami atomóránk, ami a világ végéig egyáltalán nem fog elkelni (persze az igazinak és nem a maja naptárnak szánta), és megkapjuk a az a feladat, hogy legalább megközelítőleg (10-9 mp-es pontossággal) ugyanazt az órát szerezzük meg. Szinkronizálnunk kell ezeket az órákat. Ehhez megvalósíthatja a PTP protokollt.A különbség a tisztán szoftveres megvalósítás és a "vas támogatással" rendelkező megvalósítás között
A tisztán szoftveres megvalósítás nem éri el a megígért pontosságot. Az üzenet beérkezésétől (pontosabban a készülékben az üzenet vételéhez érkezett jel) a megszakítási vagy visszahívási belépési pontra való átállásig eltelt idő nem határozható meg szigorúan. A PTP-támogatással rendelkező "okos hardver" ezeket az időbélyegeket önmagában is le tudja tenni (pl. Micrel chipek, csak a KSZ8463MLI-hez írok drivert).Az időbélyegek mellett a hardveres támogatás magában foglalja a kristályoszcillátor hangolásának lehetőségét (a frekvencia kiegyenlítése a masterrel), vagy az órajel beállítását (az órajel értékének növelése ciklusonként X ns-mal). Erről lentebb bővebben.
Térjünk át az IEEE 1588 szabványra
A szabvány leírása már 289 oldalon található. Vegye figyelembe a protokoll megvalósításához szükséges minimumot. A PTP egy kliens-szerver szinkronizációs protokoll, azaz. legalább 2 eszköz szükséges a protokoll megvalósításához. Tehát a Master eszköz egy atomóra, a Slave eszköz pedig egy óra, amelyet pontos működésre kell késztetni.Nyelvcsere
Üzenet bejelentése– közlemény üzenet, a master által az összes Slave eszközre küldött információkat tartalmaz. Az üzenetet használó slave eszköz kiválaszthatja a legjobb mestert (erre van egy BMC (Best Master Clock) algoritmus). A BMC nem olyan érdekes. Ez az algoritmus könnyen megtalálható a szabványban. A választás olyan üzenetmezőkön alapul, mint a pontosság, eltérés, osztály, prioritás stb. Térjünk át más bejegyzésekre.Sync/Follow Up, DelayResp, PDelayResp/PDelayFollowUp- a mester küldte, az alábbiakban részletesebben megvizsgáljuk őket.
DelayReq, PDelayReq– Slave eszközökre vonatkozó kérések.
Mint látható, a Slave eszköz nem bőbeszédű, a Master szinte minden információt maga szolgáltat. A küldés a szabványban szigorúan meghatározott multicast címeken történik (ha kívánja, használhatja az Unicast módot is). Mert PDelay az üzeneteknek külön címük van (01-80-C2-00-00-0E Ethernet és 224.0.0.107 UDP esetén). A fennmaradó üzeneteket a 01-1B-19-00-00-00 vagy a 224.0.1.129 számra küldjük. A csomagok mezőnként különböznek ClockIdentity(óraazonosító) és SequenceId(csomagazonosító).
Munkamenet
Tegyük fel, hogy a mestert a BMC algoritmussal választották ki, vagy a hálózat egyetlen mesterét. A képen a fő eszköz és a szinkronizált eszköz közötti kommunikáció folyamata látható.
- Minden azzal kezdődik, hogy a Mester üzenetet küld Szinkronizálés egyidejűleg rögzíti a t1 küldési időt. Létezik egy- és kétlépcsős működési mód. Nagyon könnyű megkülönböztetni őket: ha van üzenet nyomon követni- akkor kétlépcsős megvalósítással van dolgunk, a pontozott nyíl opcionális üzeneteket mutat
- nyomon követni után küldik el az üzenetet Szinkronizálés t1 időt tartalmaz. Ha az átvitel egy szakaszban történik, akkor Szinkronizál t1-et tartalmaz az üzenet törzsében. A t1-et mindenesetre a készülékünk fogja fogadni. Az üzenet átvételekor Szinkronizál t2 időbélyeg jön létre a slave-en. Így kapjuk t1, t2
- A Slave üzenetet generál DelayReq a t3 generálásával egyidejűleg
- A mester fogadja DelayReqüzenetet, ezzel egyidejűleg generál t4
- t4 elküldésre kerül a Salve készülékre a címen DelayRespüzenet
Online üzenetek
Egy ilyen cseremenettel, mint fentebb látható, csak akkor lehet sikeres, ha a kvarc ideális esetben ugyanazokat a frekvenciákat generálja a szinkronizált eszközök számára. Sőt kiderül, hogy az órajel frekvenciája más, pl. az egyik eszközön 1 másodperc alatt az óra értéke 1 másodperccel nő, a másikon pedig például 1,000001 másodperccel. Innen ered az óraeltolódás.
A szabvány leír egy példát a mesteren és a szolgán eltelt idő arányának kiszámítására egy bizonyos intervallumon belül. Ez az arány lesz a Slave eszköz frekvenciájának együtthatója. Ugyanakkor van arra utaló jel, hogy a kiigazítás többféleképpen is elvégezhető. Tekintsünk kettőt közülük:
- Módosítsa a Slave eszköz órafrekvenciáját (példa a szabványban)
- Ne változtassa meg az órajel frekvenciáját, de minden T időtartamú ciklusnál az órajel értéke nem T-vel, hanem T + ∆t-vel nő (az én megvalósításomban használom)
A második módszer ∆t kiszámítását igényli. ∆t az az érték, amely adott intervallumonként hozzáadódik az időértékhez. Az ábrán látható, hogy míg a masteren 22 - 15 = 7 másodperc, addig a slave-en 75 + (87-75) / 2 - (30 + (37-30) / 2) = 47,5 másodperc
Frekvencia - processzorfrekvencia, például 25MHz - processzorciklus 1/(25*10 6) = 40ns.
Az eszköz képességeitől függően a legmegfelelőbb módszer kerül kiválasztásra.
A következő szakaszra való továbblépéshez fejezzük ki az eltolást egy kicsit másképp:
PTP üzemmódok
A szabványt tekintve nem az egyetlen módja a szállítási idő kiszámításának. A PTPv2-nek 2 üzemmódja van. Ez E2E (végponttól végéig), fentebb figyelembe vettük, az üzemmód is le van írva P2P (Peer-to-Peer). Nézzük meg, hol melyik módszert kell alkalmazni, és mi a különbség.Elvileg tetszés szerint bármelyik módot használhatod, de nem kombinálhatók ugyanazon a hálózaton.
- módban E2E A kézbesítési idő a több eszközön érkezett üzenetekből kerül kiszámításra, amelyek mindegyike az üzenetjavító mezőbe kerül Szinkronizál vagy FollowUP(kétlépcsős átvitel esetén) az az idő, ameddig a csomag késett ezen az eszközön (ha az eszközök közvetlenül csatlakoznak, a korrekció nem kerül lerakásra, ezért ezeket nem vesszük figyelembe). Felhasznált üzenetek: Sync/FollowUp, DelayReq/DelayResp
- módban P2P a korrekciós mezőbe nem csak az az idő kerül beírásra, ameddig a csomag késett, (t2-t1) kerül rá (a szabványban olvasható). Üzenetek használatosak Sync/FollowUp, PDelayReq/PDelayResp/PDelayRespFollowUp
End-to-End mód
Peer-to-peer mód
Látjuk, hogy néhány piros nyíl megjelent P2P módban. Ezek a fennmaradó üzenetek, amelyeket nem vettünk figyelembe, nevezetesen PDelayReq, PDelayRespÉs PDelayFollowUp. Íme az üzenetek cseréje:
Szállítási idő hiba
A szabvány leírja a protokoll megvalósítását különféle típusú hálózatokban. Ethernet hálózatot használtam, és az ethernet rétegen kaptam üzeneteket. Az ilyen hálózatokban a csomagok kézbesítési ideje folyamatosan változik (különösen észrevehető, ha nanoszekundumos pontossággal dolgozunk). Különféle szűrőket alkalmaznak ezeknek az értékeknek a szűrésére.Amit szűrni kell:
- Szállítási idő
- Elfogultság
LP IIR (Infinite Impulse Response aluláteresztő) szűrő(Szűrő végtelen impulzusválaszsal) a következő képlettel írható le:
, Ahol s egy olyan együttható, amely lehetővé teszi a szűrő levágásának beállítását.
Kiigazítás számítás
Térjünk át a tuningra, arra a deltára, amit majd hozzá kell adni a másodperc értékéhez. A rendszeremben használt számítási séma:
A hálózati zaj miatti erős tuning jittert Kalman szűrővel szűrtem ki, nagyon tetszett. Általában bármilyen szűrőt használhat, ami tetszik, a lényeg a grafikon simítása. BAN BEN PTPd Például a szűrés egyszerűbb - az aktuális és az előző értékek átlaga kerül kiszámításra. A grafikonon láthatja a meghajtóm Kalman-szűrőjének eredményeit (hangolási hiba látható, szubnanoszekundumban kifejezve egy 25 MHz-es chipen):
Rátérünk a beállítás beállítására, a beállítás legyen állandó, PI szabályozót használunk. BAN BEN PTPd az óraeltolás be van állítva (eltolással megy a beállítás), de a trimm beállítására használom (a KSZ8463MLI jellemzője). Látjuk, hogy a vezérlő nincs tökéletesen beállítva, de esetemben ez a beállítás elegendő:
A munka eredménye
Az eredmény a grafikonon látható. Óraeltolás -50n és 50n között. Következésképpen elértem azt a pontosságot, amelyet számos cikk említ. Természetesen a megvalósítás sok apró vonása a színfalak mögött maradt, de a szükséges minimumot bebizonyították.
65 nanométer a 300-350 millió euróba kerülő Angstrem-T Zelenograd üzem következő célja. A vállalkozás már benyújtotta a Vnesheconombank (VEB) számára a termelési technológiák korszerűsítésére irányuló kedvezményes hitelre vonatkozó kérelmet – közölte a héten a Vedomoszty Leonyid Reimanra, az üzem igazgatótanácsának elnökére hivatkozva. Az Angstrem-T most egy 90 nm-es topológiájú chipek gyártására szolgáló sor elindítására készül. A korábbi VEB-hitel, amelyre azt vásárolták, kifizetése 2017 közepén kezdődik.
Peking összeomlott a Wall Streeten
A kulcsfontosságú amerikai indexek rekordeséssel jellemezték az újév első napjait, Soros György milliárdos már figyelmeztetett, hogy a világ a 2008-as válság megismétlődésére vár.
Tömeggyártásba kerül az első orosz fogyasztói processzor, a Baikal-T1 60 dolláros áron
A Baikal Electronics cég 2016 elején azt ígéri, hogy az orosz Baikal-T1 processzort mintegy 60 dollár értékű ipari termelésbe bocsátja. A készülékekre akkor lesz kereslet, ha ezt az igényt az állam megteremti – állítják a piaci szereplők.
Az MTS és az Ericsson közösen fejleszti és vezeti be az 5G-t Oroszországban
A PJSC "Mobile TeleSystems" és az Ericsson együttműködési megállapodást írt alá az 5G technológia fejlesztésében és bevezetésében Oroszországban. Kísérleti projektekben, így a 2018-as világbajnokságon is, az MTS a svéd gyártó fejlesztéseit kívánja tesztelni. A jövő év elején az üzemeltető párbeszédet kezd a Távközlési és Tömegkommunikációs Minisztériummal a mobilkommunikáció ötödik generációjának műszaki követelményeinek kialakításáról.
Sergey Chemezov: A Rostec már most is a világ tíz legnagyobb mérnöki vállalata közé tartozik
A Rostec vezetője, Szergej Csemezov az RBC-nek adott interjújában égető kérdésekre válaszolt: a Platon-rendszerről, az AVTOVAZ problémáiról és kilátásairól, az Állami Vállalat gyógyszeripari érdekeltségeiről, beszélt a szankciók nyomása alatti nemzetközi együttműködésről, az importról. helyettesítés, átszervezés, fejlesztési stratégiák és új lehetőségek a nehéz időkben.
A Rostec "védett" és a Samsung és a General Electric babérjaira hat
A Rostec Felügyelő Bizottsága elfogadta a „2025-ig tartó fejlesztési stratégiát”. A fő feladatok a high-tech civil termékek arányának növelése, valamint a General Electric és a Samsung felzárkóztatása a legfontosabb pénzügyi mutatókban.
2012.07.09., hétfő, 10:07, Msk
A következő generációs közlekedési hálózatok fő problémája az, hogy az Ethernet technológiát eredetileg helyi hálózatokhoz tervezték, és soha nem szinkronizációs jelek továbbítására tervezték. Az áramkörkapcsolt hálózatokban az elmúlt évtizedekben a szinkron digitális hierarchia (SDH) technológiája dominál, mint átviteli közeg, ez a szinkron jelek továbbítására épül. De még ez a robusztus és jól bevált technológia sem felel meg a mai alkalmazások követelményeinek.
oldalak: előző | | 2
Sync Ethernet használata
Kezdetben az Ethernet technológiát kizárólag helyi hálózatokban való használatra fejlesztették ki. Az információ fizikai szintű lineáris kódolásának módszereit az órajel továbbításával nem járó feladatoknak megfelelően választottuk. Az SDH hálózatok eredetileg NRZ vonalkódokat használtak, amelyek a kommunikációs csatorna fizikai rétegében történő szinkronizálás továbbítására alkalmasak. A Sync Ethernet technológia létrehozásakor a fizikai réteget és a kódolási módszereket az SDH technológiából kölcsönöztük, a második (csatorna) réteget gyakorlatilag nem érintette. A keretstruktúra változatlan marad, kivéve a szinkronizálási állapot SSM bájtját. Jelentését is az SDH technológiából kölcsönözték.
A szinkronizálás elve a Sync Ethernet protokollon keresztül
A Sync Ethernet technológia előnyei közé tartozik a fizikai réteg SDH-struktúrájának használata, és egyben - hatalmas és felbecsülhetetlen értékű tapasztalat a hálózati óraszinkronizációs hálózatok tervezésében és építésében. A módszerek azonossága megtartotta a régi G.803, G.804, G.811, G.812 és G.813 ajánlásokat az új technológiában. A drága eszközök - elsődleges referenciaoszcillátorok (PEG), másodlagos mesteroszcillátorok (SGM) - is használhatók a Sync Ethernet szabványra épülő új szállítási hálózatban.
Tipikus szinkronizálási séma a Sync Ethernet technológiával
A hátrányok közé tartozik, hogy a teljes átviteli hálózatban minden eszköznek támogatnia kell az új szabványt, és ha olyan eszköz marad a vonalon, amely nem támogatja a Sync Ethernet-et, akkor a csomópont mögötti összes eszköz nem tud szinkron üzemmódban működni. Ebből következően a teljes hálózat korszerűsítése jelentős anyagköltségeket igényel. A hátrányok közé tartozik továbbá, hogy ez a módszer csak a frekvencia szinkronizálás átvitelét támogatja.
A PTP protokoll használata (IEEE1588v2)
A szinkronizálás átvitelének utolsó módja pedig, amely az utóbbi időben egyre népszerűbb, a Precise Time Protocol (PTP). Ezt az IEEE 1588 ajánlás írja le. 2008-ban jelent meg ennek a dokumentumnak a második változata, amely leírja a protokoll használatát a távközlési hálózatokban. A Precise Time Protocol meglehetősen fiatal, de magát az időátviteli technológiát a Network Time Portocol (NTP) protokollból kölcsönözték. Az NTP protokoll legújabb verziójában nem biztosítja a mai alkalmazásokhoz szükséges pontosságot, így továbbra is jó eszköz maradt az időszinkronizáláshoz, amelyet széles körben alkalmaznak szerverek, elosztott adatbázisok stb. szinkronizálásában. De a hálózati óra hálózati szinkronizálása során az NTP protokoll logikai folytatása alkalmas - ez a PTP protokoll. A PTP kommunikációban részt vevő hálózati elemek a következő eszközök: PTP Grand Master és PTP Slave. Általában a Grand Master veszi a szinkronizálást a GNSS vevőtől, és ezen információk felhasználásával csomagokat cserél a Slave eszközzel, és folyamatosan korrigálja a Grand Master és a Slave eszközök közötti időbeli eltéréseket. Minél aktívabb ez a csere, annál pontosabb lesz a beállítás. Az ilyen aktív adatcsere hátránya a PTP protokoll számára lefoglalt sávszélesség növekedése. Az időintervallumok közötti eltérés kiszámításánál a legfontosabb probléma az, hogy a "klasszikus" 3. rétegű routerek a Grand Master és a Slave eszközök közé állhatnak. A "klasszikus" kifejezés ebben az esetben annak hangsúlyozására szolgál, hogy ezek az eszközök semmit sem értenek a PTP 5. réteg protokollból.
Az ilyen útválasztók puffereinek késleltetését nehéz kezelni, és természetüknél fogva véletlenszerűek. Ezen véletlenszerű hibák ellenőrzése, valamint a Grand Master és a Slave közötti időkülönbség kiszámításának pontosítása érdekében a PTP protokollban egy speciális paramétert vezettek be - az Időbélyegzőt. Ez a címke azt az időt jelzi, ami alatt a csomag áthaladt az útválasztón. Ha az útválasztók a Grand Mastertől a Slave-ig PTP-funkcióval rendelkeznek, és időbélyeget állítanak be, akkor a PTP-csomagok IP-hálózaton való áthaladásával kapcsolatos véletlenszerű hiba minimalizálható.
Példa egy szinkronizációs hálózat felépítésére a PTP protokollon
Szinkronizációs átviteli módszerek összehasonlítása új generációs csomaghálózatokban
Az útválasztókon a PTP funkció nem kötelező, de kifejezetten ajánlott a PTP protokoll használatakor. Meg kell jegyezni, hogy a legtöbb útválasztó gyártó ezt a funkciót beépíti eszközébe. Az alábbi ábrán látható egy példa a mobilszolgáltatók szinkronizálási sémájának felépítésére. A PTP előnye, hogy a protokoll mindhárom szinkronizálási típus átvitelére irányul: frekvencia, fázis és idő. A protokoll fő hátránya a terhelésfüggőség. A nehezen kezelhető IP-hálózatok torlódásai miatt nagyon nehéz garantálni a hálózaton keresztüli szinkronizálási átviteli normák szigorú betartását.
| Technológia | Előnyök | Hibák |
| GNSS | Frekvencia-, fázis- és időszinkronizálás biztosítása. Nem függ a hálózat terhelésétől. |
Antenna beszerelése kötelező. Beltérben nem használható. Lehetséges interferencia más rádiókészülékekből. A redundanciát csak egy második GNSS vevő felszerelése biztosítja |
| Ethernet szinkronizálása | Nem függ a hálózat terhelésétől. Hasonlóság az SDH hálózathoz | Csak frekvencia szinkronizálást biztosít. Az összes hálózati elem által megkövetelt szinkronizálási Ethernet támogatás |
| PTP | Frekvencia-, fázis- és időszinkronizálás biztosítása. | A hálózat terhelésétől függ. |
Mindegyik módszernek megvannak a maga előnyei és hátrányai, amelyeket a táblázatban mutatunk be. A helyes megközelítés meghatározásához ajánlatos számos olyan kritériumot figyelembe venni, amelyek a különböző hálózatokra jellemzőek.
Mihail Vekselman
oldalak: előző | | 2
2005-ben megkezdődött az IEEE1588-2002 szabvány megváltoztatása annak érdekében, hogy kiterjessze annak lehetséges alkalmazási területeit (telekommunikáció, vezeték nélküli kommunikáció stb.). A munka eredménye az IEEE1588-2008 új kiadása, amely 2008 márciusától érhető el a következő új funkciókkal:
- Továbbfejlesztett algoritmusok, amelyek biztosítják a hibákat a nanoszekundumos tartományban.
- Az időszinkronizálás jobb teljesítménye (a szinkronizálási üzenetek gyakoribb továbbítása lehetséges).
- Új üzenettípusok támogatása.
- Az egymódusú működési elv bevezetése (a FollowUp típusú üzenetek továbbítása nem szükséges).
- Funkció támogatásának megadása az ún. átlátszó óra, amely megakadályozza a mérési hibák felhalmozódását kapcsolók kaszkádcsatlakozása esetén.
- Adja meg az új alkalmazások beállításait meghatározó profilokat.
- Hozzárendelhető olyan átviteli mechanizmusokhoz, mint a DeviceNet, PROFInet és IEEE802.3/Ethernet (közvetlen hozzárendelés).
- A TLV struktúra (típus, hossz, érték) bevezetése a szabvány lehetséges hatókörének bővítése és a jövőbeni igények kielégítése érdekében.
- A szabvány további opcionális kiterjesztésének bevezetése.
A PTP protokollon alapuló rendszerek működési elve
A PTP protokollt használó rendszerekben kétféle óra van: a mester óra és a szolga óra. A mester órát ideális esetben rádiós óra vagy GPS-vevő vezérli, és szinkronizálja a szolga órákat. A végberendezés órája, akár mester, akár szolga, normál órának számít; a hálózati eszközök órái, amelyek adatátviteli és -útválasztási funkciót látnak el (például Ethernet switchekben), határóráknak tekintendők.
Rizs. 1. A PTP protokoll szerint az eszközök időszinkronizálása a "mester - slave" séma alapján történik.
A PTP protokoll szerinti szinkronizálási eljárás két szakaszra oszlik. Az első szakaszban a mester és a szolga óra közötti időleolvasások különbségét korrigálják - azaz végrehajtják az úgynevezett időeltolás korrekciót. Ehhez a mester eszköz időszinkronizálási célból üzenetet küld Szinkronizálás a szolga eszközzel (Sync típusú üzenet). Az üzenet tartalmazza a mesteróra aktuális idejét, és meghatározott időközönként kerül továbbításra.
Mivel azonban a mesteróra leolvasása, az adatok feldolgozása és az Ethernet-vezérlőn keresztül történő továbbítás némi időt vesz igénybe, a továbbított üzenetben lévő információ a fogadás időpontjában elavult. Ugyanakkor a lehető legpontosabban rögzítik azt az időpontot, amikor a szinkronizálási üzenet elhagyja a feladót, amely magában foglalja a fő órát (TM1). A mestereszköz ezután elküldi a szinkronizálási üzenet átvitelének rögzített idejét a slave eszközöknek (FollowUp üzenet). Ezenkívül a lehető legpontosabban mérik az első üzenet vételi idejét (TS1), és kiszámítják, hogy mennyivel szükséges korrigálni a saját és a master közötti időbeli leolvasások különbségét (O) (lásd 1. és 1. ábra). 2). Ezután a slave eszközökben az órajeleket közvetlenül korrigálják az eltolási érték. Ha nem volt késedelem az üzenetek hálózaton keresztüli továbbításában, akkor vitatható, hogy az eszközök időben szinkronizálva vannak.
Rizs. 3. Üzenetkésleltetési idő számítása kapcsolókban.
Az üzenetátvitel késleltetése mindkét irányban azonos lesz, ha az eszközök csak egy kommunikációs vonalon csatlakoznak egymáshoz. Ha vannak switchek vagy routerek a hálózatban az eszközök között, akkor nem lesz szimmetrikus késleltetés az üzenet továbbításában az eszközök között, mivel a hálózatban lévő switchek tárolják azokat az adatcsomagokat, amelyek áthaladnak rajtuk, és azok átvitelének meghatározott sorrendjét. valósul meg. Ez a funkció bizonyos esetekben jelentősen befolyásolhatja az üzenetek továbbításának késleltetését (az adatátviteli időkben jelentős eltérések lehetségesek). Alacsony hálózati információterhelés mellett ennek a hatásnak csekély hatása van, ugyanakkor nagy információterhelés esetén ez a hatás jelentősen befolyásolhatja az időszinkronizálás pontosságát. A nagy hibák kiküszöbölésére egy speciális módszert javasoltak és bevezették a határórák koncepcióját, amelyek a hálózati kapcsolók részeként valósulnak meg. Ez a határóra szinkronizálva van a mester eszköz órájával. Továbbá az egyes portokhoz tartozó kapcsoló a mester eszköz a portjaihoz csatlakoztatott összes slave eszköz számára, amelyben a megfelelő óraszinkronizálás történik. Így a szinkronizálás mindig pont-pont séma szerint történik, és az üzenet továbbításának közel azonos késleltetése az előre és hátra irányban, valamint ennek a késleltetésnek a gyakorlati változatlansága nagyságrendileg üzenet továbbítása másiknak.
A határóra használatára épülő elv ugyan megmutatta gyakorlati hatékonyságát, de a PTPv2 protokoll második változatában egy másik mechanizmust határoztak meg - az ún. átlátszó óra. Ez a mechanizmus megakadályozza a hiba felhalmozódását a szinkronizációs üzenetek kapcsolók általi továbbításában bekövetkezett késések mértékének változása miatt, és megakadályozza a szinkronizálási pontosság csökkenését nagyszámú lépcsőzetes kapcsolóval rendelkező hálózat esetén. Ezzel a mechanizmussal a szinkronizálási üzenetek elküldésre kerülnek a mestertől a slave felé, akárcsak bármely más üzenet a hálózaton. Amikor azonban a szinkronizálási üzenet áthalad a kapcsolón, a kapcsoló általi átvitelének késleltetése rögzített. A késleltetés egy speciális korrekciós mezőben van rögzítve az első szinkronizálási üzenet részeként vagy a következő FollowUp üzenet részeként (lásd 2. ábra). A Delay Request és Delay Response üzenetek továbbításakor ezek késleltetési ideje is rögzített a kapcsolóban. Így a támogatás megvalósítása az ún. Az átlátszó órák a kapcsolók részeként lehetővé teszik a közvetlenül bennük előforduló késések kompenzálását.
A PTP protokoll megvalósítása
Ha szükséges a PTP protokoll használata a rendszerben, akkor a PTP protokoll veremét kell megvalósítani. Ez az eszköz processzorának teljesítményére és a hálózati sávszélességre vonatkozó minimális követelmények mellett megtehető. Ez nagyon fontos a protokollverem egyszerű és olcsó eszközökben történő megvalósításához. A PTP protokoll könnyen megvalósítható még olcsó vezérlőkre (32 bites) épített rendszerekben is.
Az egyetlen követelmény, amelyet teljesíteni kell a nagy szinkronizálási pontosság biztosításához, az az üzenet továbbításának és az üzenet fogadásának időpontjának legpontosabb mérése az eszközök által. A mérést a hardverhez a lehető legközelebb (például közvetlenül a meghajtóban) és a lehető legnagyobb pontossággal kell elvégezni. A tisztán szoftveres megvalósításokban a rendszer architektúrája és teljesítménye közvetlenül korlátozza a megengedett maximális pontosságot.
Az időbélyegzés további hardveres támogatásával a pontosság jelentősen javítható, és gyakorlatilag független a szoftvertől. Ez további logikát igényel, amely programozható logikai integrált áramkörben, vagy egy konkrét feladat megoldására specializálódott integrált áramkörben valósítható meg a hálózati bemeneten.
következtetéseket
A PTP protokoll már számos területen bizonyította hatékonyságát. Biztos lehet benne, hogy a következő években egyre elterjedtebb lesz, és számos megoldást alkalmazva egyszerűbben és hatékonyabban lehet megvalósítani, mint más technológiák alkalmazásával.
IEEE 1588v2-t támogató KYLAND berendezések
technológiákat
S.Telegin
PTP protokoll NGN hálózatok szinkronizálásához
pályázati problémák
BAN BEN A cikk a következő generációs adathálózatok (NGN) szinkronizálásának problémájával foglalkozik. BAN BEN
A szerző a PTP protokoll használatát javasolja a szinkronizálás alternatív módszereként. A PTP protokollon (IEEE 1588) alapuló szinkronizációs rendszerek jellemzőit összehasonlítjuk a PXI buszt, valamint az NTP protokollt használó rendszerekkel.
Szinkronizálási probléma NGN hálózatokban
A távközlési technológiák és adatátviteli hálózatok fejlődése fokozatosan a következő generációs konvergens hálózatok (NGN – Next Generation Networks) kiépítéséhez vezet a távközlési szolgáltatók által. A fő különbség az ilyen hálózatok és a hagyományos szinkron digitális hierarchiával (SDH) rendelkező hálózatok között az, hogy aszinkron technológiákat, például Ethernetet (Gigabit Ethernet, 10 Gigabit Ethernet) használnak a gerinchálózati adatátvitelhez a hagyományos szinkron csatornákkal együtt. A távközlési szolgáltatók fő követelménye a következő generációs hálózatokkal szemben a hang, a kép és az adatok egyidejű átvitele egyetlen hálózaton keresztül.
A hagyományos, időmultiplexelésen alapuló adatátviteli hálózatokról az NGN hálózatokra való átállás során kiemelt figyelmet fordítanak a szinkronjelek továbbítására. A berendezések szinkronizálása elsősorban a valós idejű adatok - hang- és videóképek - hibamentes átviteléhez szükséges. Mivel az Ethernet hálózatok csomagkapcsolást alkalmaznak, ami az adatcsomagok aszinkron átviteli csatornákon való terjedésének statisztikai tulajdonságai miatt tönkreteszi a kezdetben szinkronizált adatfolyamot, az NGN hálózatokban a szinkronizálás külön feladat. A szinkron adatok csomagkapcsolt hálózatokon történő továbbításához általában csatornaemulációt alkalmaznak időmultiplexeléssel, amely abból áll, hogy a szinkron adatokat UDP-datagramokba foglalják, majd visszaállítják a célcsomóponton.
ELSŐ MIL 5–6/2009 |
|
Az aszinkron és szinkron csatorna találkozásánál a továbbított adatok hibamentes helyreállításához a berendezésnek órajelet is kell kapnia. Az órajel stabilitására vonatkozó követelmények az adathálózat konkrét céljától függően változnak. Tehát a telefonszolgáltatások és az internet-hozzáférés biztosítására szolgáló szolgáltatói hálózatokban a szinkronizálási követelmények meglehetősen enyhék - 50 ppm (egység per millió), a mobilhálózatokban pedig a mobil előfizetők zökkenőmentes átmenetéhez az egyik bázisállomásról a másikra a 50 ppb (egység/millió) szükséges. milliárd).
Az NGN hálózatok szinkronizálásának módjai
Az ITU-T G.8261 ajánlás három fő módszert tárgyal a csomagkapcsolt átviteli közeg szélein történő újraszinkronizálásra, amikor az időmultiplexelt alapsávi jelet áramkör-emulációs szolgáltatásként szállítják. Ehhez a végállomási berendezést el kell látni az internetezés funkcióival. A csomagkapcsolt átviteli közeg minden előfizetője a szokásos központi elosztáson keresztül kaphat órafrekvenciát a szinkronizációs hálózattól (1. ábra). Ha a felhasználói berendezés saját órajel-frekvenciáján működik (2. ábra), akkor a csomagkapcsolt hálózat peremén különböző relatív módokon, például az SRTS sebességillesztési algoritmus segítségével helyreáll. Az átjárócsomópontnak mindkét esetben hozzá kell férnie az elsődleges szinkronizációs generátor interfészéhez.
technológiákat
záció (KNK). Ehhez az NGN hálózat üzemeltetőjének vagy külön szinkronizációs hálózatot kell kiépítenie, vagy azt bérelnie kell a meglévő SDH szállítási hálózat üzemeltetőktől.
Számos példa van a helyi hardveres szinkronizálásra. Így például egy olcsó GPS-alapú elsődleges szinkronizációs forrást (PRS) helyeznek el az állomáshelyiségben, és vezeték nélküli technológiával vagy hagyományos dedikált kábeleken keresztül, Ethernet fizikai környezetben, valamint egyéb eszközök segítségével osztják el belőle az órafrekvenciát. eredeti sémák. Ha a szinkronizációs hálózat kiépítése (vagy szinkronizációs csatlakozások alkalmazása) lehetetlen vagy nem kívánatos, akkor a legegyszerűbb, de stabilitási okokból problémás, adaptív módszert alkalmazzuk a vételi és átviteli sebességek összehangolására (3. ábra).
A vizsgálatok eredményei azt mutatják, hogy az adaptív módszer akkor alkalmazható, ha az előfizető nem támaszt szigorú követelményeket az órajel frekvenciájának stabilitásával szemben, ellenkező esetben a visszanyert órajel további hardveres simítására van szükség. Az adaptív módszer alternatívája az RTP protokoll használata, amikor az időmultiplexelt adatokat aszinkron adatcsomagokba foglalják (4. ábra). Amint a kísérletek kimutatták, ebben az esetben a visszaállított órajel nagy stabilitása mellett a berendezés gyengén érzékeny az órajelforrás frekvenciaváltozásaira, ami szükséges például a mobilhálózatokban, amikor biztonsági mentésre vált. órajel.
PTP protokoll
A fejlesztés következő szakasza a jelek szerint a hálózati szinkronizációs jelek külön továbbítása lesz csomagkapcsolással.
speciálisan kialakított protokollok segítségével (5. ábra). Jelenleg ezek az NTP és a PTP protokollok. Ezeket a protokollokat eredetileg a különböző hálózati eszközök időszinkronizálására hozták létre, de az óra sikeres szinkronizálása esetén lehetővé válik az óraszinkronizálási algoritmusok megvalósítása a valós idejű adatok visszaállítására. Az NTP (Network Time Protocol) protokollt széles körben használják az aktuális idő alkalmazásszintű szinkronizálására. Ezzel szemben a Precision Time Protocol (PTP) az Open Systems Interconnection (OSI) modell második rétegében működik. A PTP protokollt az IEEE 1588 szabvány írja le, és várhatóan a jövőben a PTP-t mind a nagy pontosságú aktuális időszinkronizálásra, mind a berendezések órajeleinek szinkronizálására lehet majd használni. Tekintsük ezt a protokollt részletesebben.
Az IEEE 1588 szabvány azt sugallja, hogy a PTP protokoll szabványos módszert biztosít a hálózaton lévő eszközök szinkronizálására 1 µs-nál (legfeljebb 10 ns-ig) nagyobb pontossággal. Ez a protokoll szinkronban tartja a szolga eszközöket a mesterrel, biztosítva, hogy az események és az időbélyegek minden eszközön ugyanazt az időalapot használják. A protokoll két lépést biztosít az eszköz szinkronizálásához:
Rizs. 3 Adaptív szinkron
4. ábra |
Szinkronizálás átvitele RTP használatával |
5. ábra |
Szinkronizálás átvitele PTP használatával |
ELSŐ MIL 5–6/2009 |
|
Rizs. 6 PTP műveleti algoritmus
mestereszköz (1) és az egyes eszközökben az óraeltolás okozta időeltolódás és a hálózaton keresztüli adatátvitel késései által okozott időeltolódás korrekciója (2). A rendszer inicializálása során a PTP a "legjobb fő órajel" algoritmust használja a hálózat legpontosabb időzítési forrásának meghatározására. Egy ilyen eszköz lesz a mester, és a hálózat összes többi eszköze szolga lesz, és az óráját a master szerint állítja be.
A master és a slave közötti időkülönbség az óraeltolás és a szinkronizálási üzenet átviteli késleltetésének kombinációja. Ezért az időeltolás korrekcióját két lépésben kell elvégezni: az átviteli késleltetések és az eltolás kiszámítását, majd ezek korrekcióját. Tekintsük két eszköz óraszinkronizálási sorrendjét (6. ábra).
A master elindítja az óraeltolás korrekcióját a szinkronizálás és a nyomon követés üzenetekkel. A nyomon követési üzenet jelzi a szinkronizálási üzenet (TM1) idejét az átviteli közeghez legközelebb mérve, hogy minimalizálja a referenciaforrás időhibáját. Miután a slave eszköz megkapta az első szinkronizálási és nyomon követési üzeneteket, az óráját használja a szinkronizálási üzenet (TS1 ) érkezési idejének időbélyegzésére, és összehasonlítja ezt az időbélyeget a mestertől kapott időbélyeggel a nyomon követési üzenetben. A két jel közötti különbség tükrözi a T0 órajel-eltolást, valamint az üzenet átviteli késleltetését a mastertől a slave-ig ∆TMS: TS1 – TM1 = T0 + ∆TMS .
Az üzenetátviteli késleltetési idő és az óraeltolás kiszámításához a slave egy Delay_request üzenetet küld a TS2 idejével. A mester észreveszi ennek az üzenetnek az érkezését, és egy TM2 feliratú Delay_response üzenettel válaszol. A két jel közötti különbség a szolga-master átviteli késleltetés ∆TSM mínusz az eltolás a szolga mintában: TM2 – TS2 =∆TSM – T0 .
Az üzenetátviteli késleltetés kiszámításakor feltételezzük, hogy az átlagos adatátviteli késleltetés a csatornában
a terjedési késések számtani átlagáról a csatorna különböző irányaiban:
TMS + TSM |
|||
A TS1 , TM1 , TM2 és TS2 idők ismeretében a slave kiszámítja az átlagos terjedési késleltetést az adatkapcsolatban:
T = (TS1 − TM1 ) + (TM2 − TS2 ) . 2
A végső óraszinkronizálás azután történik meg, hogy a mester elküldte a második szinkronizálási (TS3) és nyomon követési (TM3) üzeneteket. A slave eszköz a T0 = TS3 – TM3 – ∆T képlet alapján számítja ki az óraeltolást.
A slave készülék ezután beállítja az óráját a számított értékeknek megfelelően. Mivel az órareferenciák az egyes eszközökben instabilok, és a csatornakésések idővel változhatnak, időnként újra be kell állítani a slave órát.
A PTP protokoll megvalósításának jellemzői
A legtöbb PTP-megvalósítás eltérése 1 µs-nál kisebb, azonban a tényleges pontosság az alkalmazástól függ. A PTP protokoll az eszközökben háromféleképpen valósul meg: szoftver, firmware és hardver. Az RTP szoftveres megvalósításai lehetővé teszik a szinkronizációs jelek körülbelül 100 μs pontosságú átvitelét. A nagyobb pontosság eléréséhez hardvert kell használni. Minden egyes komponens, amely feldolgozza a PTP-csomagot, miután megkapta azt a fizikai adathordozóról, növeli a szinkronizálási hibát. A szoftver rész okozza a legnagyobb hibát, mivel a processzor terhelése és a megszakítási feldolgozás késleltetése befolyásolja a szinkronizálási kérés feldolgozásának sebességét.
Hardverben és szoftverben megvalósítva a legérzékenyebb protokollfunkciók, mint például a PTP-csomag időbélyegének írása, az Ethernet fizikai rétegében valósulnak meg, például egy külön programozható logikai chipben. Az ilyen módszerek ma a legoptimálisabbak, mivel nem igényelnek túl sok erőforrást és időt az eszköz fejlesztéséhez, így körülbelül 20 ns-os pontosság érhető el. A PTP protokoll teljes hardveres megvalósítása esetén körülbelül 10 ns pontosság érhető el.
A megvalósítási mód mellett számos egyéb tényező is befolyásolja a PTP protokoll pontosságát. Például az IEEE 1588 szabvány nem határozza meg a master és slave órajel frekvenciáját. Ennek eredményeként az alacsonyabb frekvenciájú órák kevésbé pontos időfelbontással rendelkeznek, ami kevésbé pontos időbélyegeket eredményez az óraüzenetekben. A referenciaoszcillátorok frekvenciastabilitása szintén befolyásolja a protokoll megvalósításának minőségét. A hőmérséklet-szabályozott és hőmérséklet-kompenzált kvarcoszcillátorokkal kapott szinkronjelek stabilabbak lesznek (-tól
ELSŐ MIL 5–6/2009 |
|
technológiákat |
||||||
rész/milliárdban kifejezett eltérés), nem pedig kristályoszcillátorok |
alternatíva az elosztott rendszerek szinkronizálására |
|||||
termikus stabilizálás nélkül (eltérés ppm-ben). |
témák szubmikroszekundumos pontossággal. |
|||||
Topo- |
Tehát a PTP protokoll egy alternatíva |
|||||
hálózati logika és forgalom egységessége. Egy nagy számmal rendelkező hálózatban |
hálózatok szinkronizálásának módszere, amely kaphat |
|||||
selejtes eszközök és az adatcsatornák nagy terhelése |
elosztása NGN hálózatokban. A használtakhoz képest |
|||||
az időzítés fordítási pontossága rosszabb lesz. Ezért a |
jelenleg szinkronizálással, ez a módszer |
|||||
előnyösen szinkronizáló jelek átvitelét alkalmazzuk |
számos előnnyel rendelkezik: |
|||||
külön adathálózatot hozzon létre. |
Nincs szükség közvetlenül a szinkronizálási interfészhez való hozzáférésre. |
|||||
csökkenti a KNK-t, ami lehetővé teszi az üzemeltetők számára, hogy optimalizálják a |
||||||
Összehasonlító jellemzők |
hálózatépítési költségek. Ugyanakkor a PTP protokoll képes biztosítani |
|||||
szinkronizációs rendszerek |
sütő átvitel szinkronizálása szubmikroszekundumos pontossággal |
|||||
Vegye figyelembe a szinkronizációs rendszerek jellemzőit |
tew, ami azt jelenti, hogy 1 ppm-nél jobb stabilitás érhető el; |
|||||
a PTP protokollt használva, összehasonlítva a szinkronizált rendszerekkel |
Az adaptív módszerrel ellentétben a szinkronizálás visszaállítása |
|||||
a PXI buszon (fizikai szinkronizációs vonalon) és a protokollon keresztül |
A ronizáláshoz rendkívül stabil referenciaoszcillátorra van szükség |
|||||
lu NTP (lásd a táblázatot). Ellentétben a fizikai vonallal rendelkező rendszerekkel |
csak a fő eszközben; |
|||||
szinkronizálás, ahol az események pontosságát a pontosság határozza meg |
Szinkronizálási feladatokhoz használhat aszinkront |
|||||
órajel, a PTP protokollban a meghatározó tényezők |
viszonylag kis sávszélességű csatorna |
|||||
véletlenszerű változáshoz fázis-jitter (jitter) társul |
teljesítmény, ami jelentősen csökkenti a megvalósítás költségeit. |
|||||
csomagközi intervallumok nélkül. A legtöbb proto-megvalósítás |
Lehetőleg ezt a csatornát dedikáltnak kell lennie. |
|||||
A Cola PTP 1 μs-nál kisebb pontosságot biztosít. |
Figyelembe véve a hálózatok egyszerű telepítését |
|||||
Egy másik fontos érték, amely megkülönbözteti a különböző módszereket |
Ethernet, szubmikroszekundumos pontosság és teljesítmény |
|||||
szinkronizálás, a várakozási idő egy szinkronizáló eseményre |
minimális üzenetfeldolgozási költségekkel, proto- |
|||||
tiya. Ez az esemény mesternek való elküldése közötti idő |
count A PTP-t egyre gyakrabban használják számos iparágban, különösen |
|||||
a tiéd, és vezesse őt. Mivel a PTP protokollok és |
ipari automatizálásban, metrológiában stb. Várható- |
|||||
NTP a szinkronizálási üzenetek küldéséhez |
Xia, hogy a jövőben a PTP-protokoll képességei bővülni fognak |
|||||
ut adatcsomagok esetén az eseményre való várakozást az idő határozza meg |
Alkalmazás a távközlésben eszközök szinkronizálására |
|||||
csomag késleltetés, valamint fejléc átviteli és feldolgozási idő |
roystvo csomagkapcsolt hálózatokon keresztül. |
|||||
csomag, és általában néhány milliszekundum. BAN BEN |
||||||
különbözik tőlük a fizikai szinkronizációs vonallal rendelkező rendszerek |
Irodalom |
|||||
több szinkronizálási eseményre vár |
1. Stein Y., Schwartz E. Circuit Extension over IP: The |
|||||
nanoszekundum. Szinkronizálási esemény várakozási ideje |
A hang és az örökség átvitelének evolúciós megközelítése |
|||||
egy ilyen jellemzőt a lehető legnagyobbnak határoz meg |
Adatok IP hálózaton keresztül. – RAD Data Communications, 2002. |
|||||
az órajel frekvenciájának beállítása. |
2. ITU-T G.8261/Y.1361 Időzítés és szinkronizálás |
|||||
Szinkronizáló rendszerek egyetlen szinkronizáló busszal, |
szempontok a csomaghálózatokban. – ITU_T, 2008. április. |
|||||
mint például a PXI ideálisak a nagy pontossághoz és gyorshoz |
3. Rodrigues S. Technológiai lehetőségek a szinkronizáláshoz |
|||||
stnogo helyreállítása szinkronizálás és meghosszabbítható |
Következő generációs hálózatok. – 3. Nemzetközi Telecom |
|||||
wren akár több száz méteres távolságban speciális segítségével |
||||||
kazettákba helyezett szinkronizáló modulok. Alapértelmezett- |
4. Telegin S.A. TDMoIP multiplexelés alkalmazása |
|||||
Szoros szinkronizálás Etherneten keresztül NTP használatával |
adatátvitelhez a közlekedési hálózatokban |
|||||
beállítja a megfelelő ezredmásodperces időzítést |
GSM. – Nemlineáris világ, 2007, v.5, no.5, p. 270–271. |
|||||
alacsony sebességű alkalmazások, amelyek nem túl kritikusak a minőség szempontjából |
5. IEEE szabvány 1588–2008 IEEE szabvány a pontosságért |
|||||
szinkronizálás. A PTP protokoll jó |
Óraszinkronizációs protokoll a hálózathoz |
|||||
Szinkronizációs rendszerek összehasonlító jellemzői |
Mérési és vezérlőrendszerek. – IEEE, 2008. július. |
|||||
6. IETF RFC1305 Network Time Protocol (3. verzió). |
||||||
Szinkronizálás |
Jegyzőkönyv |
Jegyzőkönyv |
||||
Specifikáció, megvalósítás és elemzés. - IETF, |
||||||
modulok PXI buszokon |
||||||
Ideiglenes |
||||||
<1·107 |
7. Tan E. IEEE 1588 Precision Time Protocol Time |
|||||
engedély |
||||||
események, ns |
Szinkronizálási teljesítmény. Pályázati jegyzet 1728.– |
|||||
National Semiconductor, 2007. október. |
||||||
elvárások |
||||||
8. Hamdi M. Neagoe T. A Hardver IEEE-1588 |
||||||
Megvalósítás processzorfrekvencia-szabályozással. - |
||||||
kiigazításokat |
Arrow Electronics, 2006. augusztus. |
|||||
ELSŐ MIL 5–6/2009 |
|
