Hyrje
Koncepcia e ndërtimit të "Nënstacioneve Digitale" në energjinë elektrike kërkon sinkronizim me saktësi prej 1 ”s. Për kryerjen e transaksioneve financiare gjithashtu kërkohet saktësi në ”s. Në këto aplikacione, saktësia e kohës NTP tashmë nuk është e mjaftueshme.
Protokolli i sinkronizimit PTPv2, i përshkruar nga standardi IEEE 1588v2, lejon arritjen e saktësisë së sinkronizimit në disa dhjetëra nanosekonda. PTPv2 lejon dërgimin e pakove të sinkronizimit përmes rrjeteve L2 dhe L3.
Fushat kryesore ku përdoret PTPv2 janë:
- energjia;
- pajisjet e kontrollit dhe matjes;
- kompleksi industrial-ushtarak;
- telekomunikacioni;
- sektori financiar.
Në këtë postim do të shqyrtojmë se si funksionon protokolli i sinkronizimit PTPv2.
Ne kemi më shumë përvojë në industri dhe shpesh përballemi me këtë protokoll në aplikacionet energjetike. Prandaj, do ta bëjmë edhe përmbledhjen me një vështrim .
Pse është e nevojshme?
Tani për tani, në STO 34.01-21-004-2019 të PAO "Rosseti" dhe në STO 56947007-29.240.10.302-2020 të PAO "FSK EES" përmbahen kërkesat për organizimin e autobusit të procesit me sigurinë e sinkronizimit të kohës sipas PTPv2.
Kjo lidhet me faktin se autobusit të procesit i lidhen terminalet e mbrojtjes relle dhe pajisje matëse, të cilat përmes autobusit të procesit, duke përdorur të ashtuquajturat rrjedha SV (rrjedha multicast), transmetojnë vlera instantanesh të rrymës dhe tensionit.
Terminalet e mbrojtjes relle përdorin këto vlera për të realizuar mbrojtje të lidhjeve. Nëse saktësia e matjeve në kohë do të ishte e ulët, disa mbrojtje mund të veprojnë gabim.
Për shembull, një viktimë e "sinkronizimit të dobët" të kohës mund të jetë mbrojtja e selektivitetit absolut. Shpesh logjika e këtyre mbrojtjeve ndërtohet mbi krahasimin e dy vlerave. Nëse vlerat ndryshojnë në një sasi të mjaftueshme, atëherë mbrojtja aktivizohet. Nëse këto vlera matën me saktësi kohe 1 ms, atëherë mund të merret një ndryshim i madh aty ku vlerat në të vërtetë janë brenda normës, nëse matën me saktësi 1 ”s.
Versionet e PTP
Protokolli PTP u përshkrua fillimisht në vitin 2002 në standardin IEEE 1588-2002 me emrin "Standard për një Protokoll të Saktë të Sinkronizimit të Orës për Sistemet e Matjes dhe Kontrollit të Rrjetit". Në vitin 2008 u publikua një standard i përmirësuar IEEE 1588-2008, i cili përshkruan PTP Version 2. Në këtë version të protokollit, saktësia dhe stabiliteti u përmirësuan, por nuk u ruajt marrëveshja me versionin e parë të protokollit. Po ashtu, në vitin 2019 doli versioni i standardit IEEE 1588-2019, që përshkruan PTP v2.1. Ky version shton disa përmirësime të vogla në PTPv2 dhe është i përshtatshëm me PTPv2.
Me fjalë të tjera, kemi këtë pamje të versioneve:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
â
Inkompatibël
Inkompatibël
PTPv2 (IEEE 1588-2008)
Inkompatibël
â
Kompaktibël
PTPv2.1 (IEEE 1588-2019)
Inkompatibël
Kompaktibël
â
Por, siç ndodh gjithmonë, ka nuanca.
Inkompatibiliteti mes PTPv1 dhe PTPv2 nënkupton që një pajisje që mbështet PTPv1 nuk do të mund të sinkronizohet nga orë të sakta që funksionojnë në PTPv2. Për sinkronizimin, ato përdorin formate të ndryshme mesazhi.
Por është e mundur të kombinohen pajisje me PTPv1 dhe pajisje me PTPv2 në një rrjet. Për këtë, disa prodhues lejojnë zgjedhjen e versionit të protokollit në portet e orëve kufitare. Kështu, orët kufitare mund të sinkronizohen në PTPv2 dhe po ashtu të sinkronizojnë orët e tjera lidhur me to në PTPv1 dhe PTPv2.
Pajisjet PTP. ĂfarĂ« lloji ekzistojnĂ« dhe si ndryshojnĂ«?
Standardi IEEE 1588v2 përshkruan disa lloje pajisjesh. Të gjitha ato janë të renditura në tabelë.
Pajisjet ndërveprojnë me njëra-tjetrën përmes LAN-it, duke përdorur PTP.
Pajisjet PTP quhen orë. Të gjitha orët marrin kohën e saktë nga orët master.
Ka 5 lloje orësh:
Grandmaster clock (Orët Grosmëster)
Burimi kryesor i kohës së saktë. Shpesh pajisen me një ndërfaqe për lidhjen e GPS-it.
Ordinary Clock (Orët e Zakonta)
Një pajisje me një port, që mund të jetë master (orë udhëheqëse) ose slave (orë në varësi)
Orët udhëheqëse (master)
Janë burim i saktë i kohës, sipas të cilit sinkronizohen orët e tjera
Orët në varësi (slave)
Pajisje përfundimtare, e cila sinkronizohet nga orët udhëheqëse
Boundary Clock (Orët Kufitare)
Pajisje me disa porte, që mund të jetë master ose slave.
Kështu këto orë mund të sinkronizohen nga orët udhëheqëse të sipërme dhe të sinkronizojnë orët e varura nga ato.
Orari Transparent End-to-End (Ora transparente që punon në modin End-to-End)
Një pajisje me porte të shumta që nuk është as ora kryesore, as ora ndihmëse. Ajo transferon të dhënat PTP midis dy orkestrave.
Gjatë transferimit të të dhënave, oraret transparente rregullojnë të gjitha mesazhet PTP.
Rregullimi ndodh përmes shtimit të kohës së vonesës në këtë pajisje në fushën e rregullimit në titullin e mesazhit të dërguar.
Orari Transparent Peer-to-Peer (Ora transparente që punon në modin Peer-to-Peer)
Një pajisje me porte të shumta që nuk është as ora kryesore, as ora ndihmëse.
Ajo transferon të dhënat PTP midis dy orkestrave.
Gjatë transferimit të të dhënave, oraret transparente rregullojnë të gjitha mesazhet PTP Sync dhe Follow_Up (për to do të flitet më shumë më poshtë).
Rregullimi arrihet përmes shtimit në fushën e rregullimit të paketës së dërguar të vonesës në pajisjen dërguese dhe vonesës në kanalin e transferimit të të dhënave.
Nod Menaxhimi (Nod Menaxhues)
Një pajisje që konfiguruesh dhe diagnostikon oraret e tjera.
Oraret kryesore dhe ndihmëse sinkronizohen përmes shenjave të kohës në mesazhet PTP. Ekzistojnë dy lloje mesazhesh në protokollin PTP:
- Mesazhet e Ngjarjeve â kĂ«to janĂ« mesazhe tĂ« sinkronizuara qĂ« parashikojnĂ« gjenerimin e shenjĂ«s sĂ« kohĂ«s nĂ« momentin e dĂ«rgimit tĂ« mesazhit dhe nĂ« momentin e marrjes sĂ« tij.
- Mesazhet e PĂ«rgjithshme â kĂ«to mesazhe nuk kĂ«rkojnĂ« shenja kohe, por mund tĂ« pĂ«rmbajnĂ« shenja tĂ« kohĂ«s pĂ«r mesazhe tĂ« lidhura.
Mesazhet e Ngjarjeve
Mesazhet e PĂ«rgjithshme
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Menaxhimi
Sinjalizimi
Më poshtë do të shqyrtohen të gjitha llojet e mesazheve më në detaje.
Problemet kryesore të sinkronizimit
GjatĂ« transferimit tĂ« paketĂ«s sĂ« sinkronizimit pĂ«rmes rrjetit lokal, ajo vonohet nĂ« switch dhe nĂ« kanal tĂ« transferimit tĂ« tĂ« dhĂ«nave. Ădo switch do tĂ« japĂ« njĂ« vonesĂ« prej rreth 10 ”s, gjĂ« qĂ« Ă«shtĂ« e papranueshme pĂ«r PTPv2. Sepse ne nĂ« pajisjen pĂ«rfundimtare kemi nevojĂ« pĂ«r saktĂ«si prej 1 ”s. (Kjo Ă«shtĂ« nĂ«se flasim pĂ«r energjinĂ«. Aplikacione tĂ« tjera mund tĂ« kĂ«rkojnĂ« saktĂ«si edhe mĂ« tĂ« madhe.)
Në IEEE 1588v2 përshkruhen disa algoritme funksionimi që lejojnë regjistrimin e vonesës në kohë dhe rregullimin e saj.
Algoritmi i punës
Gjatë punës normale, protokolli punon në dy faza.
- Faza 1 â vendosja e hierarkisĂ« "Oraret Kryesore â Oraret NdihmĂ«se".
- Faza 2 â sinkronizimi i orareve pĂ«rmes mekanizmit End-to-End ose Peer-to-Peer.
Faza 1 â Instalimi i hierarkisĂ« «Master-Slave»
Secili port i orëve të zakonshme ose kufitare ka një numër të caktuar gjendjesh (orë të udhëhequra dhe orë të nëndheshme). Standardi përshkruan algoritmin e kalimit midis këtyre gjendjeve. Në programim, ky algoritëm quhet automatik i mbarimit ose makinë gjendjesh (më shumë në Wiki).
Ky automat i mbarimit përdor algoritmin Best Master Clock Algorithm (BMCA) për të caktuar masterin kur lidhin dy orë.
Ky algoritëm lejon orët të marrin përsipër përgjegjësitë e orëve gjeniale kur orët më të larta gjeniale humbin sinjalin GPS, çaktivizohen nga rrjeti etj.
Kalimet midis gjendjesh sipas BMCA janë përmbledhur shkurtimisht në diagramin e mëposhtëm:
Informacioni për orët në anën tjetër të "telit" dërgohet në një mesazh të veçantë (Mesazhi i Njoftimit). Kur ky informacion merret, algoritmi i makinës së gjendjeve ekzekutohet dhe bëhet krahasimi se cilat orë janë më të mira. Porti në orët më të mira bëhet orë udhëheqëse.
Hierarkia e thjeshtĂ« paraqitet nĂ« diagramin e mĂ«poshtĂ«m. RrugĂ«t 1, 2, 3, 4, 5 mund tĂ« pĂ«rmbajnĂ« orĂ« tĂ« tejdukshme (Transparent clock), por ato nuk marrin pjesĂ« nĂ« pĂ«rcaktimin e hierarkisĂ« «OrĂ« udhĂ«heqĂ«se â OrĂ« tĂ« nĂ«ndheshme».
Faza 2 â Sinkronizimi i orĂ«ve tĂ« zakonshme dhe kufitare
MenjĂ«herĂ« pas vendosjes sĂ« hierarkisĂ« «OrĂ« udhĂ«heqĂ«se â OrĂ« tĂ« nĂ«ndheshme» fillon faza e sinkronizimit tĂ« orĂ«ve tĂ« zakonshme dhe kufitare.
Për sinkronizim, orët udhëheqëse dërgojnë orëve të nëndheshme një mesazh që përmban një etiketë kohe.
Orët udhëheqëse mund të jenë:
- një-niveli;
- dy-niveli.
Orët një-niveli për sinkronizim dërgojnë një mesazh Sync.
OrĂ«t dy-niveli pĂ«r sinkronizim pĂ«rdorin dy mesazhe â Sync dhe Follow_Up.
Për fazën e sinkronizimit mund të përdoren dy mekanizma:
- Mekanizmi i kërkesës-përgjigjes për vonesën (Delay request-response mechanism).
- Mekanizmi i matjes së vonesës së fqinjit (Peer delay measurement mechanism).
SĂ« pari, le tĂ« shqyrtojmĂ« kĂ«ta mekanizma nĂ« rastin mĂ« tĂ« thjeshtĂ« â kur nuk aplikohen orĂ« tĂ« tejdukshme.
Mekanizmi i kërkesës-përgjigjes për vonesën (Delay request-response mechanism)
Mekanizmi parashikon dy hapa:
- Matja e vonesës në transferimin e mesazhit midis orëve udhëheqëse dhe orëve të nëndheshme. Ekzekutohet përmes mekanizmit të kërkesës-përgjigjes për vonesën.
- Ekzekutohet korrigjimi i devijimit të kohës së saktë.
Matja e vonesës
t1 â Koha e dĂ«rgimit tĂ« mesazhit Sync nga orĂ«t kryesore; t2 â Koha e pranimit tĂ« mesazhit Sync nga orĂ«t ndihmĂ«se; t3 â Koha e dĂ«rgimit tĂ« kĂ«rkesĂ«s pĂ«r vonesĂ« (Delay_Req) nga orĂ«t ndihmĂ«se; t4 â Koha e pranimit tĂ« Delay_Req nga orĂ«t kryesore.
Kur orët ndihmëse dinë kohën t1, t2, t3 dhe t4, ato mund të llogarisin vonesën mesatare gjatë dërgimit të mesazhit të sinkronizimit (tmpd). Ajo llogaritet si më poshtë:
GjatĂ« dĂ«rgimit tĂ« mesazhit Sync dhe Follow_Up, llogaritet vonesa kohore nga master nĂ« slave â t-ms.
GjatĂ« dĂ«rgimit tĂ« mesazheve Delay_Req dhe Delay_Resp, llogaritet vonesa kohore nga slave nĂ« master â t-sm.
Nëse mes këtyre dy vlerave ndodhet ndonjë asimetri, atëherë shfaqet një gabim në korrigjimin e saktësisë së kohës. Gabimi vjen si pasojë e faktit se vonesa e llogaritur është mesatare nga vonesat t-ms dhe t-sm. Nëse vonesat nuk janë të barabarta me njëra-tjetrën, atëherë do të korrigjojmë kohën jo saktë.
Korrigjimi i përmasës së saktësisë së kohës.
Pasi që vonesa midis orëve kryesore dhe orëve ndihmëse është e njohur, orët ndihmëse kryejnë korrigjimin e kohës.
Orët ndihmëse përdorin mesazhin Sync dhe mesazhin opsional Follow_Up për të llogaritur përmasën e saktësisë së kohës gjatë dërgimit të pakos nga orët kryesore në orët ndihmëse. Përmasa llogaritet me formulën e mëposhtme:
Mekanizmi i matjes së vonesës së fqinjëve (Peer delay measurement mechanism).
Ky mekanizëm gjithashtu përdor dy hapa për sinkronizimin:
- Dispositivet matin vonesën kohore me të gjithë fqinjët përmes të gjitha porteve. Për këtë ata përdorin mekanizmin e vonesës së fqinjëve.
- Korrigjimi i përmasës së saktësisë së kohës.
Matja e vonesës midis dispozitivëve, të cilët mbështesin modin Peer-to-Peer.
Vonesa midis porteve, të cilat mbështesin mekanizmin peer-to-peer, matet me ndihmën e mesazheve të mëposhtme:
Kur porta 1 e di kohën t1, t2, t3 dhe t4, ajo mund të llogarisë vonesën mesatare (tmld). Ajo llogaritet me formulën e mëposhtme:
Pastaj porta e përdor këtë vlerë gjatë llogaritjes së fushës së korrigjimit për secilin mesazh Sync ose mesazhin opsional Follow_Up, që kalon përmes këtij dispositivi.
Vonesa përfundimtare do të jetë e barabartë me shumën e vonesës gjatë dërgimit përmes këtij dispositivi, vonesës mesatare gjatë dërgimit përmes kanalit të të dhënave dhe vonesës tashmë të përfshirë në këtë mesazh, përfshirë në dispozitivët më të lartë.
Mesazhet Pdelay_Req, Pdelay_Resp dhe opsionale Pdelay_Resp_Follow_Up lejojnë marrjen e vonesës nga masteri te sklavi dhe nga skllavi te masteri (në rreth).
Ădo asimetri midis kĂ«tyre dy vlerave do tĂ« sjellĂ« njĂ« gabim nĂ« korrigjimin e zhvendosjes sĂ« kohĂ«s sĂ« saktĂ«.
Korrigjimi i zhvendosjes së kohës së saktë
Orët e varura përdorin mesazhin Sync dhe mesazhin opsional Follow_Up për të llogaritur zhvendosjen e kohës së saktë gjatë transmetimit të paketës nga orët e udhëhequra te ato të varura. Zhvendosja llogaritet sipas formulës së mëposhtme:
PĂ«rfitimet e mekanizmit tĂ« korrigjimit peer-to-peer â vonesa e çdo mesazhi Sync ose Follow_Up llogaritet gjatĂ« kalimit tĂ« tij nĂ« rrjet. Ndaj, ndryshimi i rrugĂ«s sĂ« transmetimit nuk do tĂ« ndikojĂ« aspak nĂ« saktĂ«sinĂ« e korrigjimit.
Me përdorimin e këtij mekanizmi, sinkronizimi i kohës nuk kërkon llogaritjen e vonesës së kohës në rrugën e kaluar nga paketa e sinkronizimit, siç bëhet me shkëmbimin bazë. Kjo do të thotë se mesazhet Delay_Req dhe Delay_Resp nuk dërgohen. Në këtë metodë, vonesa midis orëve udhëheqëse dhe atyre të varura thjesht shumizohet në fushën e korrigjimit të çdo mesazhi Sync ose Follow_Up.
NjĂ« tjetĂ«r pĂ«rfitim â orĂ«t udhĂ«heqĂ«se çlirohen nga nevoja pĂ«r tĂ« pĂ«rpunuar mesazhet Delay_Req.
Mënyrat e funksionimit të orëve transparente
Përkatësisht, këto ishin shembuj të thjeshtë. Tani le të supozojmë se në rrugën e sinkronizimit shfaqen switch-e.
Nëse përdoren switch-e pa mbështetje PTPv2, atëherë paketa e sinkronizimit do të përjetohet me vonesë në switch për rreth 10 mikrosekonda.
Switch-e me mbĂ«shtetje PTPv2 nĂ« terminologjinĂ« IEEE 1588v2 quhen orĂ« transparente (Transparent clock). OrĂ«t transparente nuk sinkronizohen nga orĂ«t udhĂ«heqĂ«se dhe nuk marrin pjesĂ« nĂ« hierarkinĂ« "OrĂ«t UdhĂ«heqĂ«se â OrĂ«t e Varura", por gjatĂ« transmetimit tĂ« mesazheve tĂ« sinkronizimit, ato mbajnĂ« mend sa kohĂ« Ă«shtĂ« vonuar mesazhi te ato. Kjo lejon korrigjimin e vonesĂ«s sĂ« kohĂ«s.
Orët transparente mund të funksionojnë në dy mënyra:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Orët transparente E2E dërgojnë mesazhet Sync dhe mesazhet përkatëse Follow_Up në të gjitha portet. Edhe ato që janë bllokuar nga ndonjë protokoll (për shembull, RSTP).
Switchi mban hallakun momentin kur të paketa Sync (Follow_Up) u pranua në port dhe kur u dërgua nga porta. Në bazë të këtyre dy momentëve, llogaritet koha e përpunimit të mesazhit nga switchi. Në standard, kjo kohë quhet koha e rezidencës.
Koha e përpunimit shtohet në fushën correctionField të mesazhit Sync (orë njëfazore) ose Follow_Up (orë dyfazore).
Orët E2E transparente matin kohën e përpunimit për mesazhet Sync dhe Delay_Req që kalojnë nëpër switch. Por është e rëndësishme të kuptohet se vonesa midis orëve kryesore dhe orëve ndihmëse llogaritet përmes mekanizmit të kërkesës- përgjigjes për vonesën. Nëse orët kryesore ndryshojnë ose rruga nga orët kryesore në orët ndihmëse ndryshon, atëherë vonesa matet përsëri. Kjo rrit kohën e kalimit në rast të ndryshimeve në rrjet.
Orët P2P transparente, përveç matjes së kohës së përpunimit të mesazhit nga switchi, masin vonesën në kanalin e transmetimit deri te fqinjët më të afërt, duke përdorur mekanizmin e matjes së vonesës së fqinjit.
Vonesa matet në çdo kanal në të dyja drejtimet, duke përfshirë kanalet që janë të bllokuara nga ndonjë protokoll (p.sh., RSTP). Kjo mundëson llogaritjen e menjëhershme të vonesës së re në rrugën e sinkronizimit, nëse orët kryesore ose topologjia e rrjetit kanë ndryshuar.
Koha e përpunimit të mesazheve nga switch-at dhe koha e vonesës akumulohen gjatë dërgimit të mesazheve Sync ose Follow_Up.
Llojet e mbështetjes PTPv2 nga switch-at
Switch-at mund të mbështesin PTPv2:
- në mënyrë softuerike;
- në mënyrë harduerike.
Në realizimin softuerik të protokollit PTPv2, switch-i kërkon momentin nga firmware. Problemi është se firmware-a punon ciklikisht, dhe do të duhet të prisni derisa të përfundojë cikli aktual, të marrë kërkesën në përpunim dhe pas përfundimit të ciklit të ardhshëm të japë momentin. Kjo gjithashtu do të marrë kohë, dhe ne do të kemi vonesë, ndonëse jo aq të rëndësishme sa pa mbështetje softuerike për PTPv2.
Saktësia e nevojshme sigurohet vetëm nga mbështetje harduerike për PTPv2. Në këtë rast, lëshimi i momentit bëhet nga një ASIC special, i cili është i instaluar në port.
Formati i mesazhit
Të gjitha mesazhet PTP përbëhen nga fushat e mëposhtme:
- Header â 34 byte.
- Body â madhĂ«sia varet nga lloji i mesazhit.
- Suffix â opsional.
Header
Fusha Header është e njëjtë për të gjitha mesazhet PTP. Masa e tij është 34 byte.
Formati i fushës Header:
messageType â pĂ«rmban tipin e mesazhit tĂ« dĂ«rguar, si p.sh. Sync, Delay_Req, PDelay_Req etj.
messageLength â pĂ«rmban madhĂ«sinĂ« totale tĂ« mesazhit PTP, pĂ«rfshirĂ« header, body dhe suffix (por duke pĂ«rjashtuar byte tĂ« mbushjes).
domainNumber â pĂ«rcakton se cilit domen PTP i pĂ«rket mesazhi.
Domaini â Ă«shtĂ« disa orĂ« tĂ« ndryshme tĂ« mbledhura nĂ« njĂ« grup tĂ« logjikshĂ«m dhe tĂ« sinkronizuara nga orĂ«t udhĂ«heqĂ«se, por nuk janĂ« domosdoshmĂ«risht tĂ« sinkronizuara me orĂ«t qĂ« i pĂ«rkasin njĂ« domene tjetĂ«r.
flags â kjo fushĂ« pĂ«rmban flamuj tĂ« ndryshĂ«m pĂ«r identifikimin e statusit tĂ« mesazhit.
correctionField â pĂ«rmban kohĂ«n e vonesĂ«s nĂ« nanosekonda. Koha e vonesĂ«s pĂ«rfshin vonesĂ«n gjatĂ« dĂ«rgimit pĂ«rmes orĂ«ve transparente, si dhe vonesĂ«n gjatĂ« dĂ«rgimit pĂ«rmes kanalit kur pĂ«rdoret mĂ«nyra Peer-to-Peer.
sourcePortIdentity â kjo fushĂ« pĂ«rmban informacion mbi portin nga u dĂ«rguar fillimisht ky mesazh.
sequenceID â pĂ«rmban numrin identifikues pĂ«r mesazhe individuale.
controlField â fushĂ« artefakti =). Ka mbetur nga versioni i parĂ« i standardit dhe pĂ«rmban informacion mbi tipin e kĂ«tij mesazhi. NĂ« thelb, Ă«shtĂ« e njĂ«jtĂ« me messageType, por me njĂ« numĂ«r mĂ« tĂ« vogĂ«l opsionesh.
logMessageInterval â kjo fushĂ« pĂ«rcaktohet nga tipi i mesazhit.
Body
Siç u diskutua më sipër, ka disa tipe mesazhesh. Këto tipe janë përshkruar më poshtë:
Mesazhi Announce
Mesazhi Announce pĂ«rdoret pĂ«r tĂ« "treguar" orĂ«ve tĂ« tjera brenda njĂ« domene pĂ«r parametrat e tij. Ky mesazh lejon vendosjen e hierarkisĂ« "OrĂ«t UdhĂ«heqĂ«se â OrĂ«t NĂ«nshtruese".
Mesazhi Sync
Mesazhi i sinkronizimit (Sync) dërgohet nga orët udhëheqëse dhe përmban kohën e orëve udhëheqëse në momentin kur mesazhi Sync u krijua. Nëse orët udhëheqëse janë me dy nivele, atëherë shenja e kohës në mesazhin Sync do të barazohet me 0, dhe shenja e kohës aktuale do të dërgohet në mesazhin e lidhur Follow_Up. Mesazhi Sync përdoret për të dy mekanizmat e matjes së vonesës.
Mesazhi dërgohet nëpërmjet Multicast. Opsionalisht mund të përdoret Unicast.
Mesazhi Delay_Req
Formati i mesazhit Delay_Req është identik me mesazhin Sync. Orët nënshtruese dërgojnë Delay_Req. Ai përmban kohën e dërgimit të Delay_Req nga orët nënshtruese. Ky mesazh përdoret vetëm për mekanizmin e kërkesës-përgjigjes për vonesën.
Mesazhi dërgohet nëpërmjet Multicast. Opsionalisht mund të përdoret Unicast.
Mesazhi Follow_Up
Mesazhi Follow_Up dërgohet opsionalisht nga orët udhëzuese dhe përmban kohën e dërgimit mesazhet Sync masterit. Mesazhi Follow_Up dërgohet vetëm nga orët udhëzuese me dy hapa.
Mesazhi Follow_Up përdoret për të dy mekanizmat e matjes së vonesës.
Mesazhi dërgohet nëpërmjet Multicast. Opsionalisht mund të përdoret Unicast.
Mesazhi Delay_Resp
Mesazhi Delay_Resp dërgohet nga orët udhëzuese. Ai përmban kohën e pranimit të Delay_Req nga orët udhëzuese. Ky mesazh përdoret vetëm për mekanizmin e kërkesë-përgjigje të vonesës.
Mesazhi dërgohet nëpërmjet Multicast. Opsionalisht mund të përdoret Unicast.
Mesazhi Pdelay_Req
Mesazhi Pdelay_Req dërgohet nga pajisja që kërkon vonesën. Ai përmban kohën e dërgimit të mesazhit nga porta e kësaj pajisjeje. Pdelay_Req përdoret vetëm për mekanizmin e matjes së vonesës së fqinjit.
Mesazhi Pdelay_Resp
Mesazhi Pdelay_Resp dërgohet nga pajisja që mori kërkesën për vonesë. Ai përmban kohën e pranimit të mesazhit Pdelay_Req nga kjo pajisje. Mesazhi Pdelay_Resp përdoret vetëm për mekanizmin e matjes së vonesës së fqinjit.
Mesazhi Pdelay_Resp_Follow_Up
Mesazhi Pdelay_Resp_Follow_Up dërgohet opsionalisht nga pajisja që mori kërkesën për vonesë. Ai përmban kohën e pranimit të mesazhit Pdelay_Req nga kjo pajisje. Mesazhi Pdelay_Resp_Follow_Up dërgohet vetëm nga orët udhëzuese me dy hapa.
Gjithashtu, ky mesazh mund të përdoret për kohën e ekzekutimit në vend të shenjës së kohës. Koha e ekzekutimit është koha nga momenti i pranimit të Pdelay-Req deri në dërgimin e Pdelay_Resp.
Pdelay_Resp_Follow_Up përdoren vetëm për mekanizmin e matjes së vonesës së fqinjit.
Mesazhet menaxhuese (Mesazhi Management)
Mesazhet menaxhuese PTP janë të nevojshme për të transferuar informacionin midis një ose më shumë orëve dhe nodit menaxhuese.
Transferimi në LV
Mesazhi PTP mund të transferohet në dy nivele:
- Niveli rrjetit â si pjesĂ« e tĂ« dhĂ«nave IP.
- Niveli kanalesh â si pjesĂ« e kufijve Ethernet.
Transferimi i mesazhit PTP përmes UDP përmes IP përmes Ethernet
PTP përmes UDP përmes Ethernet
Profillet
PTP ka një numër të lartë parametrash "fleksibël" që duhet të konfigurohen. Për shembull:
- Opsionet BMCA.
- Mekanizmi i matjes së vonesës.
- Intervalet dhe vlerat fillestare të të gjitha parametrave të konfigurueshëm etj.
Dhe, megjithatë, megjithëse më parë thamë se pajisjet PTPv2 janë të pajtueshme me njëra-tjetrën, në realitet kjo nuk është e vërtetë. Pajisjet duhet të kenë të njëjtat konfigurime për të bashkëpunuar.
Prandaj ekzistojnë ashtuquajturat profile PTPv2. Profilet janë grupe të konfigurimeve të caktuara dhe kufizimeve të protokollit, në mënyrë që të mund të realizohet sinkronizimi i kohës për një aplikacion të caktuar.
Standardi IEEE 1588v2 pĂ«rshkruan vetĂ«m njĂ« profil â "Default Profile". TĂ« gjitha profilet e tjera janĂ« krijuar dhe pĂ«rshkruar nga organizata dhe shoqata tĂ« ndryshme.
Për shembull, profili për energjinë elektrike ose PTPv2 Power Profile është krijuar nga Komiteti për Sistemet e Energjisë dhe Komiteti për Nënstacionin e Shoqërisë IEEE Power and Energy. Profili vetë mban emrin IEEE C37.238- 2011.
Profili përshkruan se PTP mund të transmetohet:
- Vetëm përmes rrjeteve L2 (dmth, Ethernet, HSR, PRP, jo IP).
- Mesazhet transmetohen vetëm me shpërndarje Multicast.
- Si mekanizëm për matjen e vonesës përdoret mekanizmi i matjes së vonesës së Peer.
Domeni i paracaktuar është 0, domeni i rekomanduar është 93.
Në filozofinë e krijimit të C37.238- 2011 qëndron dëshira për të reduktuar numrin e karakteristikave opsionale dhe për të lënë vetëm funksionet e nevojshme për ndërveprimin e sigurt midis pajisjeve dhe për të rritur stabilitetin e sistemit.
Gjithashtu, është përcaktuar frekuenca e transmetimit të mesazheve:
NĂ« thelb, pĂ«r tĂ« zgjedhur Ă«shtĂ« i disponueshĂ«m vetĂ«m njĂ« parametr â lloji i orĂ«ve kryesore (me njĂ« nivel ose dy nivele).
SaktĂ«sia duhet tĂ« jetĂ« jo mĂ« shumĂ« se 1 ÎŒs. Me fjalĂ« tĂ« tjera, nĂ« njĂ« rrugĂ« sinkronizimi mund tĂ« ketĂ« maksimumi 15 orĂ« transparente ose tre orĂ« kufitare.
Burimi: habr.com
