DSPLabs Technical Reportdsplabs.cs.upt.ro/grants/melissevs/pdfs/DSPL-TR.2009.3.pdf · Digital...

Digital Signal Processing Laboratories in Timisoara

Department of Computer and Software Engineering POLITEHNICA University of Timisoara 2, Vasile Parvan Blvd., 300223 – Timisoara, Romania Tel: + 40 256 403271, Fax: + 40 256 403214 Http://dsplabs.cs.upt.ro/

DSPLabs

Technical Report

DSPL-TR.2009.3 Title Modelarea mecanismelor de sincronizare in retele de

senzori si sisteme distribuite Authors Bogdan Stratulat, Mihai V. Micea, Sebastian Birzeianu

Language Romanian

Project ID MELISSEVS

Project Title Model for rEpresentation of coLlaborative robotic and Intelligent Sensor Systems in EnVironment exploration and Supervision applications

Project Type Grant PNCDI II - "IDEAS" Program, Code "ID-22"

Activity ID 1.3

Year 2009



2 DSPLabs Technical Report, DSPL-TR.2009.3

Cuprins

1 Introducere 3

2 Parametri si constrangeri specifice sincronizarii 4

3 Protocolul PTP 7

4 Mecanisme de sincronizare cu caracter static 11

5 Mecanisme de sincronizare cu caracter dinamic 22

6 Concluzii 29

Referinte bibliografice 30



DSPLabs Technical Report, DSPL-TR.2009.3 3

1 Introducere

Progresele tehnologice recente in domeniul proiectarii dispozitivelor miniaturizate, de cost scazut si putere redusa, constituie un mediu activ pentru cercetarea retelelor de senzori de dimensiuni mici, conectate fara fir, si cu cerinte de consum de putere foarte mic. Sincronizarea in timp a retelelor de senzori este un factor critic pentru diverse obiective cum sunt fuziunea datelor, executia coordonata sau gestionarea responsabilitatilor intr-o maniera eficienta si optima din punctul de vedere al consumului. Constrangerile referitoare la acuratetea si precizia sincronizarii ceasurilor sunt mai stricte decat in alte sisteme distribuite traditionale, si sunt amplificate si de limitarile de consum de energie impuse resurselor disponibile. Mecanismele de sincronizare se refera la coordonarea elementelor unui sistem pentru ca acesta sa poata functiona la unison. Sistemele care opereaza cu toate componentele sincronizate se numesc sisteme sincrone. Unele sisteme pot fi doar partial sincronizate, sau plesiocrone. In unele aplicatii trebuie determinate echilibrari relative intre evenimente, in altele conteaza doar ordinea evenimentelor. Cercetarea abordata in cadrul acestui proiect s-a preocupat de studierea mecanismelor de sincronizare in retele de senzori si sisteme distribuite. Scopul cercetarii a fost de a propune, testa si modela mecanismele de sincronizare folosind sistemul MELISSEVS. In acest sens, s-a realizat un studiu al celor mai potrivite protocoale de sincronizare pentru sistemul dat si s-a hotarat utilizarea protocolului Precision Time Protocol (PTP), datorita performantelor superioare ale acestuia in ceea ce priveste acuratetea sincronizarii. Totodata, s-a propus realizarea un nou protocol pornind de la structura de baza a protocolului de sincronizare anterior amintit. Implementarea protocolului de sincronizare PTP in mediul de simulare utilizat a impus abordarea a doua variante de realizare a sincronizarii retelei multihop pe care s-a realizat simularea: boundary clock si transparent clock. Simularile s-au realizat considerand reteaua statica, adica nodurile si topologia retelei au ramas constante de-a lungul simularilor. Informatiile obtinute in urma simularilor si evaluarii rezultatelor s-au concretizat prin reprezentari grafice, din care s-au observat performante superioare in cazul primei abordari de implementare. Cu toate acestea, decizia finala trebuie evaluata in urma unor masuratori efectuate in conditii reale de functionare a protocolului pe o perioada mai mare de timp. S-a realizat si o propunere pentru un protocol PTP modificat, astfel incat noul protocol de sincronizare sa fie adecvat in conditii de retele dinamice, adica atunci cand nodurile sunt mobile si/sau pot sa dispara, respectiv sa apara in retea din diferite motive.




2 Parametri si constrangeri specifice sincronizarii

Sincronizarea ceasurilor interne ale sistemelor de calcul si a dispozitivelor digitale este o problema ce deriva din posibilitatea ca ceasurile interne a diferitelor elemente componente au o tendinta de a devia, chiar daca initial sunt setate corespunzator. Pot aparea o multitudine de probleme din caza acestor diferente dar exista diverse solutii, care pot fi mai mult sau mai putin potrivite in functie de context. Sincronizarea este necesara atunci cand dispozitive care lucreaza la distanta trebuie sa se coordoneze. In astfel de situatii, un ceas central sincronizeaza ceasurile dispozitivelor conectate in retea. Cu toate acestea, nu exista garantii ca doua ceasuri setate vor ramane sincronizate, din cauza diferentelor de temperatura, a varstei si a uzurii. Din acest motiv procesul de sincronizare trebuie sa fie continuu. Sincronizarea precisa constituie un factor important si in domenii cum sunt telecomunicatiile, automatizari industriale, testare, control de roboti. Un ceas este un dispozitiv obtinut prin folosirea unui oscilator si a unui numarator. Oscilatorul poate fi orice dispozitiv fizic, adica un pendul sau un cristal de cuart, sau poate sa fie un semnal electromagnetic. Un ceas atomic, de exemplu, foloseste o oscilatie asociata cu o tranzitie cuantica intre doua niveluri energetice dintr-un atom. Numaratorul este responsabil de contorizarea numarului de oscilatii care au avut loc. Dupa setarea initiala, ceasul poate sa furnizeze o estimare a timpului corect prin adunarea numarului de oscilatii, numite si cicluri de clock. In principiu, daca un ceas a fost setat perfect iar frecventa sa (adica a oscilatorului) ramane ideala, timpul s-ar masura corect pe o perioada nedeterminata, infinita. Exista suficienti factori perturbatori care vor impiedica insa o asemenea functionare (temperatura, presiunea, vibratii, perturbatii sau intarzieri ale semnalelor). Calitatea unui ceas depinde de modul de setare, de acuratetea si stabilitatea frecventei si de gradul de imunitate pe care il prezinta ceasul fata de schimbarile din mediul in care se afla. Un algoritm se spune ca este de tip nedeterminist atunci cand dintr-un anumit punct de decizie exista mai multe variante de continuare a procesului, fara sa existe nici o specificatie legata de calea aleasa. Principalul factor care influenteaza in mod distructiv precizia sincronizarii unei retele este nondeterminismul. Latenta este diferenta de timp dintre momentul initierii unei actiuni si momentul in care efectul actiunii devine sau incepe sa devina observabil. Estimari ale latentei sunt descentrate de evenimente aleatoare care produc transferuri de mesaje dus-intors asimetrice cu intarzieri haotice, ceea ce provoaca implicit erori de sincronizare. Sursele latentei unui mesaj pot fi vazute ca avand urmatoarele componente distincte:




