Hyrje
Koncepcioni i ndërtimit të "Nënstacionit digjital" në energjinë elektrike kërkon sinkronizim me një saktësi prej 1 ”s. Për të kryer transaksione financiare nevojitet gjithashtu saktësi në ”s. Në këto aplikacione, saktësia e kohës NTP nuk është më e mjaftueshme.
Protokolli i sinkronizimit PTPv2, i përshkruar në standardin IEEE 1588v2, lejon arritjen e saktësisë së sinkronizimit në disa dhjetëra nanosekonda. PTPv2 lejon dërgimin e paketave të sinkronizimit përmes rrjeteve L2 dhe L3.
Fushat kryesore ku aplikohet PTPv2 përfshijnë:
- energjia;
- pajisjet e kontrollit dhe matjes;
- kompleksi industrial-mbrojtës;
- telekomi;
- sektori financiar.
Në këtë postim, shqyrtohet se si punon protokolli i sinkronizimit PTPv2.
Ne kemi më shumë përvojë në industri dhe shpesh hasim këtë protokoll në aplikacionet energjetike. Prandaj, do të bëjmë një përmbledhje për energjinë .
Përse është e nevojshme?
Aktualisht, 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ërkesa për organizimin e autobusit të procesit me sigurinë e sinkronizimit të kohës sipas PTPv2.
Kjo është e lidhur me faktin se në autobusin e procesit lidhen terminalet e mbrojtjes relé dhe pajisjet e matjes, të cilat përmes autobusit të procesit, me ndihmën e ashtuquajturave rrjedha SV (multicast), përcjellin vlerat momentale të rrymës dhe tensionit.
Terminalet e mbrojtjes relé përdorin këto vlera për të realizuar mbrojtjet e lidhjeve. Nëse saktësia e matjeve në kohë është e vogël, atëherë disa mbrojtje mund të veprojnë gabimisht.
PĂ«r shembull, viktima e "sinkronizimit tĂ« dobĂ«t" nĂ« kohĂ« mund tĂ« jenĂ« mbrojtjet e absolutĂ«s selektiviteti. Shpesh logjika e kĂ«tyre mbrojtjeve ndĂ«rtohet mbi krahasimin e dy vlerave. NĂ«se vlerat ndryshojnĂ« nĂ« njĂ« sasi tĂ« mjaftueshme, mbrojtja aktivizohet. NĂ«se kĂ«to vlera maten me saktĂ«si tĂ« kohĂ«s 1 ms, atĂ«herĂ« mund tĂ« merret njĂ« ndryshim i madh, aty ku vlerat nĂ« tĂ« vĂ«rtetĂ« janĂ« nĂ« normĂ«, nĂ«se i matim ato me saktĂ«si 1 ÎŒs.
Versionet PTP
Protokolli PTP u përshkrua fillimisht në vitin 2002 në standardin IEEE 1588-2002 dhe kishte emrin "Standard për një Protokoll të Sinchronizimit të Orës me Saktësi për Sistemet e Matjes dhe Kontrollit të Rrjetit". Në vitin 2008 u publikua standardi 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 përshtatshmëria prapa me versionin e parë të protokollit. Po ashtu, në vitin 2019 doli versioni i standardit IEEE 1588-2019, i cili përshkruan PTP v2.1. Ky version shton disa përmirësime të vogla në PTPv2 dhe është përshtatshëm prapa me PTPv2.
Me fjalë të tjera, kemi këtë pamje me versionet:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
â
Incompatible
Incompatible
PTPv2 (IEEE 1588-2008)
Incompatible
â
Compatible
PTPv2.1 (IEEE 1588-2019)
Incompatible
Compatible
â
Por, si gjithmonë, ka nuanca.
Inkompatibiliteti midis PTPv1 dhe PTPv2 nënkupton se një pajisje që mbështet PTPv1 nuk do të mund të sinchronizohet nga orët e sakta që punojnë në PTPv2. Për sinchronizim ata përdorin formate të ndryshme mesazhesh.
Por ndërlidhjen e pajisjeve me PTPv1 dhe pajisjeve me PTPv2 në të njëjtën rrjet është e mundur. 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 sipas PTPv2 dhe njëkohësisht të sinkronizojnë orët e tjera të lidhura me to sipas PTPv1 dhe PTPv2.
Pajisjet PTP. ĂfarĂ« llojesh ka dhe si ndryshojnĂ« ato?
Standardi IEEE 1588v2 përshkruan disa lloje pajisjesh. Të gjitha ato janë të listuara në tabelë.
Pajisjet bashkëveprojnë 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 kryesore.
Ka 5 lloje orësh:
Grandmaster clock (Orë kryesore)
Burimi kryesor i kohës së saktë. Shpesh pajiset me ndërfaqe për lidhje GPS.
Ordinary Clock (Orë të zakonshme)
Pajisje me një port, që mund të jetë master (ora udhëheqëse) ose slave (ora ndihmëse)
Ora udhëheqëse (master)
Janë burimi i kohës së saktë sipas të cilit sinkronizohen orët e tjera
Ora ndihmëse (slave)
Pajisja përfundimtare që sinkronizohet nga orët udhëheqëse
Boundary Clock (Orë kufitare)
Një pajisje me disa porte që mund të jetë master ose slave.
Kjo do të thotë se këto orë mund të sinkronizohen nga orët që janë lider dhe të sinkronizojnë orët që janë ndihmës.
End-to-end Transparent Clock (Orë të Qarta, që punojnë në mënyrë End-to-End)
Një pajisje me disa porte që nuk është as lider as ndihmës. Ajo transmeton të dhëna PTP midis dy orëve.
Gjatë transmetimit të të dhënave, orët e qarta rregullojnë të gjitha mesazhet PTP.
Rregullimi bëhet 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.
Peer-to-Peer Transparent Clock (Orë të Qarta, që punojnë në mënyrë Peer-to-Peer)
Një pajisje me disa porte që nuk është as lider as ndihmës.
Ajo transmeton të dhëna PTP midis dy orëve.
Gjatë transmetimit të të dhënave, orët e qarta rregullojnë të gjitha mesazhet PTP Sync dhe Follow_Up (për to do të flas 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ë kanal.
Management Node (Njësi Menaxhuese)
Një pajisje që konfiguron dhe diagnostikon saatet e tjera
Sahat kryesor dhe sahat ndihmës sinkronizohen përmes etiketave të kohës në mesazhet PTP. Ekzistojnë dy lloje mesazhesh në protokollin PTP:
- Mesazhet e Ngjarjeve â kĂ«to janĂ« mesazhe tĂ« sinkronizuara qĂ« kĂ«rkojnĂ« krijimin e njĂ« etikete tĂ« kohĂ«s nĂ« momentin e dĂ«rgimit dhe nĂ« momentin e marrjes sĂ« mesazhit
- Mesazhet e PĂ«rgjithshme â kĂ«to mesazhe nuk kĂ«rkojnĂ« etiketa tĂ« kohĂ«s, por mund tĂ« pĂ«rmbajnĂ« etiketat e 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
Shenjat
Të gjitha llojet e mesazheve do të shqyrtohen më në detaje.
Problemet kryesore të sinkronizimit
GjatĂ« dĂ«rgimit tĂ« njĂ« pakete sinkronizimi pĂ«rmes rrjetit lokal, ajo vonohet nĂ« switch dhe nĂ« kanal. Ădo switch do tĂ« japĂ« njĂ« vonesĂ« prej rreth 10 ”s, qĂ« Ă«shtĂ« e papranueshme pĂ«r PTPv2. Sepse ne nĂ« pajisjen pĂ«rfundimtare kemi nevojĂ« pĂ«r njĂ« saktĂ«si prej 1 ”s. (Kjo 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 algoritma funksionimi që lejojnë ecurinë e vonesës së kohës dhe korrigjimin e saj.
Algoritmi i funksionimit
Në punën normale, protokolli operon në dy faza.
- Faza 1 â ngritja e hierarkisĂ« "OrĂ«t Kryesore â OrĂ«t NĂ«nshtruese".
- Faza 2 â sinkronizimi i orĂ«ve nĂ«pĂ«rmjet mekanizmit End-to-End ose Peer-to-Peer.
Faza 1 â Ngritja e hierarkisĂ« "Master-Slave".
Ădo port i orĂ«ve normale ose kufitare ka njĂ« numĂ«r tĂ« caktuar gjendjesh (orĂ«t nĂ«nshtruese dhe orĂ«t kryesore). Standardi pĂ«rshkruan algoritmin e kalimit midis kĂ«tyre gjendjeve. NĂ« programim, njĂ« algoritĂ«m i tillĂ« quhet automatik fundor ose makinĂ« gjendjesh (mĂ« shumĂ« nĂ« Wiki).
Ky automatik fundor përdor algoritmin Best Master Clock Algorithm (BMCA) për të caktuar masterin kur lidhen dy orë.
Ky algoritëm lejon që orët të marrin përsipër detyrimet e orëve kryesore kur orët më të larta humbasin sinjalin GPS, çaktivizohen nga rrjeti etj.
Kalimet midis gjendjeve sipas BMCA janë paraqitur shkurtimisht në diagramin e mëposhtëm:

Informacionet mbi orët në anën tjetër të "telit" dërgohen në një mesazh të veçantë (Mesazhi i njoftimit). Kur këto informacione pranohen, algoritmi i makinës së shteteve ekzekutohet dhe bëhet krahasimi i orëve më të mira. Porta në orët më të mira bëhet ora lidere.
Hierarkia e thjeshtĂ« paraqitet nĂ« skemĂ«n mĂ« poshtĂ«. RrugĂ«t 1, 2, 3, 4, 5 mund tĂ« pĂ«rmbajnĂ« orĂ« transparente (Transparent clock), por ato nuk marrin pjesĂ« nĂ« vendosjen e hierarkisĂ« "OrĂ«t Lidere â OrĂ«t NĂ«nshtruese".

Faza 2 â Sinkronizimi i orĂ«ve tĂ« zakonshme dhe atyre kufitare.
MenjĂ«herĂ« pas caktimit tĂ« hierarkisĂ« "OrĂ«t Lidere â OrĂ«t NĂ«nshtruese" fillon faza e sinkronizimit tĂ« orĂ«ve tĂ« zakonshme dhe atyre kufitare.
Për sinkronizimin, orët udhëheqëse dërgojnë orëve nënshtruese një mesazh që përmban një etiketë kohore.
Orët udhëheqëse mund të jenë:
- me një shkallë;
- me dy shkallë.
Orët me një shkallë për sinkronizim dërgojnë një mesazh Sync.
OrĂ«t me dy shkallĂ« 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ë (Delay request-response mechanism).
- Mekanizmi i matjes së vonesës së nodit fqinj (Peer delay measurement mechanism).
Së pari, le të shqyrtojmë këto mekanizma në rastin më të thjeshtë - kur nuk aplikohen orë transparente.
Mekanizmi i kërkesës-përgjigje për vonesën (Delay request-response mechanism)
Mekanizmi parashikon dy hapa:
- Matura e vonesës gjatë transmetimit të mesazhit midis orëve kryesore dhe atyre ndihmëse. Realizohet përmes mekanizmit të kërkesës-përgjigje për vonesën.
- Korrigjohet zhvendosja e kohës së saktë.
Matura 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ën (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ë transmetimit të mesazhit të sinkronizimit (tmpd). Ajo llogaritet si më poshtë:

Gjatë transmetimit të mesazhit Sync dhe Follow_Up, llogaritet vonesa e kohës nga masteri te skllavi - t-ms.
Gjatë transmetimit të mesazheve Delay_Req dhe Delay_Resp, llogaritet vonesa e kohës nga skllavi te masteri - t-sm.
Nëse ka një asimetri midis këtyre dy vlerave, shfaqet një gabim në korrigjimin e kohës së saktë. Gabimi për shkak të faktit se vonesa e llogaritur është mesatare e vonesave t-ms dhe t-sm. Nëse vonesat nuk janë të barabarta, ne do të korrigjojmë kohën inaccurat.
Korrigjimi i zhvendosjes së kohës së saktë
Pasi të dihet vonesa midis orës së kryesore dhe orëve të pasme, orët e pasme kryejnë korrigjimin e kohës.

Orët e pasme përdorin mesazhin Sync dhe mesazhin opsional Follow_Up për të llogaritur zhvendosjen e kohës së saktë gjatë transferimit të paketës nga orët kryesore te orët e pasme. Zhvendosja llogaritet sipas formulës së 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 të realizuar sinkronizimin:
- Dispozitivet masin vonesën e kohës deri te të gjithë fqinjët përmes të gjithë porteve. Për këtë, ata përdorin mekanizmin e vonesës fqinjës.
- Korrigjimi i zhvendosjes së kohës së saktë.
Matja e vonesës midis pajisjeve që mbështesin modin Peer-to-Peer
Vonesa midis porteve që mbështesin mekanizmin peer-to-peer matet nëpërmjet mesazheve të mëposhtme:

Kur porta 1 dihet koha t1, t2, t3 dhe t4, ai mund të llogarisë vonesën mesatare (tmld). Ajo llogaritet sipas formulës së mëposhtme:

Pastaj porta përdor këtë vlerë kur llogarit fushën e korrigjimit për çdo mesazh Sync ose mesazhin opsional Follow_Up, të cilat kalojnë përmes këtij pajisjeje.
Vonesa përfundimtare do të jetë e barabartë me shumën e vonesës gjatë transmetimit përmes kësaj pajisjeje, vonesës mesatare gjatë transmetimit përmes kanalit të dhënash dhe vonesës që tashmë është e pranishme në këtë mesazh, e përfshirë në pajisjet e larta.
Mesazhet Pdelay_Req, Pdelay_Resp dhe opsionale Pdelay_Resp_Follow_Up lejojnë të merret vonesa nga masteri te skllavi dhe nga skllavi te masteri (në cikël).
Cila do asimetria 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 ndjekura 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 udhëheqëse te ato të ndjekura. 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. Prandaj, ndryshimi i rrugĂ«s sĂ« transmetimit nuk do tĂ« ketĂ« asnjĂ« ndikim nĂ« saktĂ«sinĂ« e korrigjimit.
Duke përdorur këtë mekanizëm, sinkronizimi i kohës nuk kërkon llogariten e vonesës së kohës në rrugën që kalon paketi i sinkronizimit, siç ndodh me shkëmbimin bazë. Pra, mesazhet Delay_Req dhe Delay_Resp nuk dërgohen. Në këtë metodë, vonesa midis orëve kryesore dhe atyre ndihmës thjesht përmbledhet në fushën e korrigjimit të çdo mesazhi Sync ose Follow_Up.
NjĂ« tjetĂ«r pĂ«rfitim â orĂ«t kryesore shkarkohen nga nevoja pĂ«r tĂ« pĂ«rpunuar mesazhet Delay_Req.
Modet 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.
NĂ«se pĂ«rdoren ç switch pa mbĂ«shtetje PTPv2, atĂ«herĂ« paketi i sinkronizimit do tĂ« vonohet nĂ« switch pĂ«r rreth 10 ÎŒs.
Switches that support PTPv2 in IEEE 1588v2 terminology are referred to as transparent clocks. Transparent clocks do not synchronize from master clocks and do not participate in the hierarchy of 'Master clocks - Slave clocks', but they store the delay that sync messages experience while being transmitted. This allows for time delay correction.
Transparent clocks can operate in two modes:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)

E2E transparent clocks transmit Sync messages and associated Follow_Up messages to all ports, including those blocked by various protocols (such as RSTP).
The switch records the timestamp when the Sync (Follow_Up) packet was received on the port and when it was sent from the port. Based on these two timestamps, the processing time of the message by the switch is calculated. In the standard, this time is referred to as residence time.
The processing time is added to the correctionField of the Sync message (one-step clocks) or Follow_Up (two-step clocks).

Orët transparente E2E maten kohën e përpunimit për mesazhet Sync dhe Delay_Req që kalojnë përmes ndërruesit. Por është e rëndësishme të kuptohet se vonesa e kohës midis orëve kryesore dhe atyre ndihmëse llogaritet përmes një mekanizmi pyetje-përgjigje të vonesës. Nëse orët kryesore ndryshojnë ose rruga nga orët kryesore në ato ndihmëse ndryshon, atëherë vonesa matet përsëri. Kjo rrit kohën e kalimit në rastin e ndryshimeve në rrjet.

Orët transparente P2P, përveç matjes së kohës së përpunimit të mesazhit nga ndërruesi, masin vonesën në kanalin e transmetimit deri te fqinja më e afërt, duke përdorur një mekanizëm matës të 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 lejon llogaritjen e menjëhershme të vonesës së re në rrugën e sinkronizimit, nëse orët e mjeshtrit ose topologjia e rrjetit ndryshojnë.
Kohët e përpunimit të mesazheve nga ndërruesit dhe kohën e vonesës akumulohet gjatë transmetimit të mesazheve Sync ose Follow_Up.
Llojet e mbështetjes PTPv2 nga ndërruesit
Ndërruesit mund të mbështesin PTPv2:
- me program;
- me pajisje.
Në realizimin programatik të protokollit PTPv2, switch-i kërkon një shenjë kohezioni nga firmware. Problemi është se firmware funksionon në një cikël, dhe do të duhet të presim deri sa të përfundojë cikli aktual, të marrë kërkesën për përpunim dhe të lëshojë shenjën kohezioni në fund të ciklit të ardhshëm. Kjo gjithashtu do të marrë kohë, dhe do të marrim një vonesë, ndonëse jo kaq të rëndësishme si pa mbështetje programatike PTPv2.
Për të arritur saktësi të nevojshme, është e domosdoshme mbështetje hardware për PTPv2. Në këtë rast, lëshimi i shenjës kohezioni realizohet nga një ASIC i veçantë, 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 â me opsion.

Header
Fusha Header Ă«shtĂ« e njĂ«jtĂ« pĂ«r tĂ« gjitha mesazhet PTP. MadhĂ«sia e tij â 34 byte.
Formati i fushës Header:

messageType â pĂ«rmban tipin e mesazhit tĂ« dĂ«rguar, pĂ«r shembull Sync, Delay_Req, PDelay_Req etj.
messageLength â pĂ«rmban madhĂ«sinĂ« totale tĂ« mesazhit PTP, duke pĂ«rfshirĂ« header, body dhe suffix (por duke pĂ«rjashtuar byte-t e mbushjes).
domainNumber â pĂ«rcakton se cilit domainin PTP i pĂ«rket mesazhi.
Domeni â janĂ« disa orĂ« tĂ« ndryshme, tĂ« mbledhura nĂ« njĂ« grup logjik dhe tĂ« sinkronizuara nga njĂ« orĂ« kryesore, por nuk Ă«shtĂ« domosdoshmĂ«risht e sinkronizuar me orĂ«t qĂ« i pĂ«rkasin njĂ« domeni tjetĂ«r.
flamuj â ky fushĂ« pĂ«rmban flamuj tĂ« ndryshĂ«m pĂ«r identifikimin e statusit tĂ« mesazhit.
fushaKorrektimi â pĂ«rmban kohĂ«n e vonesĂ«s nĂ« nanosekonda. Koha e vonesĂ«s pĂ«rfshin vonesĂ«n gjatĂ« transmetimit pĂ«rmes orĂ«ve transparente, si dhe vonesĂ«n gjatĂ« transmetimit pĂ«rmes kanalit kur pĂ«rdoret moda Peer-to-Peer.
identitetiPortitBurim â ky fushĂ« pĂ«rmban informacion mbi portin nga i cili u dĂ«rgua fillimisht ky mesazh.
identifikimiSeancĂ«s â pĂ«rmban numrin identifikues pĂ«r mesazhet individuale.
fushaKontrolli â njĂ« fushĂ«-artifakt=) Ka mbetur nga versioni i parĂ« i standardit dhe pĂ«rmban informacione mbi tipin e kĂ«tij mesazhi. NĂ« thelb, Ă«shtĂ« e njĂ«jtĂ« me messageType, por me mĂ« pak opsione.
intervaliMesazhitLog â ky fushĂ« pĂ«rcaktohet nga tipi i mesazhit.
Body
Siç u diskutua më lart, ekzistojnë disa lloje mesazhesh. Këto lloje përshkruhen më poshtë:
Mesazhi Announce
Mesazhi Announce pĂ«rdoret pĂ«r tĂ« "njoftuar" orĂ«t e tjera brenda njĂ« domene pĂ«r parametrat e tij. Ky mesazh lejon vendosjen e njĂ« hierarkie "OrĂ«t Kryesore â OrĂ«t NĂ«nshkruese".

Mesazhi Sync
Mesazhi i sinkronizimit (Sync) dërgohet nga orët kryesore dhe përmban kohën e orëve kryesore në momentin kur mesazhi Sync është krijuar. Nëse orët kryesore janë me dy hapa, atëherë vula e kohës në mesazhin Sync do të barazohet me 0, dhe vula aktuale e kohës do të dërgohet në mesazhin e lidhjes Follow_Up. Mesazhi Sync përdoret për të dy mekanizmat e matjes së vonesës.
Mesazhi dërgohet përmes Multicast. Opsionalisht mund të përdoret Unicast.

Mesazhi Delay_Req
Formati i mesazhit Delay_Req është identik me mesazhin Sync. Orët nënshkruese dërgojnë Delay_Req. Ky mesazh përmban kohën e dërgimit të Delay_Req nga orët nënshkruese. Ky mesazh përdoret vetëm për mekanizmin e kërkesës-përgjigje të vonesës.
Mesazhi dërgohet përmes Multicast. Opsionalisht mund të përdoret Unicast.

Mesazhi Follow_Up
Mesazhi Follow_Up dërgohet opcionalisht nga orët kryesore dhe përmban kohën e dërgimit të mesazhit Sync nga master. Mesazhi Follow_Up dërgohet vetëm nga orët kryesore me dy hapa.
Mesazhi Follow_Up përdoret për të dy mekanizmat e matjes së vonesës.
Mesazhi dërgohet përmes Multicast. Opsionalisht mund të përdoret Unicast.

Mesazhi Delay_Resp
Mesazhi Delay_Resp dërgohet nga orët kryesore. Ai përmban kohën e pranimit të Delay_Req nga orët kryesore. Ky mesazh përdoret vetëm për mekanizmin e kërkesës-përgjigjes së vonesës.
Mesazhi dërgohet përmes 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 pajisje. Pdelay_Req përdoret vetëm për mekanizmin e matjes së vonesës për fqinjët.

Mesazhi Pdelay_Resp
Mesazhi Pdelay_Resp dërgohet nga pajisja që ka marrë kërkesën për vonesën. Ai përmban kohën e pranimit të mesazhit Pdelay_Req nga kjo pajisje. Mesazhet Pdelay_Resp përdoren vetëm për mekanizmin e matjes së vonesës për fqinjët.

Mesazhi Pdelay_Resp_Follow_Up
Mesazhi Pdelay_Resp_Follow_Up dërgohet opsionalisht nga pajisja që ka marrë kërkesën për vonesën. 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 kryesore dy-hapëshe.
Ky kjo mesazh mund të përdoret gjithashtu për kohën e ekzekutimit si alternativë ndaj vulës së kohës. Koha e ekzekutimit është koha nga momenti i marrjes së 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ë nyjës fqinje.

Mesazhet Shtyuese (Mesazhi i Menaxhimit)
Mesazhet Shtyuese PTP janë të nevojshme për të transferuar informacion midis një ose më shumë orëve dhe nyjës menaxhuese.

Transmetimi në LV
Mesazhi PTP mund të dërgohet në dy nivele:
- Niveli Rrjet â si pjesĂ« e tĂ« dhĂ«nave IP.
- Niveli Kanal â si pjesĂ« e kornizĂ«s Ethernet.
Transmetimi i mesazhit PTP përmes UDP përmes IP përmes Ethernet

PTP përmes UDP përmes Ethernet

Profile
PTP ka mjaft shumë parametra "flexibilë" që duhet të konfigurohen. Për shembull:
- Opsionet BMCA.
- Mekanizmi i matjes së vonesës.
- Intervalet dhe vlerat fillestare të të gjithë parametrave të konfigurueshëm etj.
Dhe ndonëse më parë thamë se pajisjet PTPv2 janë të pajtueshme me njëra-tjetrën, në të vërtetë nuk është kështu. Pajisjet duhet të kenë të njëjtat konfigurime për të bashkëvepruar.
Prandaj ekzistojnë profilet e njohura si PTPv2. Profillet janë grupe të cilësimeve të konfiguruara dhe kufizimeve të caktuara të protokollit për të realizuar sinkronizimin e kohës për një aplikacion të caktuar.
Standarti IEEE 1588v2 përshkruan vetëm një profil - "Default Profile". Të gjitha profillet 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 u krijua nga komiteti i Komunikimeve të Sistemëve të Energjisë dhe komiteti i Stacioneve Nënstacione të shoqatës IEEE Power and Energy Society. Profili vetë quhet IEEE C37.238-2011.
Profili përshkruan se PTP mund të transmetohet:
- Vetëm përmes rrjetesh L2 (pra, Ethernet, HSR, PRP, jo IP).
- Mesazhet transmetohen vetëm përmes dërgimit Multicast.
- Si mekanizëm për matjen e vonesës përdoret mekanizmi i matjes së vonesës së Palëve.
Domeni për parazgjedhje është 0, domeni i rekomanduar është 93.
Në filozofinë e krijimit të C37.238-2011 qëndronte 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 besueshëm midis pajisjeve dhe për të rritur stabilitetin e sistemit.
Po ashtu, është përcaktuar frekuenca e dërgimit të mesazheve:

NĂ« thelb, pĂ«r shfrazimin Ă«shtĂ« nĂ« dispozitĂ« vetĂ«m njĂ« parameter â tipi i orĂ«ve drejtues (me njĂ« tĂ« shkallĂ« ose me dy shkallĂ«).
SaktĂ«sia duhet tĂ« jetĂ« jo mĂ« shumĂ« se 1 ÎŒs. PĂ«r tjetĂ«r fjalĂ«, nĂ« njĂ« rrugĂ« sinchronizimi mund tĂ« pĂ«rmbahen maksimumi 15 orĂ« transparente ose tri orĂ« kufij.

Burimi: habr.com
