This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
proiecte:a-mac-protocol-for-wsn [2014/01/31 12:19] alexandru.copot [Adresare si rutare] |
proiecte:a-mac-protocol-for-wsn [2014/02/06 23:03] (current) alexandru.copot [Rezultate] |
||
|---|---|---|---|
| Line 43: | Line 43: | ||
| frame de broadcast din faza initiala este transmis cu o anumita valoare TTL ce scade la fiecare | frame de broadcast din faza initiala este transmis cu o anumita valoare TTL ce scade la fiecare | ||
| forwardare a frameului. | forwardare a frameului. | ||
| + | |||
| + | ==== Sincronizare ceas ==== | ||
| + | |||
| + | Exista doua posibilitati de sincronizare intre noduri pe care le-am luat in calcul: | ||
| + | - Sincronizare relativa a momentelor de wake-up | ||
| + | - Sincronizare absoluta a ceasului | ||
| + | |||
| + | Prima varianta presupune ca ceasurile nodurilor sunt deja apropiate ca valoarea. Problema | ||
| + | pe care incearca sa o rezolve este desincronizarea care poate sa apara cand anumite noduri | ||
| + | au nevoie de mai mult timp de procesare. In aceasta situatie este posibil ca perioada activa | ||
| + | sa nu se mai suprapuna si sa se piarda mesaje. Solutia noastra sincronieaza momentuld de | ||
| + | wake-up in nodurilor invecinate facand o medie a acestora. In acest fel, protocolul devine | ||
| + | dinamic si se adapteaza la necesarul fiecarui nod. Pentru a evita situatia in care perioada | ||
| + | activa sa devina prea scurta sau ce inactiva prea lunga, se iau in calcul si limite pentru | ||
| + | timpul final calculat. | ||
| + | |||
| + | A doua varianta de sincronizare are rolul de a asigura o diferenta cat mai mica intre valorile | ||
| + | ceasurilor nodurilor vecine. Practic se sincronizeaza contoarele de timp ale nodurilor, asemanator | ||
| + | unui sistem Network Time Protocol. Avand un ceas sincronizat absolut face ca toate operatiile | ||
| + | cu durate relative sa aiba un comportament asemanator pe orice nod. | ||
| + | |||
| + | Pentru determinarea perioadelor de sleep/ | ||
| + | < | ||
| + | \[ | ||
| + | S = \sum_{n \in neighbours}^{} (n.local\_time + n.wakeup - n.sync\_rcv\_time) | ||
| + | \] | ||
| + | |||
| + | \[ | ||
| + | next\_sleep = \frac{old\_sleep + S}{N + 1} | ||
| + | \] | ||
| + | </ | ||
| + | ===== Implementare ===== | ||
| + | Toate mesajele transmise in retea au in format generic descris de: | ||
| + | <code C> | ||
| + | struct frame { | ||
| + | uint8_t ll_src; | ||
| + | uint8_t ll_dst; | ||
| + | uint8_t src; | ||
| + | uint8_t dst; | ||
| + | uint8_t flags; | ||
| + | uint8_t ttl; | ||
| + | uint8_t data[]; | ||
| + | }; | ||
| + | </ | ||
| + | Pachetele de control au setat unul din flag-urile: FLAG_RTS, FLAG_CTS, FLAG_TIME. | ||
| + | |||
| + | Tabela de rutare ofera practic atat informatii despre rutare cat si despre ceasurile | ||
| + | nodurilor. O intrare in tabela de rutare: | ||
| + | <code C> | ||
| + | struct route { | ||
| + | uint8_t | ||
| + | uint8_t | ||
| + | uint8_t | ||
| + | uint32_t this_time; | ||
| + | uint32_t dst_time; | ||
| + | uint16_t dst_sleep; | ||
| + | uint8_t | ||
| + | }; | ||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| ===== Rezultate ===== | ===== Rezultate ===== | ||
| + | Am implementat functionalitatile prezentate anterior. Acestea au fost testate pe diverse topologii | ||
| + | folosind Avrora. | ||
| + | |||
| + | Algoritmii de sincronizat ceasul au fost testati si separat, in afara protocolului | ||
| + | de comunicatie, | ||
| + | aratat ca dupa sute si mii de iteratii, ceasurile nu s-au desincronizat mai mult decat erau | ||
| + | la pornire. | ||
| + | |||
| + | {{: | ||
| + | {{: | ||
| ===== Bibliografie/ | ===== Bibliografie/ | ||