Send Time – timpul necesar asamblarii mesajului si realizarii cererii de trimitere catre nivelul MAC al transmitatorului. In functie de incarcarea sistemului cu apeluri sistem si de sarcinile curente ale procesorului, timpul de transmisie este nedeterminist si poate ajunge la valori de sute de milisecunde;

Access Time – intarzierea aparuta intre momentul asteptarii necesare pentru a primi acces la canalul de transmisie si momentul efectiv al inceperii transmisiei. Timpul de acces este componenta transmisiei cu cel mai redus caracter determinist in retelele wireless de senzori, variind intre cateva milisecunde si cateva secunde in functie de traficul si incarcarea retelei;

Transmission Time – timpul necesar transmitatorului pentru a transmite mesajul. Ordinul acestui timp este de zeci de milisecunde, depinzand de lungimea pachetului transmis si de viteza retelei;

Propagation Time – reprezinta timpul necesar pentru ca mesajul sa ajunga de la transmitator la receptor, fiind masurat de la momentul in care pachetul a parasit nodul transmitator. In retelele wireless de senzori timpul de propagare este foarte determinist si depinde de distanta dintre cele doua noduri. Pentru distante mai mici de 300 m timpul de propagare este mai putin de o microsecunda;

Reception Time – timpul de care este nevoie pentru ca nodul receptor sa receptioneze mesajul. Este identic cu timpul de transmisie, iar suprapunerea acestor doi timpi se poate observa in Fig. 1;

Receive Time – timpul necesar procesarii unui mesaj sosit si pentru a anunta nivelul aplicatie al nodului receptor. Are caracteristici similare cu timpul de transmisie.

Fig. 1. Suprapunerea timpilor la tranzactia de mesaje (sursa: [1]).

Constrangerile de timp specifice pentru o serie de aplicatii [2], sunt prezentate in Tab. 1.




Tab. 1. Acuratetea sincronizarii pentru diverse domenii de aplicatii.

Exista o serie de algoritmi consacrati pentru sincronizarea retelelor de senzori si sisteme distribuite, cu diverse caracteristici specifice si diferite performante in ceea ce priveste acuratetea sincronizarii. Protocolul Precision Time Protocol, specificat de standardul IEEE 1588 este descris in continuare mai pe larg, fiind prezentate in detaliu pachetele de sincronizare utilizate si metodele de calcul a parametrilor care vor permite sincronizarea retelei care il utilizeaza. Acest lucru se datoreaza faptului ca in urma studiului facut, acest protocol a fost ales pentru implementare si testare, datorita performantelor superioare pe care le prezinta din punct de vedere al sistemului MELISSEVS . De asemenea, pornind de la acest protocol, s-a dezvoltat un nou protocol de sincronizare, conceput in mod special pentru platforma MELLISSEVS cu caracteristici dinamice.




3 Protocolul PTP

Standardul pentru sincronizare IEEE 1588 a fost creat in anul 2002. PTP este un protocol bazat pe transfer de timp, definit de standardul IEEE 1588-2002, care permite sincronizarea precisa a retelelor. Daca se folosesc etichete de timp generate prin hardware, acuratetea obtinuta poate ajunge la nivelul nanosecundelor. Protocolul PTP presupune prezenta unui nod master (ce apare si in arhitectura sistemului MELISSEVS sub denumirea de BRAIN). care va furniza ceasul de referinta. Nodurile slave (ce sunt denumite WIT in sistemul MELISSEVS), vor fi sincronizate fata de ceasul de referinta al master-ului. Sincronizarea in timp intre nodul master si nodurile slave se realizeaza prin schimb de mesaje. Master-ul isi inregistreaza valoarea timpului propriu, si incapsuleaza informatia intr-un pachet. Folosind frecvente radio, master-ul va face o transmisie broadcast catre nodurile slave din retea. Acestea, la primirea mesajului de sincronizare de la master, isi vor sincroniza propriile ceasuri in functie de valoarea obtinuta de la master. Din acest punct de vedere, exista doua metode de sincronizare a ceasurilor – logic sau fizic. Metoda sincronizarii logice foloseste un numarator pentru ajustarea ceasului local, in timp ce metodele fizice presupun accelerarea sau incetinirea oscilatorului local. Pentru realizarea sincronizarii protocolul PTP opereaza prin schimburi de mesaje. Exista patru tipuri de mesaje transferate in cadrul procedeului de sincronizare:

SYNC – nodul master efectueaza periodic o transmisie de tip broadcast cu mesajul SYNC. Nodurile slave ataseaza o eticheta de timp acestui mesaj, continand timpul receptionarii. Aceasta valoare va fi utilizata de nodurile slave pentru corectia ceasurilor proprii, impreuna cu valoarea care este inserata in mesajul FOLLOW UP, imediat urmator;

FOLLOW UP – aceste mesaje sunt transmise de la master catre slave, si includ eticheta de timp a mesajului SYNC transmis anterior de catre master, cele doua valori obtinute de nodurile slave in urma acestor doua mesaje permitand calcularea unui prim offset intre ceasul local si cel al master-ului;

DELAY REQUEST – un nod slave va transmite un astfel de mesaj pentru a calcula intarzierea propagarii mesajelor intre sine si nodul master;

DELAY RESPONSE – acest mesaj este transmis de la master catre slave si va include eticheta de timp la care a fost primit mesaju DELAY REQUEST.

Sincronizarea intr-o retea, folosind protocolul PTP se va desfasura conform diagramei din Fig. 2.




Fig. 2. Schimbul de mesaje intre master si slave in protocolul PTP (sursa: [3]).

Un schimb de mesaje va incepe cu un mesaj SYNC transmis in regim de broadcast tuturor nodurilor din retea. Un nod slave va inregistra in T1 timpul exact al receptionarii mesajului SYNC, conform cu ceasul propriu. In continuare master-ul va trimite din nou in regim de broadcast un mesaj FOLLOW UP, care va contine timpul exact la care a transmis mesajul SYNC anterior, conform cu ceasul sau. Nodul slave va inregistra aceasta eticheta de timp in T0. In acest moment toate nodurile slave care au primit mesajele cunosc valorile T0 si T1. Daca notam intarzierea propagarii mesajelor cu D (delay) si decalajul intre ceasul master-ului respectiv al slave-ului cu O (offset), observam urmatoarea relatie: T1 − T0 = D + O = A In continuare, fiecare nod slave va transmite un mesaj DELAY REQUEST inapoi catre master. Nodul slave va masura timpul exact al transmisiei acestui mesaj, conform ceasului propriu, valoarea fiind pastrata in T2. La receptionarea acestui mesaj, nodul master va retine momentul receptionarii conform ceasului propriu si se va obtine valoarea T3, iar apoi va transmite nodului slave corespunzator un mesaj DELAY RESPONSE care va contine aceasta eticheta de timp. In acest moment avem valabila urmatoarea relatie: T3 - T2 = D – O = B Este de remarcat faptul ca la estimarea timpului de intarziere datorat propagarii mesajelor in retea, se presupune ca aceasta este simetrica, adica valoarea intarzierii la transmisia de la master spre slave este egala cu valoarea intarzierii la transmisia de la slave la master.




In acest moment, cunoscand valorile celor patru timpi de interes T0 ,T1 ,T2 ,T3, sau mai simplu, folosind notatiile impuse A si B, se pot obtine valorile necesare sincronizarii cu urmatoarele relatii: D = (A + B) / 2

O = (A − B) / 2 O sincronizare eficienta impune alegerea pentru functia de master a nodului cu cel mai precis ceas, de cea mai inalta calitate. La o eventuala eliminare a acestui nod din retea, este necesara determinarea unui nou master, conform acelorasi criterii. De asemenea, eficienta sincronizarii poate creste prin transmisia unui numar mare de mesaje SYNC si FOLLOW UP de la master la nodurile slave, si ajustarea de fiecare data a decalajului, conform valorii din A, iar dupa un anumit numar de astfel de schimburi de mesaje si ajustari corespunzatoare se trece la transmisia mesajelor DELAY REQUEST si DELAY RESPONSE, pentru determinarea valorii intarzierii propagarii, si sincronizarea ceasurilor. Protocolul PTP, conform standardului IEEE 1588-2002 [2] − [4] (respectiv IEEE 1588-2008, versiunea a doua) reprezinta cel mai precis protocol de sincronizare in timp a retelelor in prezent, avand o acuratete de sub 1 microsecunda (chiar de nivelul nanosecundelor pentru etichete de timp atasate la nivelul fizic al dispozitivelor conectate). Pentru obtinerea unor performante foarte bune in sincronizare pentru sisteme cu constrangeri de timp, se impune ca fiecare nod participant sa contina un ceas local, care sa permita sincronizarea conform IEEE 1588. O versiune succesoare, IEEE 1588 Version 2, a fost aprobata in martie 2008, cu urmatoarele modificari:

Ceasuri cu transparentta pentru retelele 1588, pentru imbunatatirea acuratetii

Mesaje de sincronizare cu dimensiuni mai mici

Suport din partea protocolului pentru precizie imbunatatita

Optiune pentru transport pe nivelul 2

Optiune pentru transport unicast

Suport pentru toleranta la defecte

Reconfigurare rapida ca raspuns la modificari in retea

Rate de actualizare variate (mai rapide) Aceasta versiune noua a standardului nu este interoperabila in mod direct cu versiunea anterioara. Tabelul urmator prezinta o comparatie intre diferiti algoritmi de sincronizare prezentati, comparatie realizata din perspectiva preciziei sincronizarii. Protocolul




selectat pentru simulare si testare este Precision Time Protocol, datorita acuratetii superioare a acestuia.

Tab. 2. Acuratetea diferitelor mecanisme de sincronizare.

Protocol de sincronizare Acuratetea obtinuta Network Time Protocol < 1 ms

Reference broadcast synchronization < 100 μs Timing-sync Protocol for Sensor Networks < 100 μs Flooding Time Synchronization Protocol < 10 μs

Precision Time Protocol IEEE 1588 < 1 μs




4 Mecanisme de sincronizare cu caracter static

Intr-o prima faza s-a realizat simularea mecanismelor de sincronizare in retele de senzori si sisteme distribuite folosind aplicatia OMNeT++ (simulator orientat pe obiecte utilizat pentru urmarirea evenimentelor intr-o retea) si aplicatia X Simulator. OMNeT++ [5] permite modelarea traficului de retele de telecomunicatii, a diverselor protocoale, a retelelor de tip coada, a multiprocesoarelor sau altor sisteme hardware distribuite, validarea de arhitecturi hardware, evaluarea de aspectelor referitoare la performante a sistemelor software complexe. Sistemul este compus dintr-un nucleu de simulare, o librarie scrisa si compilata in C++ si interfata cu utilizatorul. OMNeT++ este o aplicatie portabila pe sisteme Windows si pe diferite platforme Unix. X Simulator [6] poate sa reproduca surse tipice de nesiguranta care pot afecta functionarea corecta a protocoalelor de sincronizare intr-o retea. Acest simulator difera de abordarea tipica a analizei protocoalelor de sincronizare prin faptul ca nu are o implementare detaliata a stivei unui protocol. Comportamentul nodurilor sau al switch-urilor este implementat pe baza unor modele statistice si de flux. Aceasta abordare permite concentrarea pe aspecte fundamentale ale analizei si poate fi de folos pentru aprecierea unui protocol de sincronizare in raport cu arhitectura retelei si a conditiilor de operare, precum si pentru optimizarea algoritmului "clock servo". Pornind de la modulele si submodulele oferite de aplicatia X Simulator, s-au dezvoltat simulari mai precise, cu scopul de a permite observarea functionarii protocolului Precision Time Protocol. Pentru a studia comportarea protocolului de sincronizare Precision Time Protocol pe o retea de noduri reprezentativa pentru sistemul MELISSEVS, a fost necesara implementarea unei topologii specifice, cu o structura concreta si, de asemenea, cu un grad mai ridicat de complexitate in comparatie cu topologia abstractizata oferita implicit de aplicatia X Simulator. Implementarea simularii protocolului de sincronizare PTP are in aceasta faza un caracter static. Reteaua pentru care se realizeaza simularea se considera fixa, statica. Nu vor interveni modificari in ceea ce priveste topologia existenta. De asemenea, nodurile prezente in retea raman fixate pe tot parcursul simularii, atat in ceea ce priveste pozitia acestora, cat si din punct de vedere al rolului de slave si/sau master, relativ la celelalte noduri ale retelei. Implementarea protocolului pleaca de la structurile oferite de aplicatia de baza si urmareste transmisia intre nodurile master si slave, a mesajelor de tipul SYNC, DELAY REQUEST si DELAY RESPONSE. Asa cum s-a specificat deja, pachetele de tip FOLLOW UP nu au fost implementate deoarece valorile de timp oferite prin functionalitatea lor se pot obtine in mod direct




in cadrul mediului de simulare utilizat. Reteaua implementata pentru acest studiu este descrisa in Fig. 3.

Fig. 3. Topologia retelei implementate pentru studiul sincronizarii statice.

Se observa o topologie mai complexa, de tip arbore. Structura implementata se apropie mult de caracteristicile unei retele reale, reconstituind o posibila varianta de topologie pentru sistemul MELISSEVS. Nivelele arborelui care constituie reteaua se identifica cu distantele relative ale grupurilor de noduri fata de master-ul principal (BRAIN) si respectiv fata de alte noduri din retea (WIT). Nodurile aflate pe primul nivel sunt cele mai apropiate de BRAIN, ceea ce va permite comunicarea directa cu acesta. Nodurile de pe nivelul doi se afla la o distanta prea mare pentru a reusi transferul de pachete cu master-ul principal; ele isi vor gasi un master in cel mai apropiat nod de pe nivelul unu. In mod similar se prezinta restul nivelelor de noduri, cele mai indepartate se vor afla pe ultimul nivel si nu vor intermedia comunicare pentru alte noduri. Cu noua implementare, este posibila urmarirea traficului de pachete de sincronizare specifice protocolului PTP si evolutia valorilor de timpi pentru fiecare nod. Un




aspect hotarator pentru simularea protocolului de sincronizare in conditiile oferite de topologia implementata il reprezinta stratificarea pe nivele a nodurilor, care impune trafic de tip multi-hop si extinderea functionalitatii de master la mai multe noduri, avand in vedere ca in acest caz nodurile nu mai pot comunica direct cu master-ul principal. Utilizand aceasta noua topologie, s-a impus testarea a doua variante de implementare a protocolului PTP pentru retele cu mai multe noduri master, cu noduri cu functionalitati totodata de master si de slave:

"Boundary Clock"

"Transparent Clock" Sincronizarea unei retele folosind Precision Time Protocol cu metoda "Boundary Clock" presupune definirea nodurilor astfel incat sa fie permisa implementarea functionalitatii de master acolo unde este cazul. Un nod frunza va ramane un nod simplu, "ordinary clock". Master-ul principal va incepe transmisia de pachete de sincronizare, trimitand in regim de broadcast pachete de tip SYNC. Doar nodurile care sunt slave directi pentru nodul master vor interpreta aceste pachete, conform descrierii standardului PTP. Astfel, nodurile slave directe pentru nodul master principal se sincronizeaza cu acesta. In continuare, fiecare slave direct va juca rol de master pentru nodurile conectate la ele, daca exista astfel de noduri. Un astfel de slave va incepe sa genereze pachete proprii de sincronizare, conform cu un timer local, si le va transmite nodurilor sale de tip slave. Procesul se efectueaza pe fiecare nivel din retea. Un nod frunza nu va avea nici un nod conectat, deci nu va avea si functionasitati de nod master. Cu aceasta abordare, se evita intarzierile interne care pot sa apara intr-un nod care, dupa ce a primit un pachet de sincronizare, doreste sa il propage mai departe in retea. In acelasi timp, se remarca faptul ca folosind aceasta abordare, fiecare nod se va sincroniza doar cu propriul sau master, care la randul sau se sincronizeaza cu master-ul corespunzator. Sincronizearea retelei ca un intreg se realizeaza sub forma de cascada, incepand cu master-ul principal, in cazul nostru nodul BRAIN, pana la nodurile aflate pe ultimele nivele (Fig. 4). Metoda de sincronizare cu Transparent Clock [7], implementata pentru protocolul PTP, presupune de asemenea definirea nodurilor astfel incat sa fie permisa implementarea functionalitatii de master acolo unde este cazul, iar un nod frunza va ramane un nod simplu, "ordinary clock". Master-ul principal va incepe transmisia de pachete de sincronizare, trimitand in regim de broadcast pachete de tip SYNC. Doar nodurile care sunt slave directi pentru nodul master vor interpreta aceste pachete, conform descrierii standardului PTP. Astfel, slave-ii directi ai nodului master principal se sincronizeaza cu acesta. Se observa ca pana in acest moment nu exista diferente fata de implementarea folosind "boundary clock", astfel ca pentru nodurile de pe primul nivel valorile timpilor de sincronizare care intervin in protocolul PTP se pastreaza aproximativ la




fel indiferent de abordarea folosita. Acest lucru se va reflecta si in reprezentarile grafice obtinute in urma rularii simularilor si a inregistrarii valorilor obtinute. In continuare, nodurile aflate pe primul nivel, pastrandu-si rolul de master pentru nodurile de pe nivelul urmator conectate la ele, se vor comporta diferit fata de metoda care foloseste "boundary clock". In cazul abordarii cu "transparent clock", nodurile isi vor ajusta timpii conform cu valorile obtinute prin pachetele SYNC, dupa care vor retransmite pahcetul SYNC catre slave-ii conectati. In acest fel, toate nodurile de pe fiecare nivel vor primi acelasi pachet SYNC transmis de catre BRAIN, intreaga retea fiind sincronizata conform cu ceasul master-ului principal (Fig. 5).

Fig. 4. PTP cu "boundary clock".

Fig. 5. PTP cu "transparent clock".




"Boundary clock" si "transparent clock" sunt abordari de implementare a protocolului PTP prin care se specifica felul in care se propaga pachetele de tip SYNC si FOLLOW UP de la un master la salve-ii corespunzatori, sau de la master-ul principal catre toate nodurile din retea. In ceea ce priveste pachetele de tip DELAY REQUEST si DELAY RESPONSE nu exista diferente. Aceste tipuri de pachete vor circula doar intre un nod slave si master-ul direct, caz in care nu se pune problema retransmisiei sau a propagarii. Cu toate acestea, valorile obtinute pentru intarzierile de transmisie din retea vor fi diferite, calculul decalajului oferind valori diferite in functie de cele doua abordari. Studierea protocolului PTP prin cele doua metode descrise mai sus a impus realizarea a doua simulari folosind topologia descrisa mai sus. Pentru a permite extinderea vectorului de noduri slave, a fost necesara permiterea conectarii unui numar nelimitat (in principiu) de conexiuni ale unui nod. Astfel, s-au inclus in modulul de nod slave un multiplexor, pentru a permite n intrari, si un demultiplexor, pentru a permite n iesiri. Pentru toate nodurile, conexiunea cu numarul de ordine zero este cea cu masterul corespunzator nodului in care ne aflam. Conexiunile de pe pozitiile 1 si 2 sunt cele pentru sursa respectiv sink, cu toate ca nodurile nu comunica direct cu aceste module. Motivul existentei acestor conexiuni este de a pastra uniformitatea in toate nodurile, in conditiile in care demultiplexorul din modulul switch avea aceste conexiuni implementate in mod necesar conform aplicatiei sursa. In continuare, conexiunile 3, 4, etc sunt cele care permit legaturile dintre fiecare master si nodurile slave corespunzatoare acestuia. Pe ultimele pozitii sunt conexiunile dintre modulele slave aflate pe acelasi nivel, conexiuni cu rol demonstrativ (este vorba de o retea wireless), deoarece conform protocolului de sincronizare Precision Time Protocol, nodurile slave de pe acelasi nivel nu efectueaza transfer cu nici un fel de mesaje de sincronizare. Structura obtinuta pentru noul modul slave este descrisa in Fig. 6. Implementarea noului modul slave a permis realizarea retelei conform topologiei dorite. Fig. 7 reprezinta reteaua utilizata pentru simulari, fiind corespunzatoare celei din Fig. 3, prezentata mai sus. Se observa si transmisia unui pachet SYNC: Se observa in figura nodul master principal (brain-ul) in coltul stanga-sus, impreuna cu switch-ul care ii corespunde acestuia. In continuare sunt reprezentate nodurile retelei, purtand numele generic de salve, impreuna cu un identificator, cu toate ca in afara de nodurile de pe ultimul nivel, ele au si rol de master pentru nodurile descendente. Pastrand topologia de tip arbore descrisa anterior, se poate observa dispunerea pe nivele a nodurilor astfel:




Fig. 6. Structura implementata pentru modulul slave.

Nivelul 1 – nodurile: slave0, slave1, slave2 si slave3

Nivelul 2 – nodurile: slave4, slave5 (master slave0) slave6, slave7, slave8 (master slave1) slave10, slave11, slave12, slave13, slave14 (master slave2)

Nivelul 3 – nodurile: slave9, slave15, slave16 (master slave7) slave17, slave18, slave19 (master slave11)

Nivelul 4 – nodurile: slave20, slave21, slave22 (master slave15) slave23, slave24, slave25 (master slave 18)

S-au pastrat si modulele source si sink din motive de compatibilitate cu aplicatia sursa si pentru a pastra simularea in conditii generale.




Fig. 7. Reteaua implementata in simulator.

In urma implementarii celor doua simulari, a urmat testarea functionarii protocolului PTP prin cele doua metode de abordare, in conditiile date de simulator si pe topologia creata. In acest sens s-a efectuat rularea simularilor pentru un numar de 500 de actualizari prin pachete de sincronizare, in care s-au observat valorile timp obtinute pentru patru parametri urmariti: intarzierea (delay-ul) obtinuta pentru metoda "boundary clock", respectiv decalajul (offset-ul) obtinut pentru metoda "boundary clock", precum si aceiasi doi parametri pentru cazul utilizarii metodei "transparent clock". Valorile timpilor in simulare s-au obtinut in milisecunde, cu o precizie de 5 zecimale. Rezultatele simularilor au fost centralizate in fisiere corespunzatoare fiecarui nod in parte. In continuare s-a determinat o valoare medie pentru fiecare din cele patru valori observate, pentru fiecare nod in parte. In urma centralizarii acestor valori medii pentru toate nodurile din reteaua implementata, a urmat crearea unor grafice care sa permita observarea evolutiei valorilor. In acest sens s-a realizat in primul rand compararea valorilor obtinute pentru intarzieri (delay) intre metodele "boundary clock" si "transparent clock" (Fig. 8), urmata de o comparare a valorilor decalajului (offset) intre cele doua metode de abordare a sincronizarii (Fig. 9). Pentru o evaluare a rezultatelor care sa fie cat mai concludenta, au fost realizate doua seturi de astfel de comparatii. In prima evaluare s-a urmarit compararea prin reprezentarea valorilor medii ale parametrilor urmariti pentru fiecare nod in parte. A




doua abordare a fost calcularea unor valori medii corespunzatoare fiecarui nivel din arborele care a structurat topologia implementata. Aceasta abordare din urma a permis evaluarea valorilor bazata pe distantele dintre noduri si master-ul principal, ceea ce se poate dovedi foarte util in perspectiva incadrarii protocolului de sincronizare PTP in cadrul sistemului MELISSEVS, avand in vedere ca in reteaua de senzori propusa in acest proiect majoritatea senzorilor se vor afla cel mai probabil pe nivele de ordinul 3 sau 4 fata de BRAIN.

Fig. 8. Reprezentare grafica a valorilor medii ale delay-ului obtinut pentru fiecare nod in

parte.

Fig. 9. Reprezentare grafica a valorilor medii ale offset-ului obtinut pentru fiecare nod in

parte.




Fig. 9 reprezinta graficul obtinut in urma evaluarii valorilor medii ale offset-ului pentru toate cele 26 de noduri ale retelei implementate, avand in vedere metoda "bonudary clock", respectiv metoda "transparent clock". S-au pastrat aceleasi culori, pentru consecventa si pentru a putea urmari rezultatele obtinute in concordanta cu cele reprezentate anterior pentru valorile delay-ului. Se remarca faptul ca pentru cele patru noduri aflate pe nivelul unu al arborelui retelei nu exista diferente intre valorile obtinute. Se observa ca, in cazul ambelor metode de abordare, valorile pentru offset coboara la valori mai mici de 1 ns. De asemenea, din aceasta evaluare rezulta valori mai bune in cazul sincronizarii prin "boundary clock", insa de data aceasta diferentele sunt mult mai mici decat in cazul delay-ului. Se aminteste ca pentru a calcula offset-ul sunt utilizate valorile obtinute cu ajutorul mesajelor SYNC si a valorilor obtinute in mod direct in simulator, care in realitate sunt corespunzatoare pachetelor FOLLOW UP. De asemenea, este de remarcat ca aceste valori in realitate sunt influentate atat de distanta fizica directa dintre fiecare nod in parte si master-ul sau direct, cat si de nivelul pe care se afla nodul slave fata de master-ul principal, cu precadere in cazul metodei de abordare prin "transparent clock". S-a dovedit interesanta evaluarea valorilor medii calculate pentru nivelele corespunzatoare arborelui retelei, avand in vedere ca in mediile colaborative propuse in acest proiect majoritatea senzorilor se vor afla cel mai probabil pe nivele de ordinul 3 sau 4 fata de BRAIN, posibil chiar pe nivele si mai indepartate. In continuare sunt prezentate cateva grafice obtinute in urma evaluarilor acestor valori. In acest sens s-au realizat calculele pentru cele patru nivele prezente in topologia implementata. Primele doua evaluari prezentate mai sus, care au luat in calcul valorile medii ale fiecarui nod in parte, au obtinut rezultate mai bune pentru metoda de sincronizare prin "boundary clock" decat pentru cea prin "transparent clock", dar o evaluare pe nivele era necesara pentru a intari aceste concluzii partiale. Reprezentarea grafica din Fig. 10 ofera o comparatie intre valorile medii ale delay-ului pentru ambele metode de abordare a sincronizarii, pe fiecare din cele patru nivele ale retelei implementate. Se remarca faptul ca valorile medii ale delay-ului obtinut prin metoda "boundary clock" raman relativ constante pe masura ce se inainteaza pe nivele, in timp ce pentru metoda "transparent clock" valoarea medie pe nivel tinde sa creasca odata cu departarea fata de nodul master principal. Cu toate acestea, pentru a determina cu certitudine ca metoda de sincronizare prin boundary clock este mai performanta decat cea care utilizeaza transparent clock, s-a impus si o ultima comparatie intre cele doua abordari ale protocolului PTP, evaluarea valorilor medii ale offset-ului obtinute pe fiecare nivel in parte. In Fig. 11 se pot urmari reprezentarile grafice ale valorilor medii ale offset-ului obtinute in urma simularilor pentru fiecare nivel al arborelui corespunzator topologiei implementate. Se poate observa faptul ca nodurile aflate pe primul nivel al




arborelui nu au diferente intre valorile obtinute, ceea ce era rezultatul normal asteptat luand in considerare toate evaluarile precedente. Rezultatele obtinute in continuare pe fiecare nivel in parte, arata valori mai bune obtinute pentru metoda de sincronizare care utilizeaza "boundary clock". Valorile medii rezultate pentru metoda transparent clock au din nou tendinta de a creste pe masura ce ne deplasam pe nivele, in timp ce valorile obtinute pentru boundarz clock pastreaza valori relativ apropiate. Diferentele intre valorile medii ale timpilor obtinute sunt din nou mai mici decat in cazul celor corespunzatoare delay-ului.

Fig. 10. Reprezentare grafica a valorilor medii ale delay-ului obtinut pentru fiecare nivel in

parte.

Fig. 11. Reprezentare grafica a valorilor medii ale offset-ului obtinut pentru fiecare nivel in

parte.




De remarcat pentru toate reprezentarile grafice de mai sus faptul ca valorile reprezentate sunt intotdeauna valori medii, fie ele pe nivele sau pe noduri. In acest sens, este important sa nu se creeze impresia ca valorile pentru offset sau delay ar putea creste in loc sa scada. Valoarea offset-ului atinge intotdeauna valoarea zero, moment in care practic sincronizarea este realizata cu precizie zero si delay-ul ajunge sa aiba o valoare constanta. In realitate, desigur, o asemenea situatie este foarte putin probabila, simulatorul functionand in conditii idealizate. In urma evaluarilor celor patru parametri considerati (evaluarile realizate atat pentru fiecare nod al retelei in parte cat si dintr-o perspectiva de ansamblu prin evaluarea pe nivele ale structurii de arbore corespunzatoare topologiei implementate pentru simulari) se poate observa ca metoda de sincronizare prin protocolul Precision Time Protocol pentru retele dispuse pe mai multe nivele este mai eficienta prin implementarea abordarii cu "Boundary Clock" decat prin implementarea abordarii cu "Transparent Clock", in conditiile simularii sistemului MELISSEVS. Pentru a obtine rezultate mai concludente insa, in perspectiva utilizarii protocolului de sincronizare in cadrul mediului real propus de sistemul MELISSEVS, se impune o evaluare a ambelor abordari, folosind o implementare concreta a retelei si a protocolului, pentru a expune nodurile si reteaua la conditii reale de functionare, evitand caracteristicile idealizate ale mediului de simulare. Un prim factor care ar putea face diferenta, in afara de posibile zgomote, erori de transmisie sau erori la nivel hardware, poate fi distanta intre noduri, in special pentru retele de senzori foarte mari, cu un numar mare de noduri extinse pe o suprafata mare. Un alt aspect foarte important, neluat in considerare in simularile realizate pana in acest moment, este caracterul dinamic al retelelor modelate prin mediile colaborative din cadrul sistemului MELISSEVS. Este foarte important in acest sens sa se ia in calcul deplasarea nodurilor in retea sau erorile care pot aparea, ambele putand determina aparitia sau disparitia unor noduri in retea, fapte care pot determina consecinte hotaratoare asupra structurii retelei si implicit, vor afecta functionarea protocolului de sincronizare implementat.




5 Mecanisme de sincronizare cu caracter dinamic

Caracterul dinamic al unei retele se reflecta prin posibilitatea aparitiei unor modificari in structura acesteia in intervale relativ scurte de timp. Modificarile pot sa fie cauzate de schimbari in topologia retelei in urma deplasarii unora dintre noduri, sau in urma aparitiei de noduri noi, respectiv a disparitiei unor noduri existente in retea. Descrierea protocolului Precision Time Protocol conform standardului IEEE 1588 este una generala si abstracta, ea nu tine cont de eventualele topologii diferite ale unei retele, de constrangerile impuse de mediul de lucru sau de dispozitivele utilizate. Protocolul PTP nu pune problema implementarii specializate pentru retele wireless. In acest sens, a fost necesara o propunere de imbogatire a standardului pentru ca acesta sa fie aplicabil pe medii colaborative robotizate, sau pe retele dinamice de senzori wireless in general. Astfel, s-a incercat in cele ce urmeaza realizarea unui protocol cu caracter dinamic, adica un protocol de sincronizare care ia in considerare problemele specifice care apar in cazul retelelor WSN dinamice. Problemele ce au fost abordate in dezvoltarea noului protocol sunt:

Autentificarea unui nod nou aparut in retea – poate fi vorba si de un nod vechi, dar care se reactiveaza sau reintra in raza de actiune a retelei

Disparitia unui end-device − problema este mai simpla pentru ca nu implica un numar de noduri care raman fara master

Disparitia unui nod master – reprezinta un caz mai complex deoarece trebuie tratata si problema determinarii unui master nou pentru slave-ii corespunzatori

O prima problema care se pune in cazul retelelor dinamice este tratarea aparitiei unui nou nod in retea. Avand in vedere protocolul PTP, noul nod, pentru a se putea preta la sincronizarea propusa, trebuie sa se conecteze la retea astfel incat sa aiba un nod master cu care sa poata sa comunice prin pachetele de sincronizare specifice protocolului. Felul in care ar trebui tratata adaugarea unui nou nod la retea in perspectiva utilizarii protocolului de sincronizare PTP este descris cu pasii urmatori:

1. Nodul nou aparut trebuie sa trimita un pachet de autentificare la retea.

2. Toate nodurile din raza de actiune vor primi pachetul, dar numai cele care au si rol de master il vor interpreta, un end-device simplu va ignora pachetul.

3. Cand un nod care este si master (poate fi chiar nodul BRAIN) primeste un pachet de autentificare de la un nod nou, raspunde cu un pachet de confirmare a autentificarii.

4. E posibil ca nodul cel nou sa primeasca mai multe confirmari, daca e in raza mai multor noduri master, dar il va lua in considerare doar pe primul. Daca nu primeste raspuns la expirarea timer-ului timer_register, va intra in starea idle




pentru un timp predefinit, dupa care se va reactiva si va reincepe procesul de gasire a unui master.

5. Nodul nou raspunde primului mesaj de confirmare sosit, acceptand sa devina slave al nodului master respectiv. Celelalte noduri master, nemaiprimind nici un mesaj dupa un timp t, renunta la a mai stabili contact cu noul nod.

6. Nodul master introduce noul nod in vectorul sau de slave si raspunde din nou cu un mesaj spunand ca este noul master al nodului nou venit.

7. Daca nodul nou nu primeste acest ultim mesaj si timer-ul timer_register nu a expirat, va retrimite primul pachet de autentificare incercand sa caute un alt master si se reia tot procesul.

Se observa astfel ca se impune adaugarea unor noi tipuri de pachete definite pentru comunicarea dintre nodurile master si nodurile slave corespunzatoare acestora:

REGISTER – prin transmisia in regim broadcast a pachetelor de la acest nou nod care tocmai a fost activat si va incepe cautarea unui master

REGISTER RESPONSE − aceste pachete reprezinta raspunsul la pachetele transmise de nodurile in cautare de master. Transmisia unor astfel de pachete va fi efectuata doar de nodurile care primesc un pachet REGISTER si care au si functionalitati de master

I AM YOUR SLAVE − receptionarea primului pachet REGISTER RESPONSE de catre noul nod va genera un astfel de pachet, de data aceasta directionat doar catre master-ul corespunzator

I AM YOUR MASTER − la receptionarea pachetului I AM YOUR SLAVE de la nodul nou, nodul master va raspunde cu un astfel de pachet, dupa actualizarea vectorului cu slave-ii proprii, iar nodul cel nou va retine la receptie adresa master-ului nou determinat.

Dupa receptionarea acestui ultim mesaj, noul nod devine nod activ al retelei si va putea incepe procesul de sincronizare. Nodul master al sau va incepe transmisia de mesaje SYNC si FOLLOW UP, iar nodul nou va putea transmite DELAY REQUEST spre masterul sau. O modificare importanta care apare fata de descrierea protocolului PTP este cea legata de mesajele SYNC. Un nod master va transmite in continuare mesajele SYNC in regim de broadcast, dar va eticheta mesajul cu propria adresa. Astfel, daca un nod interepteaza semnal de la mai multe noduri master si receptioneaza mesaje SYNC diferite, va sti sa se sincronizeze doar dupa valoarea continuta in pachetul care vine de la master-ul sau.




Fig. 12. Schema logica a algoritmului de autentificare a unui nou nod la retea.




Un alt aspect specific retelelor wireless de senzori este posibilitatea disparitiei unui nod din retea. Acest lucru se poate intampla din mai multe motive: intreruperea alimentarii cu curent a nodului, deplasarea intr-o arie de unde semnalul nu mai e receptionat, erori hardware sau altele. Daca nodul disparut este un end-device, problema este mai simpla pentru ca nu implica un numar de noduri care raman fara master. Pentru a permite detectia unui end-device disparut, nu este eficienta solutia cu timere, ar insemna ca master-ul sa porneasca cate un contor pentru fiecare slave al sau. Astfel, se poate modifica protocolul astfel incat dupa un numar de pachete SYNC trimise (de exemplu, 5), master-ul sa trimita un pachet de verificare, la care slave-ii trebuie sa raspunda cu pachete DREQ. Master-ul va putea verifica daca a primit raspuns de la toti slave-ii din vectorul sau de slave. Daca master-ul nu primeste raspuns de la un nod intr-un interval de timp, va scoate nodul considerat disparut din vectorul de slave. Astfel, va fi suficient un singur timer la nivelul master-ului. Pasii de urmat pentru noul protocol sunt urmatorii:

1. Un nod end device dispare din retea din diverse motive.

2. Master-ul, dupa ce a transmis 5 pachete de sincronizare, trimite un pachet de verificare ARE_YOU_THERE catre slave-ii sai.

3. Master-ul compara adresele din vectorul sau cu cele de la care primeste mesaje DREQ, pana la expirarea unui timer_get_dreq.

4. Slave-ii care nu au raspuns sunt considerati disparuti si eliminati din vectorul de slave al master-ului.

Aparent, detectia lipsei unui end-device nu e atat de importanta, avand in vedere ca un master trimite mesaje SYNC in regim de broadcast oricum, iar disparitia acelui nod nu afecteaza alte posibile noduri slave. Pe de alta parte, sa consideram ca un nod master ramane fara nici un nod slave conectat la el. Nestiind de disparita acestora, el va continua sa trimita pachete de sincronizare in gol, ceea ce va determina un consum de putere inutil. Un caz mai complex de disparitie de nod il reprezinta situatia in care dispare un nod intermediar. Daca nodul disparut era si nod master, inseamna ca un numar de noduri erau conectate la el si au ramas fara master. Nodurile slave ale nodului iesit din retea, observand ca nu au primit nici un mesaj SYNC dupa expirarea unui timer, vor incerca sa stabileasca un contact cu master-ul lor folosind chiar un mesaj predefinit deja in protocolul PTP, si anume DREQ. Daca nu primeste raspunsul asteptat, un nod slave va considera master-ul disparut si va sterge adresa acestuia din memorie. In continuare, incepand cu primul pas, fiecare nod va relua algoritmul de autentificare la retea prezentat mai sus. Nodurile care gasesc master se vor conecta la retea, si vor putea deveni master la randul lor. In cazul in care unele noduri nu reusesc sa isi gaseasca master, acestea se vor conecta la nodurile slave care au reusit sa isi gaseasca master. Daca un nod nu reuseste sa isi gaseasca master nici printre nodurile slave conectate la retea, poate intra in stare de idle si sa reincerce dupa un interval de timp, sperand in recuperarea master-ului vechi sau in aparitia unui nod master nou.




Fig. 13. Schema logica a gestionarii pierderii unui nod end-device din retea

Pasii protocolului de gestionare a disparitiei unui nod master sunt urmatorii:

1. Un nod care era si nod master pentru alte noduri dispare din retea din diverse motive.

2. Nodurile slave conectate la nodul disparut asteapta sa primeasca mesaje SYNC de la masterul lor, pana la expirarea unui timer_get_sync.




3. Daca un nod slave a trimis un pachet DREQ, va astepta sa primeasca un pachet DRES de la master pana la expirarea unui timer_get_dres.

4. Daca nodurile nu primesc mesaje SYNC la expirarea timer-ului corespunzator, vor transmite pachete DREQ, si vor astepta raspunsul DRES pana la expirarea timer-ului pentru DRES.

5. La expirarea timer-ului, daca nu s-a primit raspuns, nodurile vor fi nevoite sa isi gaseasca alt master, incepand cu pachete REGISTER, ca in protocolul descris mai sus.

6. Nodurile care isi gasesc master vor continua sa functioneze in retea cu noul master.

7. Nodurile care nu reusesc sa isi gaseasca master vor continua procesul de autentificare la retea pana la expirarea unui timer_register. Aceste noduri pot sa isi gaseasca master chiar intre nodurile care si-au gasit master la pasul 6.

8. La expirarea timer-ului timer_register, nodurile fara master nou vor intra intr-o stare de idle, pentru un timp predefinit, dupa care se vor reactiva in speranta ca s-au prosdus modificari in retea si isi vor gasi un master.

Valorile conform carora vor functiona timer-ele specificate in pasii de mai sus se pot prestabili la initializarea retelei, in functie de caracteristicile implementarii respectivei retele si de parametri de functionare. De asemenea, pentru a respecta constrangerile de consum sau cele de hardware, fiecare nod va avea doar doua contoare, unul pentru modulul de slave si unul pentru modulul de master. Contoarele se vor initializa cu valorile necesare la un anumit moment dat. Master-ul isi va putea initializa timer-ul cu o valoare corespunzatoare la timer_there. Timer-ul din modulul slave va putea fi initializat, in functie de situatie, cu valori corespunzatoare la timer_get_sync, timer_get_dres, timer_register sau timer_idle. S-a incercat incarcarea cat mai redusa a specificatiilor protocolului, fapt pentru care anumite pachete predefinite in PTP au fost refolosite si cu scop de identificare a prezentei nodurilor. Va exista un singur tip nou de pachet adaugat la protocolul PTP pentru aceste situatii:

ARE YOU THERE − acest tip de mesaje va fi folosit periodic de catre un nod master pentru a verifica prezenta in retea a slave-urilor din vectorul sau.




Fig. 14. Schema logica a gestionarii disparitiei unui nod master din retea.




6 Concluzii

Cercetarea abordata in cadrul acestui proiect s-a preocupat de studierea mecanismelor de sincronizare in retele de senzori si sisteme distribuite. Scopul cercetarii a fost de a propune, testa si modela mecanismele de sincronizare folosind sistemul MELISSEVS. In acest sens, s-a realizat un studiu al celor mai potrivite protocoale de sincronizare pentru sistemul dat si s-a hotarat utilizarea protocolului Precision Time Protocol (PTP), datorita performantelor superioare ale acestuia in ceea ce priveste acuratetea sincronizarii. Totodata, s-a propus realizarea un nou protocol pornind de la structura de baza a protocolului de sincronizare anterior amintit. Implementarea protocolului de sincronizare PTP in mediul de simulare utilizat a impus abordarea a doua variante de realizare a sincronizarii retelei multihop pe care s-a realizat simularea: boundary clock si transparent clock. Simularile s-au realizat considerand reteaua statica, adica nodurile si topologia retelei au ramas constante de-a lungul simularilor. Informatiile obtinute in urma simularilor si evaluarii rezultatelor s-au concretizat prin reprezentari grafice, din care s-au observat performante superioare in cazul primei abordari de implementare. Cu toate acestea, decizia finala trebuie evaluata in urma unor masuratori efectuate in conditii reale de functionare a protocolului pe o perioada mai mare de timp. S-a realizat si o propunere pentru un protocol PTP modificat, astfel incat noul protocol de sincronizare sa fie adecvat in conditii de retele dinamice, adica atunci cand nodurile sunt mobile si/sau pot sa dispara, respectiv sa apara in retea din diferite motive.




Referinte bibliografice

[1] M. Maroti, B. Kusy, G. Simon, A. Ledeczi, "The Flooding Time Synchronization Protocol", Institute for Software Integrated Systems, Vanderbilt University, SenSys 2004.

[2] J. Eidson, M. Fischer, J. White, "IEEE-1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", 2003.

[3] H. Weibel, "IEEE 1588 Tutorial", Zurich University of Applied Sciences, 2006. [4] * * *, "IEEE 1588 Protocol Overview", 2008. [Online]. Available:

http://www.rtaautomation.com/ieee1588/IEEE_1588_R2.pdf [5] F. Saremi, "OMNet++: Modeling and Analysis of Computer Networks Course,

Prof. A. Movaghar", Sharif University of Technology, Computer Engineering Department, 2009.

[6] G. Giorgi, "X Simulator", University of Padova, Department of Information Engineering, 2007. [Online]. Available: http://www.dei.unipd.it/ricerca/gmee/xsim/

[7] H.Weibel, D. Mohr, "Pre-Standard Prototype Implementation of an End-to-End Transparent Clock", Zurich University of Applied Sciences, September 2006

http://www.rtaautomation.com/ieee1588/IEEE_1588_R2.pdf�

http://www.dei.unipd.it/ricerca/gmee/xsim/�

DSPLabs Technical Reportdsplabs.cs.upt.ro/grants/melissevs/pdfs/DSPL-TR.2009.3.pdf · Digital...

Documents

Transcript of DSPLabs Technical Reportdsplabs.cs.upt.ro/grants/melissevs/pdfs/DSPL-TR.2009.3.pdf · Digital...