Protocolul DE Rutare Meshspf Pentru Retele DE Senzori Wireless

CUPRINS

1. INTRODUCERE… .5

1.1. Motivație … .5

1.2. Obiective … .5

1.3. Conținutul lucrării … ..6

2. REȚELELE DE SENZORI WIRELESS: FUNDAMENTE TEORETICE … .7

2.1. Descriere generală a rețelelor de senzori wireless … ..7

2.2. Standardul IEEE 802.15.4 ZigBee … .8

2.2.1. IEEE 802.15.4 WPAN … ..9

2.2.2. IEEE 802.15.4 PHY … .12

2.2.3. IEEE 802.15.4 MAC … …14

2.3. Platforma hardware … .21

2.3.1. Modulul IRIS … ..22

2.3.2. Placa de interfațare MIB520 … …22

2.4. Platforma software … ..23

2.4.1. TinyOS și nesC … ..23

2.4.2. Cygwin, XServe și PostgreSQL … .27

2.4.3. Microsoft .NET 2.0 … ..29

2.4.4. XSniffer … ..30

3. PROTOCOLUL DE RUTARE MESHSPF … …31

3.1. Cracteristicile protocolului MeshSPF … …31

3.1.1. Pachetul Single-hop (TOS_Msg) … ..33

3.1.2. Pachetul Multi-hop UpStream (TOS_MHopMsg) … …34

3.1.3. Pachetul Multi-hop DownStream (TOS_DSMsg) … …34

3

3.2. Componenta Designated Router Other … .35

3.2.1. Starea Discove și Protocolul Discovery … .36

3.2.2. Starea Advertise … .41

3.2.3. Starea Wait … …42

3.2.4. Starea Route și Protocolul Hello … …43

3.3. Componenta Designated Router Base. .. ..46

3.3.1. DRBase: legătura dintre rețea și aplicație … .47

3.3.2. Protocolul Discovery … ..48

3.3.3. Protocolul Hello… .48

3.3.4. Pachetele Neighbors Advertisment și Route Update … ..49

3.4. Componenta MeshSPF Router … ..50

3.4.1. Clientul Serial Forwarder … ..51

3.4.2. Clientul PostgreSQL… .52

3.4.3. Firul de execuție ReceiveData … .53

3.4.4. Firul de execuție TransmitData … ..54

3.4.5. Firul de execuție central (Engine) … ..55

4. STUDIU DE CAZ: COMPARAREA PROTOCOLULUI MESHSPF CU

PROTOCOLUL XMESH … .57

4.1. Caracteristicile protocolului Xmesh … ..57

4.2. Definirea indicatorilor de calitate … .. 59

4.3. Rezultate experimentale … …60

4.3.1. Timpul de Convergență … ..61

4.3.2. Viteza de Rutare … .63

4.3.3. Fluxul de Pachete … .64

4.3.4. Încărcătura Computațională … ..65

5. CONCLUZII … ..66

6. BIBLIOGRAFIE … ..68

=== 1 ===

PROTOCOLUL DE RUTARE
MESHSPF PENTRU REȚELE DE
SENZORI WIRELESS

2

CUPRINS

1. INTRODUCERE… .5

1.1. Motivație … .5

1.2. Obiective … .5

1.3. Conținutul lucrării … ..6

2. REȚELELE DE SENZORI WIRELESS: FUNDAMENTE TEORETICE … .7

2.1. Descriere generală a rețelelor de senzori wireless … ..7

2.2. Standardul IEEE 802.15.4 ZigBee … .8

2.2.1. IEEE 802.15.4 WPAN … ..9

2.2.2. IEEE 802.15.4 PHY … .12

2.2.3. IEEE 802.15.4 MAC … …14

2.3. Platforma hardware … .21

2.3.1. Modulul IRIS … ..22

2.3.2. Placa de interfațare MIB520 … …22

2.4. Platforma software … ..23

2.4.1. TinyOS și nesC … ..23

2.4.2. Cygwin, XServe și PostgreSQL … .27

2.4.3. Microsoft .NET 2.0 … ..29

2.4.4. XSniffer … ..30

3. PROTOCOLUL DE RUTARE MESHSPF … …31

3.1. Cracteristicile protocolului MeshSPF … …31

3.1.1. Pachetul Single-hop (TOS_Msg) … ..33

3.1.2. Pachetul Multi-hop UpStream (TOS_MHopMsg) … …34

3.1.3. Pachetul Multi-hop DownStream (TOS_DSMsg) … …34

3

3.2. Componenta Designated Router Other … .35

3.2.1. Starea Discove și Protocolul Discovery … .36

3.2.2. Starea Advertise … .41

3.2.3. Starea Wait … …42

3.2.4. Starea Route și Protocolul Hello … …43

3.3. Componenta Designated Router Base. .. ..46

3.3.1. DRBase: legătura dintre rețea și aplicație … .47

3.3.2. Protocolul Discovery … ..48

3.3.3. Protocolul Hello… .48

3.3.4. Pachetele Neighbors Advertisment și Route Update … ..49

3.4. Componenta MeshSPF Router … ..50

3.4.1. Clientul Serial Forwarder … ..51

3.4.2. Clientul PostgreSQL… .52

3.4.3. Firul de execuție ReceiveData … .53

3.4.4. Firul de execuție TransmitData … ..54

3.4.5. Firul de execuție central (Engine) … ..55

4. STUDIU DE CAZ: COMPARAREA PROTOCOLULUI MESHSPF CU

PROTOCOLUL XMESH … .57

4.1. Caracteristicile protocolului Xmesh … ..57

4.2. Definirea indicatorilor de calitate … .. 59

4.3. Rezultate experimentale … …60

4.3.1. Timpul de Convergență … ..61

4.3.2. Viteza de Rutare … .63

4.3.3. Fluxul de Pachete … .64

4.3.4. Încărcătura Computațională … ..65

5. CONCLUZII … ..66

6. BIBLIOGRAFIE … ..68

4

1. INTORDUCERE

1.1 Motivație

Progresele tehnologice uriașe realizate în ultimii ani în domeniile Sistemelor Micro-
Electromecanice (MEMS) și Nano-Electromecanice (NEMS) au dat o nouă dimensiune

dezvoltării rețeleor de senzori wireless.

S-a obținut astfel pe de-o parte micșorarea mărimii, a greutății și a costurilor de fabricație ale senzorilor, iar pe de atltă parte au fost îmbunătățite caracteristicilor lor de funcționare precum rezoluția spațială, temporală și precizia.

Dezvoltate inițial în scopuri militare , rețelele de senzori wireless sunt folosite în
prezent întro gamă foarte largă de aplicații din domeniul industriei civile. Astfel printre cele
mai importante întrebuințări ale acestora se remarcă, rețele pentru controlul traficului rutier,
monitorizarea mediului pe suprafețe foarte mari, monitorizarea rețelelor electrice la nivel
regional sau național , aplicații în domeniul sănătății precum monitorizarea condiției

victimelor la locul accidentului, aigurarea confortului în locuințe.

În prezent rețele de senzori wireless, dezvoltate pentru a reliza sarcinile expuse anterior, pot conține sute sau chiar mii de noduri. Datorită propreatăților pe care trebuie să le respecte aceste rețele, precum consumul scăzut și eficientizat de energie sau întindere foarte mare dar și datorită nenumăratelor restricții de proiectare și a resurselor limitate de care dispun la nivel de nod, fac din crearea unui protocol de rutare pentru acestea o temă de cercetare extrem de interesantă.

1.2 Obiective

Această lucrare are ca scop dezvoltarea unui protocol de rutare care să respecte cerințele nivelului Rețea al standardului 802.15.4 ZigBee astfel încât să fie satisfăcute toate necesitățile unei rețele de senzori wireless din perspectiva transmiterii și rutării de pachete, ținând cont de constrângerile pe care o astfel de rețea le impune.

Principala caracteristică pe care un astfel de protocol trebuie să o aibe este asigurarea
unui consum redus de enrgie , păstrând intactă functșionalitatea rețelei. Din această

perspectivă lucrarea de față se axează pe reducerea numărului de pachete necesare pentru
realizarea și menținerea topologiei logice a rețelei (calcularea și întreținerea rutelor folosite la

5

transmiterea pachetelor dinspre nodurile dotate cu senzori ale rețelei spre nodul Bază),

precum și pe minimizarea procesării datelor necesare protocolului de rutare la nivel de nod.

S-a urmărit sporirea stabilității și robusteții rețelei, fiind foarte importantă tratarea
problemei apariției buclelor de rutare. Deasemenea s-a urmărit obținerea unei periodae cât
mai mici de convergență a rețelei privind atât din perspectiva configurării inițiale a acesteia
precum și în urma modificărilor de topologie ce pot apărea pe parcursul funcționării.

Un alt aspect important este viteza pe care protocolul de rutare o asigură transmiterii pachetelor ce conțin datele prelevate de la senzori, urmărindu-se în acestă direcție calcularea de rute optime din perspectiva „costului de tranmisie” către nodul Bază. Costul redus al transmisie se referă la timpul necesar unui pachet să ajungă la destinație, dar și la un consum cât mai mic de energie , necesar transmiterii și rutării pachetului (un rol foarte important pentru obținerea unui cost redus îl are numărul de retransmisi necesare).

Încercând să respecte cât mai mult cerințele prezentate anterior, protocolul de rutare
MeshSPF analizat în acestă lucrare, a fost dezvoltat în ideea realizării unui compromis între
simplitatea și resursele reduse la nive de nod al rețelei pe care le implică un protocol de rutare
de tipul „Vector de Distanță” (Distance Vector), și stabilitatea și vitezele ridicate de rutare a
pachetelor oferite de utilizarea protocoalelor de tipul Starea Legăturii (Link State).

1.3 Conținutul lucrării

În capitolul următor vor fi prezentate aspectele teoretice considerate pentru dezvoltarea

acestei lucrări. Astfel subcapitolul 2.1 conține aspecte generale și caracteristicile de bază ale rețelelor de senzori wireless, 2.2 prezintă pe larg standardul IEEE 802.15.4 , axându-se pe nivelele PHY și MAC ale acestuia, 2.3 prezintă componentele hardware care au fost folosite pentru dezvoltarea protocolului MeshSPF iar subcapitolul 2.4 conține aspecte cu privire la ustensilele software folosite.

Capitolul 3 conține prezentarea protocolului de rutare MeshSPF dezvoltat, evidențiind modul în care au fost proiectate și realizate fiecare din cele 3 componente ale acestuia
(Designated Router Base, Designated Router Other, MeshSPF Router).
Detaliile privind testarea protocolului sunte prezentate în capitolul 4 pe baza unui
studiu comparativ între performanțele obținute folosind MeshSPF și protocolul XMesh
dezvoltat de către Crossbow. Concluziile bazate pe rezultatele obținute în urma dezvoltării protocolului MeshPSF sunt prezentate în capitolul 5.

6

2. REȚELELE DE SENZORI WIRELESS: FUNDAMENTE
TEORETICE

2.1 Descriere generală a rețelelor de senzori wireless

Rețelele de senzori wireless sunt alcătuite din sisteme autonome dotate cu senzori răspândite spațial care interacționând intre ele permițând monitorizarea diferitelor condiții fizice ale mediului precum temperatura, sunetul, vibrațiile, presinea, mișcarea și poluarea. Inițial ele au fost dezvoltate în scopuri militare, dar datorită costului redus, al mobilitații oferite si a posibilitații de extindere practic nelimitate, rețele au ajuns sa fie folosite in multe domenii civile și industriale.

Pe lânga senzorii de care dispune, un nod al unei rețele de senzori este echipat cu un transciever radio (sau un alt dispozitiv de transmisie), un microcontroler folosit la procesarea datelor la nivel de nod și de o sursă de energie (de cele mai multe ori o baterie).

Uzual rețeaua de senzori se constitue intr-o structura ad-hoc de plasă (mesh), fiind folosit un protocol de rutare multi-hop pentru transmiterea datelor. Caracteristicile unei astfel de rețele sunt următoarele:

o Multi-hop: posibilitatea transmiterii datelor peer-to-peer (de la nod la nod) catre
nodul care are rolul de „Bază a rețelei”, conferind astfel o scalabilitate sporita;
o Auto-Configurare: rețeaua se poate configura fară intervenșie umană;
o Auto-Regenerare: caracteristica rețelei de a accepta sau pierde noduri dinamic,
fară a fi necesară o oprire sau o repornire a acestia in ansamblu;

o Rutare Dinamică: nodurile rețelei sunt capabile sa aleagă rutele de transmisie a
datelor către bază in funcție de contextul actual al rețelei.

Intrecațiunea cu o astfel de rețea este realizată de obicei prin intermediul unei aplicații software. Astfel din acest punct de vedere, rețeaua poate fi privita ca și conlucrarea următoarelor trei nivele:

7

o Nivelul Client: oferă interfațarea grafică dintre rețea si utilizatorul uman,
permițând acestuia să obtină si să interpreteze datele provenite de la senzori,
precum și să transmită acestora diferite comenzi;

o Nivelul Server: reprezintă o entitate situată intre rețea si utilizator si care este
desemnată să inmagazineze permanent sau provizoriu informațiile transmise de
nodurile rețelei si să l-e transmit cleintului in momentul in care acesta l-e solicită;
o Nivelul Nodurilor: este constituit din software-ul aflat pe nodurile rețelei si care
gestionează preluarea și transmisia datelor la nivel de nod.

2.2 Standardul IEEE 802.15.4 ZigBee

ZigBee reprezintă un standard de protocoale de rețea wireless, caracterizat prin rată mică de
transfer, putere consumată redusă și cost mic, destinat aplicațiilor de automatizare și control la
distanță. Tehnologia ZigBee se bazeaza pe standardul IEEE 802.15.4 care definește

caracteristicile nivelelor inferioare MAC (subnivel al componentei Data Link din cadrul

modelului OSI) si PHY (nivelul fizic) pentru rețele wireless. Ulterior ZigBee a devenit parte componenta a IEEE 802.15.4 , de a cărui dezvoltare sunt in prezent responsabile atât IEEE cât și Alianța ZigBee.

ZigBee oferă soluții pentru aplicațiile în care este esențială o durată de viață a bateriei de câteva luni până la câțiva ani, și care nu necesită capacități de transmisie cu rate mari de transfer precum cele oferite de catre tehnologia Bluetooth (IEEE 802.15.1). În plus, ZigBee oferă posibilitatea proiectării rețelelor de tip plasă (mesh network) mai mari decât o poate face tehnologia Bluetooth.

Dispozitivele ZigBee pot transmite în limita a 10-75 metrii, în funcție de mediul

Frecventelor Radio în care funcționează si de consumul de putere permis de către aplicația
dată. Ele opereaza in banda Frecventelor Radio nelicențiate la nivel global (2.4GHz global,

915 MHz în SUA, 868 MHz în Europa), avnâd rate de transfer de 250Kbps la 2.4 GHz, 40 Kbps la 915MHz și 20 Kbps la 868 MHz.

IEEE și Alianța ZigBee urmăresc dezvoltarea intregii stive de protocoale. Astfel IEEE
este responsabilă de nivelele inferioare, Fizic si Legătura de Date, iar Alianța ZigBee
urmărește dezvoltarea nivelelor superioare (pornind de la nivelul Rețea și incheiind cu nivelul
Aplicație) astfel incât să permită interoperabilitate intre rețelele de date, crearea de servicii de

8

securitate si control wireless pentru clădiri si a altor soluții avansate pentru dezvoltarea standardului.

IEEE 802.15.4 prin specificarea detaliata a caracteristicilor nivelelor PHY și MAC ofera elementele necesare dezvoltării a trei tipuri elementare de rețele, stea, peer-to-peer si arbore cluster. Algoritmii de rutare folosiți urmăresc consumul redus de energie și minimizarea latențelor la transmiterea de date. O caracteristică esențială a ZigBee este eliminarea „punctelor singulare de eșec” in cadrul topologiilor peer-to-peer.

2.2.1 IEEE 802.15.4 WPAN

Standardul IEEE 802.15.4 se evidențiază prin flexibilitatea rețelelor, cost redus, consum foarte mic de energie, rată mică de transfer, precum și prin capacitatea de autoorganizare a rețelei formate din dispozitive fixe, portabile sau mobile.

Compnentele WPAN

Sistemel ZigBee conțin mai multe tipuri de componente, dintre care cel mai des intâlnit este „dispozitivul”. Acesta la rândul seu este de două tipuri: dispozitiv cu funcționalitate completă, FFD (Full-Function Device) si dispozitiv cu funcționalitate redusă RFD (Reduced-Funcion Device). O rețea wireless necsită existența a cel puțin unui dispozitiv FFD care să aibe rolul de coordinator al PAN (Personal Area Network).

Un dispozitiv FFD poate opera în 3 moduri: coordonator al PAN, coordonator simplu, sau dispozitiv. Sarcinile unui RFD sunt relativ simle, nepresupunând transmiterea unei cantitați mari de date. Dispozitivele FFD nu intampină dificultatțti in ceea ce privește comunicarea cu alte dispozitive din cadrul aceleiași rețele, in schim RFD-urile pot comunica doar cu dispozitive FFD.

Topologii de rețea

ZigBee suporta topologiile stea, peer-to-peer si arbore cluster, prezentate succint in paragrafele urmatoare:

9

o Topologia Stea:

comunicațiile sunt stabilite între dispozitive și un singur nod central, numit coordonator al rețelei PAN. Acest coordonator poate fi alimentat de la rețeaua de alimentare, pe când nodurile subalterne cel mai probabil sunt alimentate de la baterii. După ce un dispozitiv FFD este activat pentru prima oară el poate stabilii, singur, propria rețea și poate deveni coordonator PAN. La fiecare pornire rețeaua atribuie un identificator PAN, care nu este la acel moment utilizat de o altă rețea din vecinătate, permițând rețelelor să funcționeze independent

o Topologia Peer-To-Peer

în topologia peer-to-peer nu există un coordonator PAN. Spre deosebire de topologia
stea, orice dispozitiv poate comunica cu oricare altul atâta timp cât se află în raza de
acțiune comună. Există posibiliatea de auto-organizare și chiar de auto-reorganizare în
urma funcționării defectuase ca urmare a unei perturbații. Aplicațiile cărora această
topologie se potrivește foarte bine sunt de monitorizare și constrol în industrie,
monitorizarea și evidența bunurilor. Este capabilă de a ruta datele pe mai multe căi și
de a dirija pachetele peste mai multe hopuri (noduri), pentru a ajunge la destinație.

o Topologia Arbore Cluster

preuspune crearea unei structuri arborescente de noduri conectate peer-to-peer, in care majoritatea dispozitivelor sun de tipul FFD, iar eventualele dispotizitive RFD pot fi conectate doar ca și “frunze” ale arborelui . Topologia presupune exsitenta unui singur FFD cu rolul de coordonator al PAN, dar permite oricărui alt nod FFD sa fie un coordonator pentru un anumti număr de noduri.

Un grup de noduri are un cluster head, CLH (conducător de grup), care va avea un
identificator de grup ,CID (cluster ID) setat pe zero, și va alege un identificator PAN
neutilizat. CLH-ul va face broadcast către toate nodurile aflate în aria sa de trasmisie,
transmițând un cadru numit “beacon”. Nodurile care recepționează acest cadru și sunt
interesate sa comunice în noua rețea detectată trimit o cerere conducătorului de grup.
Dacă nodul rincipal din grupul de noduri acceptă noul nod, îl va identifica în rețeua sa
ca pe un dispozitiv fiu și îl va consemna în lista vecinilor. Nou intratul nod va marca
în lista lui nodul părinte care tocmai l-a acceptat și va începe să trasmită periodic
cadre “beacon” astfel ca și alți candidați să poate intra în rețea. O dată ce cerințele de
rețea sunt satisfăcute, coordonatorul PAN poate desemna, în cazul existenței mai

10

multor posibilități, un CLH pentru un grup de noduri descendent grupului principal
unde chiar coordonatorul PAN este și CLH. Această organizare arborescentă aduce
avantajul extinderii rețelei pe arii largi, cu dezavantajul creșterii latenței mesajelor.

Figura 2.1 Topologii WSN

Arhitectura dispozitivelor LR-WPAN

Dispozitivele LR-WPAN sunt concepute din punct de vedere arhitectural în strânsă concordanță cu nivelele ierarhice definite in standardul IEEE 802.15.4. Astfel la nivelul PHY, dispozitivul conține transceiverul radio precum și un mecanism de control de nivel scăzut; la subnivelul MAC este precizat modul in care este permis accesul tuturor tiputilor de transfer de date, la canalul de comunicare.

Nivelurile superioare constatu dintr-un nivel Rețea , unde este specificat modul in cate se formeaza rețeaua , precum și modul de manipulare și rutare a pachetelor de date, si un nivel Aplicație, care conferă dispozitivului funționalitatea dorită. Intre subnivelul MAC si nivelurile superioare poate fi plasat si un subnivel LLC (Logical Link Control), specificat de standardul IEEE 802.2, care specifica modul in care este sunt controlate conexiunile logice si care interactioneaza cu subnivelul MAC (Medium Acces Control) prin intermediul componentei SSCS (Service Specific Convergence Sublayer). Figura X.X prezinta arhitectura dispozitivelor LR-WPAN.

11

Figura 2.2: Arhitectura dispizitivelor LR-WPAN

2.2.2 IEEE 802.15.4 PHY

Nivelul PHY (fizic) din cadrul standardului IEEE 802.15.4 ofera un servicu PHY care
precizezază modul de gestiune al datelor, permitand transmisia și recepția pachetelor de date
ale nivelului PHY (PPDU) pe/de pe canalul radio; serviciul PHY de mangement, care
inerfațeaza modulul PLME (Entitatea de Management a Nivelului Fizic). Principalele
facilități oferite de nivelul PHY specifică modul de activare/dezactivare al transciever-ului
radio, detectarea de energie pe mediu (ED), indicarea calitatii legaturii cu un alt dispozitiv
(LQI), selectia canalelor de comunicare, stergerea valorii canalului (CCA), precum si

transmiterea si receptia datelor la/de la mediul fizic.

În funcție de frecvența radio utilizată se poate beneficia de o rată de transfer mai mare (250Kbps la frecvența de 2.4GHz) ,datorită unei scheme cu un grad mai mare de modulație, de capacități de trecere mai mari și de latențe mai mici. Pentru frecvențe mai mici (900MHz) se poate beneficia de rate de transfer reduse (20 / 40 Kbps), dar cu avantajul unei arii de acoperire mai mari.

În intervale mici din vecinătatea valorilor standard ale frecvențelor, 2.4-2.4835GHz de
exemplu, se pot alege un număr de canale (până la 16 pt 2.4GHz) cu posibilitatea de relocare
în cadrul spectrului. Prin standard este permisă scanarea listei de canale, selectarea dinamică a
unui canal în scopul detecției beacon-urilor, identificarea calității legăturilor, comutarea
canalelor pentru îmbunatățirea legăturii. Pentru frecvențe în jurul valorii 915 MHz se pot

12

alege 10 canale de comunicații, iar pentru frecvența 868 MHz este disponibil un singur canal de comunicație.

PHY Banda de Parametrii de Propagare Parametrii de Date

(MHz) Frecventă Rată Chip Modulatie Rată de Biti Rată Simboluri Simboluri

(MHz) (kchip/s) (kb/s) (ksimbol/s)

868/915 868-868.6 300 BPSK 20 20 Binar

902-928 600 BPSK 40 40 Binar

2450 2400-2483.5 2000 O-QPSK 250 62.5 Ortogonal 16

Tabel 2.1:Banda de frecvențe și ratele de biți obținute

Detectare energiei pe mediu (ED)

Funcția de detectare si masurare a energiei la receptor este utilă nivelului Rețea în algoritmul de selectare a canalului. Valoarea obținută este un estimat al semnalului recepționat, cuprins in limitetle niveluriolor de bandă ale canalului IEEE 802.15.4 folosit. Nu se realizează o decodificare sau o identificare a semnalului de biți, perioada ED avnâand o durata echivalentă cu perioada in care sunt recepțtionate 8 simboluri.

Valorea finală a ED este raportată sub forma unuei valori intregi pe 8 biți (0x00 –
0xFF). Valoarea minimă pe care o poate avea ED este 0, ea indică detecția unei valori cu cel mult 10dB mai mare decât sensibilitatea stabilită pentru receptor.

Indicarea calitatii legaturii (LQI)

Funcția de indicare a calității legăturii (LQI) – folosind ED, estimând semnalul “zgomot” sau
combinând aceste două metode detectează calitatea legăturii ca o valoare între 0x00 (calitate
scăzută) și 0xFF (calitate ridicată), valoare ce va fi prelucrată de nivelele superioare (rețea și
aplicație).

Stergerea valorii canalului (CCA)

Funcția de ștergere a valorii canalului (CCA), se aplică prin una dintre următoarele metode:

o Energia depașește un prag prestabilit, CCA raportează mediu ocupat când energia
detectată depășește pragul ED;

13

o Detecția semanlului purtător pe mediu, CCA anunță mediu ocupat doar în cazul

detectării unui semnal cu modulație și cu bandă de întindere specifice IEEE 802.15.4, indiferent de pragul ED;

o Detecția semanlului purtător cu depașire unui prag, la fel ca la punctul 2 cu

specificarea că energia poate fi peste pragul ED

Formatul pcahetului PPDU (PHY Protocol Data Unit)

Octeti: 4 1 1 Variabil

Preambul Delimitator de Lungime Rezervat PSDU

start (SFD) (7 biti) (1 bit)

SHR PHR Incarcatura PHY

Fiecare pachet PPDU are urmatoarele componente:

o SHR, antetul de sincronizare, permite receptorului să se sincronizere cu emițatorul; o PHR, antetul nivelului PHY, precizează dimensiunea pachetului;
o Incarcatura nivelului PHY, contine cadrul provenit de la subnivelul MAC

2.2.3 IEEE 802.15.4 MAC

Nivelul MAC oferă, la fel ca și nivelul său inferior PHY , un serviciu de gestionare al pachetelor, care permite transmisia și recepția pachetelor MPDU (MAC Protocol Data Unit); un serviciu de management al MAC, care interfațeaza modulul responsabil de controlul MAC (MLME). Principalele facilități oferite de MAC sunt: controlul semanleor „beacon”, accesul la canale radio, validarea cadrelor, confirmarea ajungerii cu succes la destinație a cadrelor și managementul poziției temporale garantate (GTS, guaranteed time slot).

Structura unui „supercadru”

Rețelele LR-WPAN ofera opțional posibilitatea folosirii unor structuri de date numite
supercadre. Aceste supercadre sun încadrate de către pachete „beacon” și sunt împărțite in 16
segmente egale. Beaconul este introdus întotdeauna în primul segment al unui supercadru.
Daca un dispozitiv coordonator nu dorește să folosească supercadre, este suficient ca acesta să

14

nu mai emită pachete beacon. Acestea din urmă fiind folosite pentru sincronizare dintre
dispozitive, pentru identificarea PAN-ului și pentru descrierea structurilor supercadru.
Supercadrele sunt alcătuite din doua perioade distincte, o perioadă activă și o perioadă
de inactivitate. Pe durata perioadei inactive, nodul coordonator nu trebuie să interacționeze cu
PAN.ul din care face parte, el putând funcționa in modul de putere scăzută (low-power).
Pe durata perioadei active apar alte doua subperioade ale acesteia: CAP (contention
acces period), perioadă în care dispozitivele din PAN doresc acces simultan la mediu si câand
este folosit CSMA-CA și CFP (contention free period), în care dispozitivele nu trebuie sa
„concureze” pentru a avea acces la mediul de transmisie. CFP beneficiază de poziții
temporale garantate (GTS), introduse la finalul supercadrului la încheierea secțiunii CAP.
Pentru a cunoaște duratele porțiunilor din cadru se folosesc valorile
macSuperFrameOrder (SO) și macBeaconOrder (BO). BO poate lua valori între 0 și 14,
valoarea 15 fiind ignortă. Intervalul pentru beacon (BI) se calculează cu formula:

BI = aBaseSuperFrameDuration * 2BO

Valoarea macSuperFrameOrder este legată de lungimea porțiunii active, SD calculată cu formula:

SD = aBaseSuperFrameDuration * 2SO cu 0 <= SO <= 14

Pentru valoarea 15 supercadrul este dezactivat după semnalul beacon. Porțiunea activă include beacon-ul, intervalul CAP și CFP. Pentru accesarea canalului de către cadrele transmise în perioada CAP folosesc algoritmul CSMA-CA. Măsura aceasta nu este necesară perioadei CFP. Lungimea CFP se calculează prin însumarea tuturor GTS.

Figura 2.3: Structura unui supercadru

15

Utilizarea supercadrelor fiind opțională, prin setarea macSuperFrameOrder și macBeaconOrder la valoarea 15, mecanismul utilizării supercadrelor poate fi dezactivat. Dezavantajul este că nodurile cu funcția de coordonare nu mai pot trimite beacon-uri, GTSurile de asemenea, iar toate pachetele în afara celor de confirmare vor fi transmise pe canal cu folosirea algoritmului CSMA-CA fără poziții

Algoritmul Carrier Sense Multiple Acces – Collision Avoidance

Mediul Frecventa Radio, utilizat de catre rețelele de senzori wireless pentru transmisia datelor este de tipul acces multiplu, de aceea pentru a evita coliziunile între pachetele de date transmise de catre doua sau mai multe dispozitive este necesara folosire algoritmului CSMACA. Urmând acest mecanism fiecare nod al rețelei care dorește să transmită date, execută mai întâi operația de ascultare pentru a determina dacă un alt nod transmite sau nu, transmițând priopriul pacht doar dacă nu detectează o alta transmise.

Algoritmul este implementat pe baza a 3 variabile:

NB – numărul de incercări de transmitere a datelor care au eșuat datorita unei alte
transmisii detectate pe mediu;

CW – precizează numărul de perioade in care mediul etse detectat ca liber, necesar
inaintea transmiterii datelor;

BE – perioada pe care o asteapta un dispoozitiv inainte de a incerca să acceseze
canalul.

Variabilele, după inițializare, vor fi incrementate sau decrementate în funcție de tipul de contorizare a cadrelor transmise, sincronizarea efectuându-se prin alinierea perioadelor unităților definite special pentru implementarea algoritmului cu perioadele cadrelor transmise. În funcție de valoarea acestor variabile de contorizare se va ști în orice moment dacă un set de cadre se află în curs de transmisie pe canalul de comunicație sau nu.

CSMA-CA se implementează diferit în funcție de validarea sau invalidarea folosirii supercadrelor, și anume CSMA-CA cu poziții și CSMA-CA fără poziții, cu diferența constând în simplificarea algoritmului fără poziții prin eliminarea sincronizărilor cu cadrele din supercadru, acesta validând o transmisie imediat ce depistează canalul liber.

16

Modelul transferului de date

In cadrul IEEE 802.15.4 MAC sunt specificate trei tipuri de transfer de date: de la un coordonator la un alt dispozitiv al reteli, de la un dispozitiv actre un coordonator si intre doua dispozitive.

In rețelele in care nu se folosesc cadre de tip “beacon”, datele sunt transmise sub
formă de cadre în mod direct, ori de câte ori se depistează canalul ca fiind liber. În acest caz,
algoritmul folosit se numeste CSMA-CA fără cadre cu posibilitate de confirmare finală a

transmisiei cu succes.

Dacă rețeaua folosește cadrele de tip “beacon”, dispozitivul care intenționează să
transmită date urmărește mai întâi traficul de pe canal, “citește” cadrele “beacon”, ține

evidența tuturor cadrelor din supercadru și trimite propriile cadre în urma calculelor de sincronizare efectuate prin algoritmul CSMA-CA cu poziții. Opțional se pot solicita confirmări ale transmisiei cu succes a datelor.

O particularitate a rețelelor ZigBee este aceea că funcționarea rețelei nu este centralizată în jurul coordonatorului, din punctul de vedere al aplicațiilor, ci se răspândește la nivelul tuturor dispozitivelor. În varianta în care un coordonator dorește să transmită date unui dispozitiv, acesta va lansa un mesaj care va fi pus în așteptare (valabil pentru rțțelele care folosesc beacon-uri), care va fi recețționat de nodul destinatar mulțumită capacității acestuia de a asculta și recepționa periodic semnale beacon, depistând mesajele în așteptare. În cazul în care aceasta se întâmplă, dispozitivul receptor va transmite la rândul său o comandă MAC pentru solicitare a datelor ce se doresc a-i fi transmise. Se poate folosi confirmarea trasmiterii datelor. Algoritmul adecvat acestui caz este CSMA-CA cu poziții

In condiții similare, dar având o rețea in care nu s-e transmit beacon-uri, apare
dezavantajul consumului ridicat de energie deoarece sunt transmise frecvent cereri de către
dispozitive pentru a depista dacă un coordonator are de transmis date. Acestia din urmă vor
genera trafic suplimentar prin transmisia frecventă de pachete cu conținut 0 prin care

informează dispozitivele că nu există date destinate lor. În cazul în care există totuși date de transmis este folosit algoritmul CSMA-CA fără poziții.

In rețelele peer-to-peer, ca și în cazurile precedente se pot folosi una dintre variantele
algoritmului CSMA-CA, cu sau fără poziții în funcție de folosirea / nefolosirea beacon-urilor

17

Pornirea și controlul PAN-urilor

Un dispozitiv FFD poate iniția un PAN doar dupa ce a efectuat o scanare activă a canalului sau o scanare ED (Energy Detection) a canalului si dupe ce arealizat o identificare a eventualelor PAN-uri deja formate. Astfel scanarea canalului permite dispozitivului FFD sa detecteze beacon-urile emise de catre un coordonator situtat in raza sa de acoperire radio (POS – Personal Operating Space).

Scanarea activă a canalului este necesara pentru o multime logică de canale, FFD-ul
comutând pe fiecare din canalele logice si transmițând comenzi Beacon Request. Pe parcursul
acestui proces dispozitivul va accepta doar mesaje beacon și va memora datele obșinute cu
privire la fiecare PAN intr-o structura interna. Dispozitivele care au roluri de coordonator
pentru PAN-uri deja active vor ignora comenzile beacon request, transmișand semanle beacon
normale. În schimb, coordonatorii PAN-urilor care nu au fost activate vor transmite mesaje
beacon singulare catre dispozitivul care a generat comanda beacon request. Alegerea unui
identificator valid pentru noul PAN, pe baza datelor obtinute in urma scanarii ramâne la
latitudinea aplicației.

Generarea semanlului beacon

Un dispozitiv FFD , in funcție de parametrii primitivei Cerere de Start din cadrul MLME,

poate genera semanle beacon, dacă el este coordonatorul PAN-ului sau dacă FFD-ul aparține unui PAN deja format; sau poate opera intr-un mod in care nu genereaza semnale beacon. Dispozitivul care nu are rolul de coordonator PAN , incepe transmisia de semanle beacon doar dupa ce a intrat intr-un PAN activ.

Asocierea și desasocierea la/ de la un PAN

Un FFD iși anunța prezența intr-un PAN prin emiterea semanlelor beacon. Prin acestea este permis unui alt dispozitiv să detecteze toate nodurile active in area s-a de acoperire radio. Dispozitivele FFd care nu au rolul de coordinator al PAN pot transmite beacon-uri doar dupa ce au fost asociate cu un PAN activ.

18

Asocierea unui dispozitiv la un PAN se face doar dupa incheierea procesului de scanare activă a canalului. FFD-ul va incerca asocierea cu un PAN doar daca acesta din urmă o permite. Selectia PAN-ului din lista de PAN-uri descoperite in vecinătatea dispozitivului este lăsată la latitudinea aplicației.

Astfel, dispozitivul care nu a fost inca asociat la un PAN transmite o cerere de asociere catre coordonatorul PAN-ului ales in urma scanării active. Coordonatorul raspunde la aceasta cerere cu un mesaj de confirmare, dar care nu semnificfă asocierea imediată a dispozitivului, deoarece premergător incheierii asocierii, coordonatorul trebuie să verifice daca resursele disponibile in acel moment in PAN permit o nouă asociere. În cazul în care noua asociere este posibila, coordonatorul alocă dispozitivului care a efectuat cererea de asociere o adresă validă pe care o transmite in interiorul unui mesaj de confirmare a asocierii la PAN. Dacă asocierea dispozitivului nu este posibilă, coordonatorul anuntă FFD-ul care a emis cererea printr-un mesaj.

Dispozitvul emițător al cererii de asociere, in momentul receptionării mesajului de confirmare a asocierii, răspunde la rândul său coordonatorului cu un mesaj de confirmare, si memoreaza adresa primită.

Desasocierea unui dispozitiv de la PAN poate fi făcută in două moduri. Nodul coordonator al PAN-ului, în momentul în care hotarăste eliminarea unui dispozitiv, emite un mesaj de notificare a desasocierii pe care-l transmite FFD-ului în cauză. Acesta din urmă raspunde cu un mesaj de confirmare a desasocierii, dar indiferent dacă recepționează sau nu această confirmare, coordonatorul consideră dispozitivul ca fiind desasociat. Pe de altă parte dacă un dispozitiv dorește sa părăsească PAN-ul, transmite un mesaj prin care anunță parăsirea PAN-ului catre coordonator și se considera desascoiat de la PAN indiferent daca primește sau nu un mesaj de confirmare.

Transmisia și recepția

Transmisia pachetelor de date, a semnaleor beacon sau a cadrelor de comenzi, la nivelul MAC
este precedata de urmatoarele acțiuni: câmpul numar de secventă al pachetului ce va fi
transmis este completat cu valoarea variabilei interne a MAC, masDSN, si incrementat cu
valoare 1; campul de adresă va fi completat cu adresa dispozitivului emițător iar campul
destinație cu adresa dispozitivului către care se transmite pachetul (pentru ambele câmpuri de

19

adrese este de preferat folosirea adreselor scurte, interne PAN-ului, in detrimentul adresei pe

64 biți a dispozitivului).

Intr-un PAN in care sunt folosite supercadre, dispozitivul emițator trbuie să detecteze beacon-ul care indica inceputulu supercadrului, ulterior putând transmite pachetele pe perioada CAP (fiind necesară folosirea CSMA-CA) sau pe perioada CFP, când utilizarea CSMA-CA nu mai este necesară; daca nu este detectat beacom-ul , transmiterea pachetului este posibilă folosind CSMA-CA fară pozitii. In PAN-urile care nu folosesc supercadre, cadrele sunt transmise folosind algoritmul CSMA-CA fară poziții.

Recepția cadrelor are o importanță sporită deoarece influențează consumul de enrgie al dispozitivului. Decizia de a permite subnivelui MAC să activeze receptorul pe durata perioadelor inactive este luat la nivel de dispozitiv. Pe durata perioadelor inactive , MAC accepta cereri pentru task-ul transciever de la nivelul superior, iar în urma soluționării acestora, MAC poate cere nivelului PHY activarea sau dezactivarea receptorului.

O alta caracteristica a MAC care permite conservarea energiei este transmiterea indirectă de pachete. Astfel dispozitivele inițiază singure tranzactiile de date fără a aștepta semnalele de la coordonator efectunând cereri catre acesta pentru a afla dacă exista mesaje in asteptare care le sunt adresate.

Structura cadrelor nivelului MAC

Fiecare cadru MPDU (MAC Protocol Data Unit) are urmatoarele componente:

o MHR, antetul nivelului MAC, contine datele necesare controlului cadrelor, numaarul
de secventa si campurile de adresă;

o Incacatura MAC, are dimensiune variablă , structura interna depinzând de tipul
cadeului;

o MFR, care contine valoarea FCS, clacultata pentru cadru.

Octeti: 2 1 0/2 0/2/8 0/2 0/2/8 Variabil 2

Control Numar de ID PAN Adresă ID PAN Adresă Incarcătura FCS

Cadru Secvență Destinație Destinație Sursă Sursă cadrului

Câmpuri de adresă

Antetul MAC (MHR) Incarcatura MFR

MAC

Figura 2.4:Formatul general al cadrului MAC

20

În cadrul LR-WPAN sunt definite 4 tipuri de cadre: cadru beacon (Figura 2.5), cadru de date (Figura 2.7), cdru de confirmare (Figura 2.8) si cadru de control MAC (Figura 2.6);

Octeti: 2 1 4/10 2 k m n 2

Control Numar de Câmpuri de Specificatii Câmpui Câmp de Incarcatura FCS

Cadru Secvență adresă Supercadru GTS Adresă Beacon

Suplimentar

Figura 2.5: Formatulu cadrului beacon

Octeti: 2 1 4/20 1 n 2

Control Numar de Câmpuri de adresă Tipul Incarcatura FCS

Cadru Secvență Comenzii Comenzii

Figura 2.6: Formatul cadrului de comanda al MAC

Octeti: 2 1 4/10 n 2

Control Numar de Câmpuri de adresă Incarcatira de Date FCS

Cadru Secvență

Figura 2.7: Formatul Cadrului de date

Octeti: 2 1 2

Control Numar de FCS

Cadru Secvență

Figura 2.8: Formatul cadrului de confirmare

2.3 Platforma hardware

Pentru realizarea și testarea protocolului de rutare MeshSPF au fost folosite 3 module de tip IRIS, avnând rolul de noduri ale rețelei, o placa de interfațare de tip MIB520 si un PC cu următoarea configuratie:

o Procesor Intel Pentium M 740 (1.7GHz) o Memorie RAM 1GB

o Harddisk cu o capacitate de 100GB

o Port USB 2.0 cu posibilitatea de virtualizare in port serial

Caracteristicile modulului IRIS și a placii MIB520 vor fi prezentate în paragrafele următoare.

21

2.3.1 Modulul IRIS

Modulul IRIS (Figura 2.9) este produs de catre firma Crossbow Technology Inc si

funcționează în standardul IEEE 802.15.4 la 2.4 GHz, având o rată de transfer de 250Kbps. El pote fi conectat prin intermediul unui conector de 51 de pini la o gamă variată de senzori. Specificațiile complete ale modulului IRIS se găsesc în Anexa 1.

Figura 2.9: Modulul IRIS

Microcontrolerul ce stă la baza platformei IRIS, Atmega1281 este un microcontroler de mică
putere din a cărei memorie flash internă rulează MoteWorks. Marele avantaj al acestui tip de
platformă este rularea simultană a aplicației de citire a senzorului conectat pe modulul IRIS și
a transmisiei / rutării wireless. Conectorul de 51 pini suportă interfețe pentru: Intrări

Analogice, Intrări/Iesiri Digitale, I2C, SPI si UART. Aceste interfețe permit conectarea usoară la o gamă variată de periferice

2.3.2 Placa de interfațare MIB520

Dispozitivul MIB520 (Figura 2.10) are rolul de a agrega totalitatea datelor colectate de rețeaua de senzori pe un computer local (PC sau altă platformă). MIB520 utilizează interfața USB (Serial virtual) atât pentru programare cât si pentru comunicații, dar aceste funcții nu pot fi folosite simultan.

Baza principală de tip MIB 520 oferă conectivitate la familiile de noduri IRIS și
MICA atât pentru comunicarea cu senzorii cât și pentru programarea acestora. Alimentarea cu
putere se face prin conexiunea USB. MIB 520 are încorporat un procesor de sistem (ISP) de

22

tipul Atmega16L. Codul este descărcat către ISP prin portul USB, mai apoi ISP încarcă codul în nod.

Programarea nodurilor de rețea presupune ca pe calculatorul la care este conectat dispozitivul MIB520 și de pe care se face programarea, să fie instalat MoteWorks/TinyOS. Nodul de tip IRIS se conectează la baza MIB520 pentru descărcarea codului prin USB și încărcarea acestuia pe nod, pentru programarea UISP (prin contact direct între nod și baza MIB520). MIB 520 utilizează portul USB ca port COM virtual. Programarea se poate face si prin aer, folosindu-se opțiunea OTAP (Over the airprogramming).

Figura 2.10: Placa de intefațare MIB520CA

Dispozitivul MIB520 dispune de un buton de RESET cu rolul de a reseta ISP-ul și procesorul nodului conectat. De asemenea resetează și softul de monitorizare care rulează pe calculatorul gazdă. MIB 520 dispune de două porturi separate. Unul dedicat programării nodurilor prin contact direct și un al doilea pentru comunicațiile prin USB, cu calculatorul gazdă.

2.4 Platforma sotware

2.4.1 TinyOS și nesC

TinyOS

TinyOS este un sistem de operare “open source” creat pentru rețelele de senzori wireless. Modul în care este proiectat TinyOS permite nivelului aplicație al rețelei să acceseze direct componentele hardware. TinyOS garantează fluxuri de date concurente către dispozitivele rețelei, asigură modularizarea componentelor hardware.

23

Prin comparație cu un sistem de operare tradițional TinyOS este mai rapid, el folosind

un model de execuție bazat pe evenimente și o arhitectură bazată pe componente care permite o dezvoltare și implementare rapidă a programelor respectând constrângerile legate de memoria nodurilor.

Componentele folosesc trei concepte computaționale:

o Comenzi

o Evenimente

o Task-uri (sarcini)

Comenzile si evenimentele sunt mecanisme pentru comunicarea dintre componente, în timp ce task-urile sunt folosite pentru a exprima funcționarea concurențială din interiorul componentelor. O comandă este în mod normal o cerere către o componentă de a executa o sarcină. Un exemplu concludent este pornirea citirii de către un senzor. Un eveniment va marca finalizarea acestui serviciu.

Evenimentele pot fi semnalizate asincron, din cauza întreruperilor hardware sau a mesajelor de sosire. Comenzile sunt analoge solicitărilor, iar evenimentele “reacțiilor”. Nici comenzile si nici evenimentele nu pot fi blocate. O comandă/cerere poate fi împărțită în segmente, iar această nu lucrează neaparat în pereche cu evenimentul ce semnalizează terminarea furnizării serviciului.

Taskurile sunt folosite pentru amâna executia calculelor ample din ineriorul comenzilor și evenimentelor. Conform modelului de execuție, task-urile vor rula până la terminare, fără întreruperi. Deoarece un task este legat de concurența internă a unei componente, el poate accesa stări numai din respectiva componentă.

În cadrul sistemului de operare TinyOS toate resursele hardware sunt văzute ca si componente, chiar și senzorii fiind abstarctizați, iar aceste componente, fie hardware sau software sunt văzute transparent de către utilizator.

TinyOS execută un singur program care constă în componentele de sistem și în componente speciale necesare pentru o anumită aplicație. Există două fire de execuție: taskuri și controlori de evenimente hardware (întreruperi). Task-urile sunt funcții a căror execuție este amânată. O dată executat, un task rulează și nu este întrerupt de un altul. Controlorii de evenimente hardware operează în scopul de a răspunde întreruperilor hardware, și de asemenea nu pot fi întrerupți din rulare până la finalizarea operației curente.

24

TinyOS poate fi implementat pe diferite platforme hardware, pentru diferite tipuri de senzori. Pot fi utilizate medii de dezvoltare avansate ce includ unelte de ajutor, de depanare a aplicației direct pe nodurile rețelei, de vizualizare si de simulare. Pentru nivelul client se pot folosi calculatoare desktop sau laptop-uri, de unde informațiile pot fi dirijate prin internet către utilizatori aflați la distanță.

NesC

Limbajul nesC, o extensie a limbajului C este un limbaj pentru programarea structurată a aplicațiilor pe bază de componente. El încapsulează conceptele și modelul de execuție al sistemului de opereare TinyOS.

Principalele concepte ale limbajului sunt:

o Separarea de construcție si de compoziție: programele sunt construite din componente,
ce sunt apoi asamblate pentru a forma unui program. Componentele sunt definite din
două perspective: una a specificării – conține numele interfețelor folosite și una a
implementării.

o Comportamentul componentelor e specificat din punct de vedere al interfețelor
folosite: Interfețele pot fi furnizate sau utilizate de componente. Interfețele furnizate
au rolul de a pune la dispoziție utilizatorului funcționalitatea componentei, iar interfața
utilizată reprezintă funcționalitatea componentei ce îsi execută sarcina.
o Interfețe sunt bidirecționale: ele specifică un set de comenzi pe care l-e va
implementa furnizorul interfeței, si un set de evenimente care vor fi implementate de
către utilizatorul interfeței. Această configurare permite interfeței să realizeze o
interacțiune complexă între componente. Aspectele anterioare sunt de mare
importanță, deoarece comenzile lungi din cadrul TinyOS (de exemplu trimiterea unui
pachet) nu pot fi blocate. Îndeplinirea acestor comenzi sunt semnalate printr-un
eveniment de anunțare a terminării cu succes. Prin specificarea interfeței, o
componentă nu poate apela comanda de trimitere până nu prevede un eveniment ce
marchează trimiterea anterioară cu succes. În manieră tipică, comenzile apelează
“downwards” (dinspre componentele aplicație cât mai aproape de partea hardware), în
timp ce evenimentele apeleaza “upwards”. Anumite evenimente primare sunt legate de
întreruperile hardware.

25

o Legarea componentelor este statică, realizată prin intermediul interfețelor: Acest lucru

sporește eficiența de rulare, încurajează proiectarea robustă, și permite o mai bună analiză statică a programelor.

o Compilarea se face asupra întregului program: NesC fiind proiectat în speranța
generării codului de compilatoarele întregului program. Aceasta permite o mai bună
generare și analiză a codului.

o Task-urile si controlul întreruperilor: Modelul concurențial al NesC se bazează atât pe
execuția completă a task-urilor, cât și pe controlorii de întreruperi, care pot întrerupe
taskurile.

Există două tipuri de componente în NesC: module și configurații. Modulele conțin codul aplicației, implementând una sau mai multe interfețe. Configurațiile sunt folosite pentru a asambla alte componente, conectând interfețele utilizate de componente cu interfețe furnizate de alte componente. Acest proces este numit cablare. Orice aplicație NesC este descrisă de o configurație de nivel superior care cablează împreună componentele.

Figura 2.11: Exemplu de aplicație în nesC

26

2.4.2 Cygwin, XServe și PostgreSQL

Cygwin

Cygwin este un mediu de emulare Unix/Linux pentru sistemele Microsoft Windows. Uneltele Cygwin sunt porturi ale popularelor unelte de dezvoltare GNU pentru Microsoft Windows. Scopul Cygwin este de a oferii utilizatorului un mediu in format linie de comandă care sa fie stabil, util și utilizabil sub Windows.

Este formată din două părți:

o un fisier dll (cygwin1.dll) care joacă rolul unui nivel de emulare API Linux, furnizând
funcționalitate substanțială de Linux API

o o colecție de unelte care oferă impresia si aspectul mediului Linux.

XServe

XServe este o aplicație care rulează in Windows sub Cygwin si care reprezintă legătura principală dintre aplicația utilizatorului și rețeaua de senzori. Funcția elementara a XServe este de a transfere date de la și la rețea ,permițind in același timp analizarea și interpretarea datelor de catre serviciile de nivel superior. Interacțiunea utilizatorului cu XServe poate fi făcută prin intermediul unui terminal prin care aplicația poate interacționa cu rețeaua direct sau folosind o interfață cu comenzi XML.

Dintre serviciile furnizate de XServe (Figura 2.12) se evidentiază următoarele două:

o Serial Forwarder: XServe adoptă acest rol pentru a permite interacțiune
directă dintre aplicație si rețea. Astfel este permisă transmitsia directa de
pachete de date in formă brută către rețea , fără a fi becesară o prelucrare de
nivel superior a acestora.

o Server pentru aplicație: în acestă ipostază, XServe, oferă posibilitatea
interpretării și procesării datelor primite de la rețea înainte ca acestea să fie
transmise către aplicație.

27

Figura 2.12: Arhitectura XServe

PostgreSQL

PostgreSQL este un sistem avansat de baze de date relaționale inclus în pachetul de instalare
MoteView produs de către Crossbow. Accesarea bazei de date PostgreSQL creată automat în
cadrul instalării pachetului MoteView se poate face prin shell-ul de comandă Cygwin prin
comanda:

psql -h localhost -U tele task

Sistemul de baze de date PostgreSQL este pus la dispoziția doritorilor gratuit, sub licență
BSD, ca o alternativă la alte tipuri de baze de date. Este foarte asemănător sistemului MySQL.
PostgreSQL este dezvoltat prin munca unei comunități răspândite la nivel global, precum și
de câteva companii dezvoltatoare, dar nu este controlat în totalitate de nici o companie.

28

2.4.3 Microsoft .NET 2.0

Microsoft .NET este o platformă software care conectează informații, sisteme și dispozitive. Unește clienți, servere și unelte de dezvoltare și are în componența sa următoarele:

o .NET Framework 2.0, folosit pentru dezvoltarea și rularea de diverse programe,
incluzând aplicații web, aplicații client inteligente, servicii web, componente care
facilitează integrarea prin împărțirea datelor și a funcționalității chiar în cadrul unei
rețele, folosind protocoale standard și independente de platformă cum XML,
HTTP. .NET Framework suportă peste 20 de limbaje diferite

o Unelte de dezvoltare, cum ar fi Microsoft Visual Studio, care pune la dispoziție un
mediu de dezvoltare integrat pentru maximizarea productivității programatorilor cu
.NET Framework.

o Un set de servere, incluzând Microsoft Windows Server 2003, Microsoft SQL Server,
Microsoft BizTalk Server, care integrează, rulează, operează și asigură managementul
serviciilor și aplicațiilor web.

Alegerea Micrisoft .NET 2.0, pentru realiazrea componentei protocolului de rutare ce
se ocupă de calcularea si gestionarea efectivă a rutelor , precum si de mentinerea si

actualizarea informatiilor despre starea rețelei la un moment dat, a fost influențată de facilitațile oferite de aceasta pentru conectarea la porturi tcp, conectarea la baza de date PostgreSQL, precum și de structura orientată pe obiecte a acesteia, asemănatoare cu cea a limbajului nesC.

29

2.4.4 XSniffer

XSniffer este o aplicație dezvoltată de către firma Crossbow care permite utilizatorilor de
rețele de senzori wireless să monitorizeze transferurile multi-hop de pachete ce au loc între
nodurile acesteia, în zona de acoperire radio a dispozitivului pe care aceasta este încărcată .
Interfața grafică prin care XSniffer prezintă datele recepționate de la rețea este prezentată în
Figura 2.13.

Figura 2.13: XSniffer

30

3. PROTOCOLUL DE RUTARE MESHSPF

3.1 Caracteristicile protocolului MeshSPF

Protocolul MeshSPF operează la nivelul Rețea din cadrul stivei de protocale 802.15.4 ZigBee,
fiind situat intre subnivelul MAC al standardului 802.15.4 și nivelurile aplicalie superioare ale
ZigBee. MeshSPF a fost creat pentru a oferii o alternativă viabilă a protocolului Xmesh, de tip
vector de distanță, dezvoltat de către firma Crossbow. MeshSPF este un protocol hibrid care
încearcă să îmbine avantajele oferite de determinarea rutelor pe baza stării legăturilor dintre
noduri (caracteristică a protocoalelor de rutare Link State), cu simplitatea implementării și cu
consumul redus de resurse pe care-l implică la nivel de nod folosirea unor rute de tip vector
de distanță.

MeshSPF propune utilizara resurselor sporite oferite de către un calculator conectat la nodul bază al rețelei de senzori wireless pentru folosirea unui algoritm coplex de calculare a rutelor. Algoritmul folosit în cadrul protocolului MeshSPF este algoritmul Dijkstra, care permite determinarea drumurilor de cost minim de la nodul bază către oricare alt nod din rețea, evintând în același timp apariția buclelor.

Arhitectural, protocolul MeshSPF are trei componente majore, Designated Router
Base (DRBase), Desiganted Router Other (DROther), MeshSPF Router (MSPFRouter).

Fiecare dintre acestea are rolul său bine stabilit în formarea unei rețele de senzori wireles și în rutarea pachetelor cu date prelvate de la senzori către aplicația creată de utilizator. Interacțiunea dintre componentele MeshSPF este prezntată în Figura 3.1.

Componenta DROther operează la nivelul nodurilor ce compun rețeaua (exceptând
nodul Bază), sub forma unuei librării ce oferă aplicației ce rulează pe nod datele necesare
transmiterii multi-hop upstream a pachetelor. Ea are două roluri bine separate în timp: inițial
permite formarea rețelei prin intermediul protocolului Discovery care stabilește modul în car
nodurile descoperă vecinii din zona proprie de acoperire radio ; apoi în urma rcepționării
pachetelor Route Update de la nodul Bază, stabilește, menține și monitorizază rutele pe care
le vor folosii nodurile pentru a transmite către aplicația utilizatorului pachetele de date.
DROther interacționează doar cu componenta DRBase a MeshSPF prin intermediul diferitelor
tipuri de pachete transmise intre cele două. Se evidnețiază ca importanță transmiterea

31

pachetelor Neighbors Advertisment, ce conțin informații depsre vecinii nodurilor, dinspre

nodurile rețelei spre Bază și receptionarea de la Bază a pachetelor Route Update , care reprezintă ultima etapă din faza de configurare a rețelei.

Componeta DRBase operează la nivelul nodului conectat la placa de interfațare
MIB520, nod ce indeplinește rolul de Bază a rețelei de senzori wireless. DRBase este aplicația
care rulează pe acest nod, aplicație care are doar sarcinia de a transmite pachet de la și înspre
rețea, nefiind implicată în colectarea de informații prin intermediul senzorilor. Din
perspectiva protocolului de rutare, DRBase constituie legătura dintre rețeaua de senzori și
modulul însărcinat cu formarea topologiei și calcularea rutelor, modul situat pe calculatorul la
care este conectată rețeaua (prin MIB520). Astfel DRBase transmite spre MSPFRouter

pachetele Neighbors Advertisment ce conțin starea legăturiilor dintre noduri; transmite spre nodurile DROther pachetele Route Update ce conține ruta calculată de MSPFRouter pentru un anumit nod; permite comunicare sigură intre cele două componente prin intermediul mesajelor de confirmare pe care le generează în momentul recepțioării pachetelor Neighbors Advertisment, și pe care le solicită după transmiterea de Route Update.

Componenta MeshSPF Router, constitue elementul central al protocolului MeshSPF, ea fiind responsabilă de formarea rețelei prin intermediul drumurilor de cost minim către bază pe care le calculează pe baza grafului nodurilor pentru fiecare din nodurile rețelei. Spre deosebire de celelate două componente care sunt implementate sub forma de librării sau aplicații scrise in limbajul nesC, MSPFRouter este o aplicație C# realizată folosind Microsoft .NET 2.0.

MSPFRouter interacționează direct doar cu DRBase, legăura dintre cele două fiind
relizată prin serviciul XServe oferit de Crossbow. Schimbul de pachete dintre cele două se
face folosind protocolul Serial Forwarder, oferit de XServe și constă în schimbul de pachete
în formă brută (șiruri de biți), interpretarea acestora fiind responsabilitatea fiecărei

componente la nivel local. Pe lângă cele prezentate până acum, mai trebuie precizat și faptul
că MSPFRouter folosește și baza de date PostgreSQL pusă la dispoziție de către XServe
pentru a menține cantitatea mare de informații cu privire la legăturile dintre noduri , ptovenită
de la rețea.

În continuare vor fi prezenate structurile pachetelor folosite de către MeshSPF pentru
transmiterea mesajelor specifice protocolului și mesajelor ce conțin date preluate de la
senzori.

32

Figura 3.1: Arhitectura MeshSPF

3.1.1 Pachetul Single-hop (TOS_Msg)

Pachetele transmise în cadrul protocolului MeshSPF sunt pachete de tip TinyOS, de aceea

indiferent de scopul pe care îl au, ele vor fi încapsulate in interiorul pahcetului TinyOS

prezentat în Figura 3.2.

Octeți: 2 1 1 1 Variabil 2

Addr Type Group Length Data CRC

Antetul TinyOS Încărcătura TinyOS

Figura 3.2: Structura pachetului TinyOS

Semnificația câmpurilor pachetului TinyOS este următoarea:

o Addr: este adresa nodului destinație al pachetului la nivel local (hopul următor la care
va ajunge pachetul ).

o Type : specifică tipul mesajului încapsulat in interiorul pachetului TinyOS.

33

o Group: specifiă id-ul asignat grupului de noduri ce formează rețeaua de senzori

wireless. Acest atribut perimte existența mai multor rețele în acași zonă geografică.

o Length: specifică dimensiunea datelor încapsulate în interiorul pachetului TinyOS.

o CRC: acest câmp conține valoarea „cyclic redundancy check” calculată de către nod
înainte de a transmite pachetul și verificată de destinație pentru a detecta posibilele
erori care au apărut pe parcursul transmisiei.

3.1.2 Pachetul Multi-hop UpStream (TOS_MHopMsg)

Pachetul MeshSPF Multi-hop UpStream este folosit în cadrul protocolului pentru transmiterea de mesaje de rutare sau de date dinspre nodurile rețelei de senzorii spre nodul bază al acesteia. Acest tip de pachet este încapsulat in interiorul unui pachet TinyOS și are structura prezentată în Figura 3.3.

Octeți: 2 2 1 1 Variabil

SourceAddr OriginAddr SeqNo Socket Data

Figura 3.3: Structura anteteului Multi-hop UpStream

Semnificația câmpurilor pachetului Multi-hop UpStream sunt următoarele:
o SourceAddr: adresa ultimului nod expeditor al pachetului;
o OriginAddr: adresa nodului care a generat pachetul;
o SeqNo: nuărul de secvență al pachetului;
o Socket: id-ul aplicație căreia pachetul îi este destiant;

o Data: încărcătura pachetului, poate conține mesaje de la provenite de la nivelul
superior sau mesajele interne protocolului MeshSPF.

3.1.3 Pachetul Multi-hop DownStream (TOS_DSMsg)

Pachetul MeshSPF Multi-hop DownStream este folosit în cadrul protocolului pentru transmiterea de mesaje interne protocolului de rutare dinspre nodul bază al rețelei de senzori wireless spre nodurile acesteia. Acest tip de pachet este încapsulat in interiorul unui pachet TinyOS și are structura prezentată în Figura 3.4.

34

Octeți: 1 2 1 2 2 Variabil

Socket SeqNo RoadLen Road[0] Road Data

[RoadLen-1]

Figura 3.4: Structura anteteului Multi-hop DownStream

Semnificația câmpurilor pachetului Multi-hop DownStream sunt următoarele:
o Socket: id-ul aplicație căreia pachetul îi este destiant;

o SeqNo: nuărul de secvență al pachetului;

o RoadLen: dimensiunea drumului pe care trebuie să-l parcurgă pachetul către destinație o Road: adresele nodurilor prin care trebuie să treacă pachetul în drum sore destinție (șir
de tipul părinte-copil)

o Data: mesajul ce se dorește a fi transmis către nod (de exmplu un paachet de tip Route
Update )

3.2 Componenta Designated Router Other

Aceasta este componenta protocolului de rutare situată pe toate nodurile rețelei cu excepția nodului bază. Aceste noduri pot avea unul din următoarele două roluri în cadrul unei topologii stabile a rețelei de senzori wireless: nodul poate fi un nod terminal al rețelei fiind responsabil doar de preluarea informației de la senzori și de transmiterea acesteia catre bază (printr-un singur hop sau multi-hop); nodul poate avea rol de router, el trebuind să transmită către bază pe lângă pachetele generate local și pachetele provenite de la alte noduri.

Functiile principale ale componentei Designated Router Other a potocolului MeshSPF sunt:

o sondarea propiei zone de acoperire radio pentru a detecta prezența altor noduri și
estimarea calității legăturii cu fiecare dintre acestea;

o alegerea unui nod „părinte” inițial, prin care nodul să poată transmite bazei o cerere
de intrare in rețea, sub forma unor pachete ce conțin estimate ale calității legaturilor
dintre nod și vecinii acestuia;

o recepționrea unui mesaj Route Update de la bază prin care nodul este informat ca
poate patrunde in rețea și care conține „parintele” nodului curent (parintele nodului
va fi nodul cu rol de router prin care nodul curent va transmite pachetele de date si de
protocol destinate bazei);

35

o monitorizarea legaturilor dintre un nod al rețelei și nodurile cu rolul de copil sau

părinte al acestuia.

Fiecareia dintre aceste funcții ale nodului cu rol de DROther (din perspectiva protocolului
de rutare), îi este asociată o stare (Discover, Advertise, Wait și Route). În paragrafele

următoare vor fi prezentate în detaliu fiecare dintre aceste stări precum și eventualele protcoale de comunicare folosite.

3.2.1 Starea Discover și Protocolul Discovery

Starea Discover

În momentul activării unui dispozitiv, privind din perspectiva protocolului de rutare MeshSPF, acesta se află în starea Discover. Un nod aflat în acestă stare nu face încă parte din rețeaua funcțională de senzori wireless, în care pentru a pătrunde, nodul trebuie mai întâi să-și sondeze zona de acoperire radio pentru a putea detecta eventualele dispozitive care aparțin rețelei și va completa informațiile cu privire la calitatea legăturii cu fiecare dintre aceste noduri intr-o tablă internă.

Dintre nodurile descoperite, va fi ales ca și prim „părinte” al nodului curent, nodul care implică cel mai mic cost de transmisie către nodul bază al rețelei, iar prin acest părinte nodul va transmite bazei tabela cu situația legăturior nodului. Baza va răspunde printr-un mesaj de confirmare a recepționării pachetelor cu informațiile despre vecinătatea nodului, mesaj care va provoca tranziția nodului curent în starea Wait.

Protocolul Discovery

Protocolul Discovery oferă unui nod mijloacele necesare pentru a pătrunde intr-o rețea de
noduri wireless care folosește protocolul de rutare MeshSPF. El precizează formatul
pachetelor beacon pe care nodul le transmite pentru a sonda vecinătatea, structura tabelei care
va păstra informațiile cu privire ca calitatea legăturiilor dintre nodul curent si vecinii acestuia,
algoritmul de calcul folosit pentru calcularea calitații legăturii dintre noduri precum și
algoritmul de calcul al costului total de transmisie catre bază și de alegere al unui părinte
inițial.

36

Trebuie evidențiată importanța procesului Discover pentru intregul protocol

MeshSPF, deaorece acest proces permite o estimare calitativă foarte bună a legăturilor dintre
nodul care dorește să intre in rețe și vecinii acestuia. Astfel pe baza informațiilor obținute pe
durata stării discover va fi determinată poziția pe care nodul o va ocupa in rețea, subliniind
faptul că un nod aflat intr-o poziție favorabilă din perspectiva minimizării costului de
transmisie către bază trebuie să aibe un rol de router și nu doar de simplă frunză a rețelei.

Intervalele de timp ale prtocolului Discovery

Intervalul de timp elementar folosit in cadrul protocolului MeshSPF este denumit Puls Interval și are o durată standard de 36 secunde. Din perspectiva protocolului Disocvery, pe baza intervalului de puls sunt definite două perioade:

o Perioada Discover: precizează durata totală a procesului Discover efectuat de un nod
care dorește să pătrundă in rețea; durata acesteia este de 20 intervale de puls; sfărșitul
acestei perioade coincide cu efectuarea operației de selectare finală a părintelui;
o Rata de estimare (Estimate Ratio): are o durată de 5 intervale de puls și indică
momentul in care nodul va calcula estimatele legăturilor cu fiecare dintre vecinii săi și
va alege un părinte provizoriu pe baza informațiilor din Tabelul Vecinilor.

Deasemenea, pe parcusul stării discoverii, la fiecare interval de puls, nodul transmite
broadcast un pachet Discovery Beacon, a cărui rol si structură sunt orezentate in paragraful
următor.

Pachetul Discovery Beacon

Aceste pachete sunt emise la fiecare interval de puls, pe toată durata stării discover, de către
nodurile care intenționeză să pătrundă in rețea. Întrebuințarea acestui tip de pachete trebuie
privită din două unghiuri. Astfel, din perspectiva nodului emitent, pachetele sunt folosite
pentru ca acesta să-și anunțe prezența și pentru a solicita nodurilor care fac deja parte din
rețea să emită pachete de confirmare pentru ca nodul să poată estima calitatea legaturilor cu
aceștia (se formează astfele perechi discovery beacon – discovery beacon ackwoledge).

37

Din perspectiva nodului care recepționeza un pachet Discovery Beacon, putem

identifica alte doun situații: nodul receptor se află deja in rețea (starea Route), caz ce va fi prezentat in subcapitolul 3.2.4 Starea Route și Protocolul Hello; nodul receptor nu face parte din rețea. În acest al doi-lea caz, receptorul va folosii datele incluse de către emițător pentru a iniția sau actualiza inregistrarea din Tabelul Vecinilor asociată acestuia.

Pachetele Discovery Beacon sunt încapsulate în pachete Multi-hop UpStream și sunt transmise boradcast astfel încât să poată fi recepționate de către toți vecinii nodului emitent. Structura unui astfel de pachet este prezentată in Figura 3.5, iar semnificațiile câmpuriilor acestuia sunt utmătoarele:

o Type: indică tipul pachetului din perspectiva protocolului de rutare (pentru discovery
beacon fiind specificat tipul DISCOVERY_BEACON, care are valoarea 0x73)
o Parent: indică id-ul părintelui nodului emitent la un moment dat.
o Cost: indică costul de transmisie upstream către bază, pentru a putea permite altor
noduri care nu fac incă parte din rețea să aleagă un parinte cât mai bun.
o Listă vecini: nodul emitent precizează mai intâi numarul de vecin, despre care
transmite informații în pachet (EntriesNo), iar apoi include o listă cu id-urile si

estimatele vecinilor (ReceiveEst). Trebuie precizat numărul de vecini incluși pentru că
datorită dimensiunii scăzute a unui pachet TinyOS, în interiorul acestuia nu vor putea
fi incluși toți vecinii nodului în situația in care Tabela Vecinilor este plină. În acestă
situație vor fi incluse in pachet, secvențial, porțiuni succesive din Tabela Vecinilor.

Octeți:1 2 2 1 2 1 2 1

Type Parent Cost EntriesNo Id 1 ReceiveEst1 Id n ReceiveEstn

Figura 3.5: Structura pachetului Discovery Beacon

Tabela Vecinilor

Reprezintă structura interna a nodului DROther în care sunt păstrate pe parcursul stării
Discover informațiile cu privire la legăturile dintre nodul curent și vecinii acestuia. O
inregistrare din această tabelă conține următoarele patru tipuri de date: date privind identitatea
nodului (id, cost transmisie, distanța în „hopuri” față de bză ), contoare de pachete (numarul
de pachete recepționate sau pierdute de la acest vecin, numărul de secvență al ultimului pachet
primit), date privind calitatea legăturii dintre nod și vecin, date priviind starea înregistrării.

38

Introducerea unui nod în Tabela Vecinilor se face in momentul recepționării unui
pachet Discovery Beacon de la acesta. Datorită memoriei reduse de care dispune un nod, in
tabel pot fi menținute informații doar pentru 15 vecini, din acest motiv in momentul în care se
încearcă introducerea unui nou vecin in tabela plină, trebuie eliminat vecinul cu cea mai mică
calitate a legăturii. Actualizarea contoarelor de pachete și a datelor cu privire la identitatea
nodului se face la primirea unui pachet Discovery Beacon sau Discovery Beacon
Acknowledge.

Estimarea legăturilor

Aceasta este relizată de către nod pe parcursul stării Discover, la expirearea unui interval ESTIMATE_RATIO (echivalentul a 5 intervale de puls), și presupune aplicarea algoritmului EWMA (Exponetially Weighted Moving Average) pentru fiecare nod din Tabela Vecinilor. Astfel pentru a estima legătura cu un vecin sunt folosite următoarele formule:

EstimatNou

Estimat Re ceptie

255 * Pachete Re ceptionate

Pachete Re ceptionate PachetePie rdute

( 1 ) Estimat Re ceptie EstimatNou

În care α este denumit factorul EWMA, fiind o valoare cuprinsă intre 0 și 1 ce indică ponderea noului estimat al legăturii.

Pe lânge estimatul legăturii la recepție, ân Tabela Vecinilor, nodul păstrează și un estimat al legăturii la transmisie, primit de către nod de la vecin prin intermediul pachetelor Discovery Beacon transmise de acesta, și constând de fapt în estimatul la recepție pe care îl calculează vecinul pentru legătura dintre cele două noduri.

În plus față de cele prezentate anterior trebuie precizat faptul că la nivel de nod
valorile celor două estimate (de transmisie și de recpție) sunt normalizate astfel îcât să aibe
valorile cuprinse intre 0 și 255, valoarea 255 semnificând o calitate perfectă a legăturii dintre
noduri.

39

Calularea cosutrilor de transmisie și selecția primului părinte

Calcuarea costului și selecția unui părinte se relizează la expirarea ficărui interval de estimare pentru a permite nodului să propage și informații cu privire la adâncimea sa din punct de vedere al distanței față de nodul bază (numărul de hopuri). Foarte important din perspectiva protocolului de rutare este însă selecția finală a unui părinte, care are loc la expirarea intervalului Disocover Period, deoarece prin intermediul acestui părinte, nodul va transmite mesajele Neighbors Advertisment (conțon inregistrările din Tabla Vecinilor) către nodul bază pentru ai solicta acestuia calcularea unei rute nod curent – nod bază, permitându-i astfel nodului curent pătrunderea în rețeaua de senzori wireless.

Metrica folosită de către protocolul MeshSPF pentru estimarea calității unei rute este costul minim de transmisie către bază, astfel pentru fiecare nod din Tabela Vecinilor va fi calculat atât costul legăturii dintre noduri, precum și costul total de transmisie prin acest vecin către bază. Formulele de calcul sunt următoarele:

CostLegatu ra

( 1 18 )

,

Estimat Re ceptie EstimatTra nsmisie

CostTotal CostLegatura CostNod

unde costul nodului este obținut prin intermediul pachetelor Discovery Beacons sau Discovery Beacons Ack.

Alegerea nodului părinte se face dintre nodurile din Tabela Vecinilor care implică un număr de hopuri până la bază minim (obligatoriu mai mic decât cel al nodului curent), pe baza criteriului costului minim de transmisie. Este evident, ținândcont de primul crteriu al selecție că baza are prioritate deoarece este singurul nod cu numar de hopuri 0. Un nod poate fi candidat pentru rolul de părinte dacă satisface urmăoarele condiții:

o să nu considere nodul curent ca și părinte;

o să aibe ales un părinte prin care să poată transmite mai departe informațiile provenite
de la copii.

o să aibe un estimat al legăturii de minim 25.

40

Dacă în nodul nu reușește să găsească un vecin care să satisfacă toate cerințele pentru a deveni părinte al nodului curent, acesta reia, după o periodă de așteptare întreg procesul Discover.

3.2.2 Starea Advertise

Nodul trece în starea Advertise doar dacă, la încheierea procesului Discover a reușit să găsească un vecin pe care să-l considere părinte și prin care să poată transmite către nodul bază datele din Tabelul Vecinilor.

Informațiile cu privire la vecinii nodului sunt transmise bazei prin intermediul
pachetelor Neighbors Advertisment. Acestea sunt încapsulate în interiorul unui pachet Multi-
hop UpStream care va conține adresa locală a nodului în câmpurile OriginAddr și
SourceAddr. Pachetul multi-hop este îcapsulat la rândul său într-un pachet TinyOS care are ca
adresă destinație, adresa bazei (uzual 0) si este de tipul AM_MULTIHOPMSG. Pachetul
TinyOS astfel creat este transmis de către nodul curent spre vecinul ales ca și părinte.

În momentul recpționării unui pachet primit de la unul dintre copii săi, părintele analizează antetul TinyOS al pachetului pentru a deteremina destinatarul. În cazul pachetelor Neighbors Advertisment, destinatarul este nodul bază, astfel fiecare dintre nodurile intermediare situtate intre nodul care a generat pachetul și bază vor transmite pachetul mai departe (forward), dar doar după ce și-au introdus propria adresă în câmpul SourecAddr din header-ul de multi-hop.

Structura pachetului Neighbors Advertisment este prezentată în Figura 3.6. În

interiorul acestora nodul emitent include id-ul fiecărui vecin și costul legăturii dintre cele două noduri. Dată fiind dimensiunea redusă a unui pachet TinyOS și a numărului maxim de vecini pe care un nod îi poate păstra în Tabela Vecinilor, poate aprărea situația în care expedierea unui singur pachet Neighbors Advertisment să nu fie suficientă pentru ca acesta să conțină toți vecinii nodului. Din aceste considerente , pachetele Neighbors Advertisment sunt trasmise sub forma unei secvețe de astfel de pachete. Pentru a putea identifica un anumit pachet din acestă secvenșă, în antetul Neighbors Advertisment a fost inclus câmpul AdvertiseNo. Transmimsia efectivă a Tabele Vecinilor unui nod se incheie prin transmiterea unui pachet care are în câmpul NumărAdvertisment valoarea 254.

Transmiterea pachetelor Neighbors Advertisment de la un anumit nod către bază este
realizată intr-o manieră sigură, pentru fiecare pachet recepționat de la un anumit nod , baza

41

trebuie să transmită DownStream un pachet Neighbors Acknowledge. Recepționarea unei

secvențe este considerată incheiată doar după primirea pachetului cu AdvertiseNo egal cu
254. Privind din perspectiva nodului, acesta așteaptă , după transmiterea unui adintre

pachetele Neighbors Advertisment din secvență, primirea unui mesaj Neighbors

Acknowledge care să aibe AdvertiseNo egal cu cel așteptat de nod, pentru a transmite următorul pachet.

Durata de timp în care nodul așteaptă sosirea confirmării recepției ultimului Neighbors Advertisment transmis, de la bază este specificată de catre intervalul MAX_ADVERTISMENT_WAIT. Dacă expiră acest interval fără ca nodul să recepționeze confirmarea așteptată, este retransmis ultimul pachet Neighbors Advertisment. Transmisia pavehtelor Neighbors Advertisment către bază eșuează dacă este depășit numărul maxim de retransmisii permise pentru un pachet.

Octeți: 1 2 2 1 1 2 2 2 2

Type Parent HopCount AdvertiseNo NbrsNo Id 1 LinkCost 1 Id n LinkCost n

Figura 3.6: Structura pachetului Neighbors Advertisment

3.2.3 Starea Wait

Nodul ajunge în starea Wait după ce reușește transmiterea cu succes a Tabelei Vecinilor prin intermediul pachetelor Neighbors Advertisment către Bază. Pe durata acesteia nodul nu transmite nici un tip de pachete indiferent de pchetele primite de la alte noduri (sunt ignorate inclusiv pachetele Discovery Beacons). Dealtfel singurele pachete pe care nodul l-e acceptă sunt pachetele de tip Route Update.

În momentul recepționării unui pachet Route Update (Figura 3.7) de la bază, nodul
analizează inițial câmpurile antetului Multi-hop DownStream pentru a vedea dacă acest
pachet îi este adresat. Din acest punt de vedere pentru nod prezintă ineters câmpurile Road și
RoadLen a căror verificare permite nodului să decidă dacă pachetul îi este detinat sau nu
(pachetul îi este adresat nodului dacă adresa acestuia se află în șirul Road la poziția RoadLen-

1).

Dacă în urma analizei prezentate anterior, nodul decide că pachetul nu îi este destinat,
renuță la pachet. Altfel nodul înlătură antetul DownStream și folosește informațiile de rutare
incluse în pachetul Route Update pentru a configura ruta pe care o va folosii pentru

42

transmiterea pachetelor către nodul bază. Astfel nodul își va actualiza adresa părintelui, costul total de transmisie și numărul de hopuri care-l despart de bază .

În momentul în care nodul și-a configurat datele necesare rutării (transmiterii

upstream) de pachete, are obligația să transmită către bază un mesaj de confirmare prin care informează bază că este pregătit să transmită mesaje de date upstream și pachete Route Update, downstream, către nodurile aflate la o depărtare mai mare de bază (din perspectiva numărului de hopuri).

După tranmiterea cu succes a confirmării primiri informațiilor de ruatre, nodul trece în starea Route.

Octeți: 1 2 1 2 2 1 2 2

Socket SeqNo RoadLen Road[0] Road Type Parent Cost

[RoadLen-1]

TOS_DownStreamMsg Route Update

Figura 3.7: Structura pachetului Route Update

3.2.4 Starea Route și Protocolul Hello

Starea Route

După recepționarea informațiilor necesare rutării de pachete upstream, nodul părăsește starea Wait și intră în starea Route. Aceasta din urmă este starea pe care nodurile o au în momentul în care rețeaua este stabilă și pregătită să preia informațiile de la senzori și să l-e transmită către bază. În starea Route nodul îndeplinește patru funcții principale: rutarea pachetelor, întreținerea și monitorizarea rutelor (Protocolul Hello), propagarea downstream a pachetelor Route Update, oferirea posibilități de intrare în rețea a nodurilor noi.

Rutarea pachetelor de date

Rutarea pachetelor de date este funcția de bază pe care o oferă protocolul MeshSPF.
Principial ea presupune preluarea pachetelor de date de la nodurile situate pe nivelele
inferioare ale ierarhiei rețelei (copi ai nodului receptor), și transmiterea upstream spre

părintele nodului.

Destinația finală a pachetelor ce conțin date preluate de la senzori este în marea
majoritate a cazurilor nodul bază (existând și posibilitatea agregării pachetelor de date la nivel

43

de nod). Astfel nodul preia infomațiile de la senzori, le introduce în pachetele specifice

aplicației și transmite aceste pachete nivelului Rețea di cadrul stivei de protocoale ZigBee (implicit protocolului MeshSPF).

Protocolul MeshSPF încapulează pachetele de date provenite de la nivelele superioare,
adăugând antetul Multi-hop UpStream, necesar propagării pachetelor către bază și transmite
pachetul nou creat nivelelor inferioare pentru transmisia lor efectivă. Fiecare hop din drumul
pachetului către bază pasează aceste pachete nivelului Rețea care le decapsulează, analizează
adresa finală, actualizează antetul multi-hop și transmit pachetul mai departe spre următorul
hop.

La nivel de nod informațiile despre ruta pe care o parcurg pachtele în drumul lor spre bază sunt păstrate sub forma adresei părintelui nodului, costul transmisiei prin acest părinte și adâncimea nodului exprimată ân numărul de hopuri (noduri) ce despart nodul curent de bază. Protocolul MeshSPF permite accesul nivelelor superioare la ceste informații de rutare prin intermediul interfeței Route Control

Propagarea pachetelor Route Update

Din momentul în care un nod intră in stare Route, pe lângă transmiterea pachetelor de date către bază, nodul are și sarcina de a transmite downstream pachetele Route Update către nodurile ce vor devenii copi ai nodului curent.

Astfel în momentul recepționării de la părinte a unui pachet downstream ce conține încapsulat un pachet Route Update, nodul analizează câmpul Road pentru a determina care este următorul hop. Dacă în urma analizei nodul nu poate determina care este următorul hop , renunță la pachet, altfel îl transmite mai departe spre destinația finală.

Emiterea de Discovery Beacon Acknowledge

Nodurile aflate în starea route trebuie să permită eventualelor noduri noi să pătrundă în rețea. Pentru aceasta ele au posibilitatea de a genera pachete Discovery Beacon Acknowledge, pe care l-e transmit ca răspuns la recepționare de pachete Dicovery Beacon.

Pachetele de confirmare sunt încapsulate în ineriorul unui pachet Multi-hop upstream
și vor fi transmise către adresa de Broadcast, permitând astfel tutror nodurilor pentru care sunt

44

utile să l-e recepționeze. Structura unui pachet Discovery Beacon Acknowledge este prezentată în Figura 3.8.

Octeți: 1 2 1 2

Type ParentID HopCount TotalCost

Figura 3.8: Structura pachetului Discovery Beacon Acknowledge

Protocolul Hello

Rolul protocolului Hello este de a întreține și de a monitoriza legăturile dintre nodul curent, copii și părintele acestuia, precum și de a detecta eventaulele schimbări ale topologie și de a informa baza despre acestea. Protocolul Hello poate fi împărțit în trei module, fiecare dintre acestea având sarcini bine stabilite.

Întreținerea Rutei UpStream

Din momentul în care trece în starea Route, nodul inițiază protocolul Hello, transmițând pachete Hello Msg către părintele său . Acetea suntr transmise la fiecare interval de puls și sunt folosite pentru a păstra activă legătura dintre nod și părinte.

Părintele la rândul său are obligația de a transmite pachete Hello Acknowledge către copii săi. Acestea sunt introduse în pachete Mhop Downstream și transmise Broadcast la fiecare 5 intervale de puls. Copilul monitorizează statutul legăturii cu părintele pe baza acestor mesaje, el considerând că a pierdut legătura cu părintele dacă nu recepționeză trei pachete Hello Acknowledge consecutive. În momentul pierderii legăturii cu părintele, nodul se consideră scos din rețea și trece în starea Discover.

Monitorizarea legăturilor cu copii nodului

Privind din perspectiva unui nod părinte, protocolul Hello presupune menținerea unui Tabel al
Copiilor nodului prin intermediul căruia sunt monitorizate legăturile dintre nod și copii săi.
Acest tabel este creat folosind structura de date care pe parcursul stării Discover conținea
datele despre vecinii nodului (în momentul trecerii nodului în starea Route, Tabelul Vecinilor
este golit).

45

Un nod, copil al nodului curent este introdus în Tabelul Copiilor în momentul

recepționării unui prim pachet Hello Msg de la acesta. Vor fi folosite în continuare contoarele de pachete pentru monitorizarea stării legătruii dintre copil și nodul curent. Astfel în momentul recepționării unui pachet Hello de la copil, nodul calculează diferența dintre numărul de secveță al pachetului și ultimul număr de secvemță recepționat de la acest copil și păstrat in Tabelul Copiilor. Părintele consideră invalidă legătura cu un copil dacă diferența acesta depășește pragul MISSED_HELLOS (10 pachete).

Pe lângă acestă metodă de detectare a legăturilor invalide, părintele menține pentru fiecare dintre copii săi , numărul de intervale de puls care au trecut de la ultimul pachet Hello recpționat. Astfel dacă acest număr depăște pragul impus prin HELLO_IDLE_PERIOD (15 impulsuri de puls), părintele consideră invalidă legătura cu acest copil. În ambele situații prezentate, părintele informează nodul bază de pierderea legăturii cu unul dintre copii săi prin intermediul pachetelor Topology Change.

Detectare aschimbărilor de topologie.

Cele trei situații prin care un nod poate detecta pierdera legăturii cu unul dintre vecinii săi

(părinte sau copil) au fost prezentate în paragrafele anetrioare. Responsabilitatea nodului este de a informa nodul bază de aceste shimbări prin intermediul pachetelor Topolgy Change (Figura 3.9).

Octeți: 8 1 2

TOS_MhopMsg Header Type NeighborID

Figura 3.9: Structura pachetului Topology Change

3.3 Componenta Designated Router Base

Componeta Designated Router Base a protocolului MeshSPF este aplicația ce rulează pe
nodul Bază al rețelei de senzori wireless, permițându-i acestuia să gestioneze eficeint traficul
de mesaje dinspre rețeaua de senzori spre srverul de date XServe sau spre o altă aplicație. Din
perspectiva rutării, DRBase conlucrează cu componenta MeshSPFRouter a protoclului, având
rolul de a propaga spre calculaotr mesajele ce conțin legăaturile dintre nodurile rețelei
(Neighbors Advertisment) și de a transmite nodurilor, mesjele Route Update generate de către
calculator,

46

DRBase are la bază aplicația TinyOS, TOSBase, care este folosită ca și o punte de legătura intre portul serial al calculatorului la care este conectată placa de interfațare MIB520 și interfața radio a acesteia. Astfel mesajele provenite de la portul serial vor primii „eticheta” ce conține id-ul grupului asociat cu rețeaua de senzori , iar mesajele provenite de la rețea prin interfața radio vor fi filtrate tot în funcție de acest id de grup.

Modul în care DRBase realizează comunicarea intre portul seria și intrefața radio este
prezentat succint în subcapitolul 3.3.1, iar extensiile ce conferă componentei DRBase un rol
de nod bază din perspectiva protocolului MeshSPF sun prezenta în subcapitolele 3.3.2 și

3.3.3.

3.3.1 DRBase: legătura dintre rețea și aplicație

DRBase moștenește rolul de punte între portul serial al calculatorului și interfața radio a nodului IRIS ce are rolul de Bază a rețelei de senzori wireless de la aplicația TinyOS, TOSBase.

Pentru interacțiunea cu portul serial la care este conectată (prin MIB520), aplicația DRBase ce rulează pe nodul cu rol de Bază, folosește facilitățiile de încapsulare și decapsulare a pachetelor, provenite de la sau destinate nivelului Rețea al ZigBee, oferite de modulul FarmerM produs de către Intel Corporation și care operează la subnivelul nivelul MAC al ZigBee.

Pentru a putea gestiona eficient fluxul de pachete provenite de la nodurile rețelei și
destinate transmiterii pe portul serial către o anumită aplicație sau către componenta
MeshSPFRouter, DRBase înmagazinează intr-un registru intern de tip LIFO aceste pachete,
transmițând spre portul serial un nou pachet, doar dupe ce cel precedenta fost transmis.

Transmiterea de pacehte pe interfața radio este realizată de către DRBase folosind interfața RadioCRCPacket produsă de către Crossbow Technology în colaborare cu Intel Corporation și cu Universitatea „Berkeley” din California, USA. La nivel local, DRBase adaugă pacetelor destinate nodurilor rețelei de senzori eticheta ce conține id-ul grupului. În plus pentru o mai buna gestiune a transmisiei, este folosit și in acest caz un registru intern de tip LIFO pentru înmagazinarea pachetelor inainte de relizarea efectivă a transmisiei în cazul în care fuluxul de date depășește puterea de transmisie a bazei.

47

3.3.2 Protocolul Discovery

În momnetul in care un dispozitiv este activat, el sondează zona propire de acoperire radio
pentru a detecta rețele de senzori existente. Nodul folosește protocolul Disocvery pentru a
estima legăturile cu celelalte noduri detectate și pentru a alege nodul cel mai potrivit pentreu a
transmite crerea (sub forma pachetului/lor NeighborsAdvertisment) de intrare în rețea. Pentru
a permite intrarea în rețea , protocolul Disocvery forma semnalelor pe care un nod aflat deja
în rețea trebuie să l-e genereze în momentul în care receptionează un mesaj Discovery
Beacon.

Nodul Bază al rețelei, care rulează componenta Designated Router Base a protocolului de nivel Rețea, MeshSPF, are un rol foarte important în formarea rețelei, el fiind nodul însăricant cu calcularea rutelor pentru noile noduri. Mai exact el face legătura intre nodurile rețelei și componenta MeshSPFRouter a protocolului, cea care calculează efectiv rutele folosind resursele oferite de calculatorul pe care rulează.

Astfel protocolul Disocvery prevede ca în momentul în care DRBase detectează un semanl Discovery Beacon, transmis de un nod care sondează vecinătatea, să transmită o serie de cinci semale Base Beacons , pe parcursul a cinci intervale de puls, prin intermediul cărora să permită nodului nou să aleagă Baza ca și prim părinte.

Semnalele Base Beacons au o structură mult simplifată față de Disocvery Beacons, ele
având rolul doar de a anunța prezența Bazei în vecinătatea nodului, lucru sufieicent pentru a
permite alegerea bazei ca și prim părinte, aceasta fiind singurul nod cu numărul de hopuri 0.
Astfel mesajul Base Beacon constă intr-un pachet Multi-hop gol transmis boradcast de către
Bază.

3.3.3 Protocolul Hello

Nodul Bază, deși nu este dotat cu senzori pentru prelevarea de date de la mediu, are un rol activ în rețeaua de senzori wireless, el fiind responsabil de transmiterea pachetelor de date provenite de la nodurile rețelei spreaplicația utlizatoruli pentru a fi interpretate. De aceea nodul Bază deține rolul de părinte pentru cel puțin un nod în cadrul rețelei active.

Astfel aplicația DRBase a fost extinsă pentru a implementa protocolul Hello, folosit în
cadrul MeshSPF pentru mențiinerea rutelor și detectarea eventualelor schimbări ale

48

topologiei. DRBase folosește o Tabelă a Copiilor, similară cu cea de pe nodurile ce folosesc modulul DROther, prin intermediul căreia monitorizează sitația legăturiilor cu fiecare dintre copii săi. Fiecare înregistrare din tabel conține id-ul copilului, numărul de secvență al ultimului pachet Hello primit de la acsta, un câmp idlePeriod, care contorizeză numărul de intervale de puls care au trecut fără ca baza să primească un pahcet Hello de la nod, si un byte de flag-uri care evdențează starea copilului.

Există două posibilități prin care Baza poate detecta dacă a pierdut legătura cu unul
dintre copii săi. În momentul recepționării unui pachet Hello de la un copil, baza calculează
diferența dintre numărul de secvență al acestui pachte și valoarea câmpului LastSeqNo din
Tabelul Copiilor. Dacă diferența dintre cele două depășește valoarea MISSED_HELLOS,
legătura cu acest copil este considerată invalidă. A doua metodă de detectare a legăturilor
invalide se bazează pe câmpul idlePeriod asociat fiecărui nod. Astfel după trecerea fiecărui
interval de puls, baza incrementează cu o unitate valoarea din acest câmp și verifică ca aceasta
să nu depășească valoarea HELLO_IDLE_PERIOD. În cazul unei depășiri baza consideră
legătura cu acest copil invalidă. În momentul în care este detectată pierdera legăturii cu unul
dintre copii săi, baza generează un pachet Topology Change pe care îl transmite către
MeshSPF Router.

Din momentul recepționării primului pachet Hello de la unul din copii săi , bază începe să transmită broadcast , la fiecare 5 intervale de puls pachete HelloAck, DownStream, pentru a permite copiilor monitorizarea legăturii cu baza. Aceste Hello Ack sunt transmise de către bază atât timp cât există minim un nod în Tabela Copiilor.

3.3.4 Pachetele Neighbors Advertisment și Route Update

Rolul DRBase în ceea ce privește formarea rețelei este evidențiat de pachetele Neighbors Advertisment pe care le primește de la noduri și de pachetele Route Update primite de la MeshSPFRouter.

Astfel în cazul primului tip de pachete , DRBase trebuie să se asigure că fiecare dintre pachetele ce compun o scevență Neighbors Advertisment transmisă de un nod , ajunge la MeshSPF Router, de aceea Baza transmite pachete de confirmare pentru fiecare pachet al secvenței recepționat, transmisia următorului pachet din secvența de Neighbors Advertisment, la nivel de nod fiind condiționată de recepția confirmărilor de la Bază.

49

În cazul pachetelor Route Update transmise spre un anumit nod al rețelei , DRBase

trebuie să se asigure că mesajul de confirmare generat de nod în urma recepției rutei, ajunge la MeshSPF Router.

3.4 Componenta MeshSPF Router

MeshSPF Router este componenta protocolului de rutare responsabilă cu claculul rutelor
logice ce leagă nodul Bază de celelalte noduri ale rețelei de senzori wireless. Această
componentă se dorește a fi o extensie a aplicației DRBase, care având acces la resursele
calculatorului, să ofere posibilitatea calculării de rute minime către Bază pentru fiecare din
nodurile rețelei, aplicând algorimul Dijkstra pentru determinarea drumurilor de cost minim
într-un graf.

Comunicarea între DRBase și MeshSPF Router se face prin intermediul serviciului XServe oferit de către firma Crossbow prin pachetul MoteWorks. În plus, MeshSPF Router folosește pentru păstrarea informațiilor legate de legăturile dintre noduri precum și Tabela de Rutare, baza de date PostgreSQL care însoțește XServe.

MeshSPF Router poate fi împărțit în cinci componente majore, fiecare dintre ele având sarcini bine stabilite. În subcapitolele următoare va fi prezentat modul în care fiecare dintre aceste componente ale MeshSPF Router folosește resursele disponibile pentru a realiza sarcinile care i-au fost impuse. În Figura 3.10 este prezentată arhitectura MeshSPF Router sub forma interacțiunii dintre obiectele ce o compun (fiind vorba de o dezvoltare a acesteia în limbajul orientat oe obiecte C#, ficărei componentă îi este asociat un obiect) .

Figura 3.10: Argitectura MeshSPF Router

50

3.4.1 Clientul Serial Forwarder

Clientul Serial Forwarder este componenta MeshSPF Router care are rolul de a oferi un canal de comunicare între acesta și XServe. Legătura cu rețeaua de senzori folosind XServe se face respectând protocolul Serial Forwarder.

Acesta prevede mai întâi respectarea unui protocol de conectare care presupune transmiterea a doi octeți de date, dintre care primul conține valoarea zecimală 84 iar al 2-lea valoare zecimală 32, dacă se folosește versiunea 1 a protocolului , sau valoarea 33 pentru folosirea versiunii 2 (aceasta presupune transmiterea a încă patru bytes ce vor fi folosiți pentru identificarea platformei nodurilor folosite).

Protocolul Serial Forwarder este extrem de simplu el permițând transmiterea de
pachete de date în format brut deoarece se bazează pe nivelul Data Link al stivei de
protocoale TCP/IP care asigură o transmisie sigură a pachetelor. Singura regulă care trebuie
respectată este de a transmite inițial un octet ce va conține lungimea pachetului, iar apoi vor fi
transmiși restul octeților. Trebuie precizat că pentru a putea transmite pachete spre rețeaua de
senzori prin intermediul XServe, MeshSPF Router trebuie să includă la sfărșitul pachetului și
valoarea CRC clculată pentru acesta (algoritmul de calcul al crc este prezentat în [X, pagina
Y] ). Structura pachetului Serial Forwarder este prezentată în Figura 3.11.

Componenta SerialForwarderClient are la bază un obiect de tipul
System.Net.TcPClient prin intermediul căruia se conectează la socketul aplicației XServe
(localhost:9001). Deasemenea componenta mai oferă obiectelor care o foloses și două obiecte
de tipul NetworkStream, unul pentru transmisia și celălalt pentru recepția datelor de la
XServe. Modul în care serviciile Serial ForwarderClient sunt folosite de celelalte
componente ale MeshSPF Router va fi evidențiat în momentul prezentării acestora.

Octeți: 1 Variabil 2

Length Data Payload CRC

Figura 3.11: Structura pachetului Serial Forwarder

51

3.4.2 Clientul PostgreSQL

MeshSPF Router folosește baza de date PostgreSQL inclusă in pachetul MoteWorks pentru a menține datele despre legăturile dintre nodurile rețelei necesare pentru calcularea rutelor, precum și a Tabele de Rutare. Astfel în baza de date sunt definite trei tabele, MeshDB, RoutingTab și StatusTab.

Tabela MeshDB conține toate legăturile existente intre nodurile rețelei de senzori
wireless. Ea este completată de către firul de execuție receptor de pachete, pe baza
informațiilor cu privire la legăturile dintre un nod și vecinii săi, incluse în pachetele
Neighbors Advertisment. O înregistrare din tabela MeshDB conține adresele celor două
noduri ce definesc o legătură , costul acestei legături, un câmp stare. înregistrarea poate avea
la un moment dat una din următoarele trei stări: înregistrare nouă (valoarea 1), dacă nu a fost
încă folosită de către firul de execuție central pentru calcularea rutei pentru unul sau ambele
noduri ce o definesc; înregistrare procesată (valoarea 2), dacă a fost folosită de către firul
central în momnetul calculării unei rute; înregistrare invalidă (valoarea 3), dacă a fot primit un
pachet Topology Change care informează MeshSPF Router că unul dintre nodurile ce
dlimiteză legătura nu mai face parte din rețea. Tabela MeshDB poate fi accesată la un
momnet dat de unul dintre firele de execuție ReceiveData sau Engine.

Tabela RoutingTab conține rutele calculate de către EngineThread pentru nodurile
rețelei de senzori wireless. O înregistrare a acestei tabele conține adresa nodului pentru care
este caculată ruta, adresa părintelui , costul total de transmisie de pachete ccătre Bază, si un
câmp status care indică starea rutei (transmsă, netransmisă, invalidă). În tabela RoutingTab
sunt adăugate date de către EngineThread în urma calculării de rute noi pe baza informațiilor
noi din MeshDB. TransmiterThread preia rutele din această tabelă și incearcă transmiterea lor
către nodurile rețelei. ReceiverThread modifică statutul înregistrărilo din RoutingTab pe baza
mesajelor Route Acknowledge sau Topology Change recepționate de la rețea.

Tabela StatusTab este folosită pentru a informa firele de execuție de existența datelor noi în cele două tabele ale MeshSPF Router. În acest sens StatusTab conține câte un flag pentru fiecare din cele două. Acesta este setat sau resetat de către firele de execuție ori de câte ori este nevoie.

Clientul PostgreSQL este implementat prin intermediul unui obiect
System.Data.Odbc.OdbcConnection și a mai multor metode ce permit introducerea, ștergera,

52

modificarea sau preluarea datelor din tabelele incluse în baza de date PostgreSQL, oferite spre utilizare firelor de execuție ce compun MeshSPF Router.

Figura 3.12: Tabelele PostgreSQL

3.4.3 Firul de execuție ReceiveData

ReceiveData este componenta MeshSPF Router responsabilă cu recepționarea de pachete de la rețeaua de senzori. După cum a fost precizat anterior, pachetele sun recepționate prin intermediul XServe, iar comunicarea cu acesta este făcută respectându-se protocolul Serial Forwarder. Pentru a putea primi pachete de la rețea, ReceiveData folosește obiectul ReceiverStream oferit de componenta SerialForwarderClient.

Pachetele ajung la ReceiveData în formă brută, el fiind responsabil de interpretarea acestora. Principalele tipuri de mesaje al e protocolului de rutare recepționate sunt: Neighbors Advertisment, Route Acknowledge și Topology Change. Acțiunile pe acre firul de execuție responsabil cu recepția le inteprinde în momentul recepționării acesora sun prezentate în paragrafele următoare.

În momentul recepționării unui pachet sau a unei secvențe de pachete de tipul
Neighbors Advertisment, ReceiveData decapsulează antentul TOS_Msg si antetul
TOS_MhopMsg pentru a putea accesa lista de vecini și estimate ale legăturilor acestora cu
nodul emitent al pachetului. Folosind metodele oferite de către clientul PostgreSQL,
ReceiveData introduce în tabela MeshDB datele cu privire la legăturile dintre noduri.

53

Recepționarea unui pachet Route Acknowledge , indicând primirea cu succes a rutei

calculate de MeshSPF Router, de către unul din nodurile rețelei, solicită firului de execuție ReceiveData să șteargă pachetul Route Update asociat nodului, din Registrul de Transmisie, și să actualizeze starea rutei în tabela RoutingTab (starea rutei va devenii „transmisă”).

Pachetele Topology Change provenite de la rețeaua de senzori au rolul de a informa MeshSPF Route de pierderea legăturii dintre un nod și unul dintre copii acestuia. Protocolul de rutare MeshSPF prevede ca în momentul în care unul din nodurile rețelei nu mai poate ruta pachete spre Bază , eliminarea acestuia din rețea și recalcularea rutelor pentru nodurile care au considerat nodul exclus ca și părinte. Din aceste considerente ReceiveData, trebuie să modifice atât starea înregistrărilor din tabela MeshDB cât și pe cele ale rutelor care indică ca și părinte nodul ieșit din rețea. De asemenea el informează firul de execuție Engine de aceste modificări prin setarea flag-urilor aferente în StatusTab.

Implementarea în .NET 2.0 a ReceiveData are la bază, după cum indică și denumirea acestuia, un obiect de tipul System.Threading.Theard. Acșiunile pe care acesta le relizează pe durata rulării sun specificate în metoda engineReceiveData , metod transmisă ca perametru lui ThreadStart. ReceiveData este pornit în momentul conectării la XServe și rulează atât timp cât acestă conexiune ste deschisă.

3.4.4 Firul de execuție TransmitData

Firul de execuție TransmitData este responsabil cu transmisia de pachete către rețeaua de senzori, transmisie relizată prin intermediul serviciului XServe și respectând specificațiile protocolului Seria Forwarder. Tipul principal de pachete pe care acesta le generează și l-e transmite este Route Update.

Pachetele Route Update conțin informațiile de rutare pentru un anumit nod al rețelei.
Ele sunt încapsulate în inetriorul unui pachet Multi-hop DownStream și sun transmise către
componenta DRBase a protocolului de rutare MeshSPF. Un pachet Route Update conține
adresa părintelui nodului destinație precum și costul transmiterii de pachte prin acesta către
Bază. În antetul Multi-hop DownStream , TranmsitData introduce atât lungimea drumului pe
care pachetul Route Update trebuie să-l parcurgă, pornind de la Bază și îcheiindu-se cu nodul
detinație care primește informațiile de rutare, cât și fiecare nod prin care pachetul trebuie să
treacă.

54

Firul de execuție TransmitData verifică periodic starea tabelei RoutingTab prin intermediul flag-ului asociat acesteia în StatusTab. În momentul în care detectează informații noi în RoutingTab, folosește metodele oferite de clientul PostgreSQL pentru a l-e accesa și pentru a crea pachetle Routing Update.

Firul introduce mai întâi pachetele Route Update nou create în TransmitRegister, iar
apoi încearcă transmiterea tuturor pachetelor din acet registru către DRBase. În Transmit
Register sunt păstrate la un moment dat toate pachetele Route Update nou create precum și
cele pentru care nu s-a primit încă o confirmare a recepției de la nodul detianție. Din acest
motiv, firul de execuție TrnamsitData transmite periodic întreg conținutul TransmitRegister,
considerând că oachetele Route Update create anterior nu au ajuns la destinație.

3.4.5 Firul de execuție central (Engine)

Engine după cum sugerează și denumirea acestuia este componenta MeshSPF Router care este responsabilă de calculul rutelor pentru nodurile rețelei de senzori. Pentru calcularea rutelor pe care nodurile le vor folosi pentru transmisia către Bază (upstream) a pachetelor cu datele preluate de la senzori, a fost ales algoritmul Dijkstra care permite calcularea drumurilor de cost minim de la un nod la toate celelate nodrui dintr-un graf.

Prin folosirea algoritmului Dijkstra se rezolvă una dintre cele mai grave probleme cu care se confruntă protocolalele de rutare folosite de către rețelele de senzori și nu numai. Este vorba de formarea buclelor de rutare. Acestea presupun, în cadrul rețelelor wireless, în cel mai simplu caz, ca un nod să aleagă în rolul de părinte unul dintre copii săi, putând apărea și bucle ce cuprind mai multe noduri , făcând detecția și corectaea mult mai dificile (în Figura Z este prezentată o buclă ce cuprinde mai multe noduri). Crearea unei bucle în cadrul unei rețele duce la scăderea dramatică a performanțelor acesteia și în cele mai multe cazuri la pierdera de date foarte importante. Protocolul de rutare MeshSPF propune o rezolvare eficientă a acestei probleme, calcularea rutelor folosind algoritmul Dijkstra asigură generarea de rute optime și evită posibilitatea formării de bucle.

Componenta Engine monitorizează în permanență situația tabelei MeshDB prin intermediul StatusTab. În momentul în care detectează existența de informații noi în MeshDB, indicând solicitarea unor noduri de a intra în rețea, realizează opearțiile prezentate în paragrafele următoare.

55

Pe baza informațiilor valide din MeshDB , se creează un graf al rețelei. Graful constă

într-un obiect de tipul MeshDBGraf și conține toate legăturile existente intre nodurile care aparțin deja rețelei, precum și intre nodurile noi ce doresc să pătrundă în rețea. Pe baza informațiilor din MeshDB, Engine determină și care sun nodurile pentru care trebuiesc calculate rute.

Următorul pas pe care Engine trebuie să-l realizeze este acela de a calcula efectiv rutele pentru nodurile noi. Acest lucru îl relizează prin aplicarea algoritmului Dijksra asupra obiectului MeshDBGraf. Vor fi astfel create două șiruri, unul de tipul părinte-copil, ce va conține drumurile de cost minim de la bază spre oricare din nodurile rețelei, denumit SPFTree, și unul ce va conține costurile minime de transmisie spre bază pentru aceste perechi de noduri părinte-copil, denumit MinCost.

Ținând cont de nodurile pentru care există informații noi în MeshDB, Engine determină noile rute pe baza SPFTree și MinCost și l-e introduce în tabela RoutingTab. În plus Engine resetează flagul din StatusTab asociat lui MeshDB, indicând faptul că a folosit informațiile noi pentru a calcula rute, și anunță firul de execuție responsabil de transmisia de pachete către rețea, că există rute noi în RoutingTab.

56

4. STUDIU DE CAZ: COMPARAREA PROTOCOLULUI
MESHSPF CU PROTOCOLUL XMESH

Scopul acestei lucrări este dezvoltarea protocolului de rutare MeshSPF respectând normele
imupse de standardul IEEE 802.15.4 ZigBee. Privind din perspectiva modului în care

MeshSPF își claculează rutele logice pe care le folosește pentru transmisia pachetelor către nodul Bază și ținând cont de modul în care fiecare nod gestionează procesul de rutare, putem spune că acest protocol este un hibrid între un protocol de tipul Link State și unul de tip Distance Vector.

Sarcinile impuse protocolului MeshSPF sunt asigurarea unui consum redus de energie prin reducerea numărului de pachete necesare pentru realizarea și menținerea topologiei logice a rețele; sporirea stabilității și robusteții rețelei, fiind importantă tratarea problemei apariției buclelor de rutare; asigurarea unei viteze ridicate pentru transmisia datelor. Pentru a o imagine cat mai clară a rezultatelor obținute , s-a relizat o comparare a protocolului MeshSPF cu protocolul de rutare XMesh creat de firma Crossbow. Caracteristicile protocolului XMesh vor fi prezentate succint în paragraful următor.

4.1 Caracteristicile protocolului Xmesh

XMesh este protocolul de rutare multi-hop, ad-hoc, dezvoltat de către firma Crossbow pentru rețele de senzori wireless . În esența ei, o rețea wireless ce folosețe pentru rutarea de pachete , protocolul XMesh, este formată din noduri dotate cu senzori, capabilie să transmită pachete multi-hop (de la un nod la altul) către un nod central. Prin folosire transmisie multi-hop se obțin două mari beneficii: este extinsă suprafața pe care rețeaua o poate acoperii, crescând totodată și siguranța oferită de acesta pentru preluarea și transmiterea de date.

O rețea XMesh este caracterizată prin următoarele funcții de bază:

o Auto-organizare și auto-vindecare;

o Transmisia de pachete către nodul bază (upstream), și dinspre bază spre
nodurile rețelei (downstream);

o Permite atât transmisia broadcast (limitată la zona de acoperire radio a

nodului), cât si unicast, între oricare două noduri ale rețelei.

57

o Ofera QoS (Calitatea Serviciului) prin posibilitatea transmiterii de mesaje de

confirmare (acknowledge) la nivel de legătura sau end-to-end, între bază și nodul emitent al unui mesaj;

o Ofera posibilitatea funcționării nodului pe trei nivele de energie: HP (High
Power – putere ridicată), LP (Low Power – putere scăzută) și ELP (Extended
Low Power);

o Permite sincronizarea temporală intre noduri.

Tabelul următor prezintă performanțele protocolului XMesh ținând cont de nvelul de energie folosit.

Parametru

Route Update Interval

Rata Transmisie Date
Timp Convergență

Consum de Energie

XMesh-HP XMesh-LP XMesh-ELP

36 sec. 360 sec. 36sec./360sec.

10 sec. 180sec. N/A

2, 3 intervale RUI pentru rețele de diametru 2.5
20-30 mA <250µA 50 µA

Tabel 4.1: Performanțele XMesh

Formarea și menținerea unei rețele bazate pe protocolul de rutare XMesh presupune folosirea paralelă a unui proces de estimare a legăturilor dintre noduri și a unui proces de selecție a părintelui unui nod (nodul prin care se face rutarea upstream). Estimarea legăurilor dintre noduri se face aplicând algoritmul EWMA asupra estimatului dat de către nod legăturii pe baza pachetelor Route Updates transmise și recepționate. Selecția unui nod părinte se face ținând cont de costul total al transmiterii de pachete către bază pe care acesta îl implică. Selecția părintelui este efectuată la trecerea unei perioade echivalente a 8 Route Update Interval (RUI), considerată suficientă pentru luarea de decizii valide.

58

4.2 Definirea indicatorilor de calitate

Pentru analizarea și comporarea performanțelor obținute de către cele două protocoala de rutare , MeshSPF și XMesh, au fost definite următoarele indicatoare de calitate:

o Timp de Convergență (TC) : intervalul de timp necesar pentru formarea unei
topologii logice stabile a rețelei de senzori wireless. Este calculat ca fiind diferența
dintre momentul transmiterii primului pachet de configurare al protocolului de rutare
și momentul transmiterii primului pacht de date de către unul din nodurile rețelei.

o Viteza de Rutare (VR): este definită ca fiind intervalul de timp scurs între

transmiterea către bază a două pachete succesive de date de către un nod al rețelei. (A fost aleasă această metodă de calcul deoarece intrvalul de timp la care datele sunt preluate de la senzori și transmise către bază este specificat prin intermediul timere-lor folosite de aplicația ce rulează la un moment dat pe nod).

o Flux de Pachete (FP): reprezintă numărul de pachete aparținând protocolului de
rutare (necesare formării sau menținerii topologiei) emise și recepționate de către un
nod în intervalul de timp scurs între transmisia a două pachete de date succesive emise
de acesta.

o Încărcătura Computațională (IC): acest indicator de calitate se referă la cantitatea
de calcule efectuate la nivel de nod al unei rețele de senzori wireless, necesitată de
protocolul de rutare pentru calculul metricii și/sau determinarea rutelor folosite.

59

4.3 Rezultate experimentale

Testearea protocolului MeshSPF, precum și compararea acestuia cu protocolul XMesh s-a
realizat folosind patru dispozitive de tip IRIS și două păci de interfațare de tip MIB520.
Dintre acestea, pe unul dintre modulele IRIS, montat pe o placă MIB520, a fost icărcată
aplicația XSniffer dezvoltată de către firma Crossbow pentru a permite ,monitorizarea

traficului de pachete din rețea.

Unul din nodurile rămase a fost încărcat cu aplicația Designated Router Base și a
îndeplinit rolul de nod Bază al rețelei, el fiind conectat prin intermediul aplicației XServe la
componenta MeshSPF Router a protocolului MeshSPF. Celellalte două noduri rămase au fost
pozițonate în așa manieră încât să formeze o rețea multi-hop (o pereche copil – părinte).

Pe nodurile rețelei, atât în catul folosirii MEshSPF cât și în cel al folosirii XMesh a fost încărcată aplicația TinyOS, NetCountToLeds, care utilizează un timer intern de tipul TIMER_REPEAT pentru a incrementa o variabilă count, care numără evenimentele Timer.fired() declanșate de expirarea perioadei acestuia. De asemenea a mai fost folosită și interfața LedsC pentru a permite afișarea valorii variabilei count prin intermediul led-urilo cu care modulul IRIS este dotat. Aplicația folosește pe rând unul din cele două protocoale de rutare pentru a transmite valorile variabilelor count de pe cele două noduri, către nodul Bază, având setată o periodă de transmise spre acesta de 20 secunde.

În plus trebuie meționat că intervalele Route Update Interval (RUI) al XMesh și
Interval de Puls (IdP) al MeshSPF au fost setate la 4 secunde. MeshSPF a fost configurat
astfel încât să aibe o comportare optimă dat fiind diametrul scăsut rețelei (diametreu 2): durata
stării Discovery a fost setată la 8 IdP (realizndu-se astfel și o concordanță cu XMesh), iar
perioada necesară strângerii de informații pentru estimarea legăturii dintre noduri a fost setată
la 4 IdP .

60

4.3.1 Timpul de Convergență

În cazul folosirii protocolului MeshSPF, pe baza rezultatelor preluate de la Xsniffer (Figura

4.1) a fost calculată următoarea valoare a indicatorului Timp de Convergență:

Considerând:

t1 = momentul transmiterii primului pachet Discovery Beacon de către nodul cu id-ul 1899, t2 = momentul transmiterii primului pachet de către nodul 1899;

TC = t2 – t1 = 1585,875 – 1511,781 = 74,094 (secunde)

Figura 4.1: XSniffer – stările MeshSPF Discover și Advertise

61

Folosind protocolul XMesh s-a obținut următorul rezultat (Figura 4.2): Considerând:

t1 = momentul transmiterii primului pachet Route Update de către nodul cu id-ul 13, t2 = momentul transmiterii primului pachet de către nodul 13.

TC = t2 – t1 = 493,203 – 469,314 = 23,889 (secunde)

Figura 4.2: XSniffer – configurarea rețelei XMesh

Analizând rezultatele obținute, iese în evidență avantajul pe care XMesh îl are în datorită calculării rutelor la nivel de nod, și nu centralizat precum protocolulul MeshSPF. Trebuie precizat că aceste rezultate erau previzibile, pentru formarea topologiei logice a MeshSPF preferându-se folosirea unui algoritm complex, precum Dijkstra, care permite calculul de rute optime și eleiminarea buclelor de rutare chiar din momentul determinării rutelor dar care necesită o putere de calcul net superioară celei oferite de dispozitivele IRIS.

62

4.3.2 Viteza de Rutare

Acest indicator de calitate a fost calculat în cazul ambelor protocoale, pe baza rezultatelor oferite de XSniffer (Figura 4.3, Figura 4.4), facându-se o medie a vitezelor de rutare folosind informațiile oferite de către ambele noduri ale rețelei:

Cazul MeshSPF:

Interval transmisie aplicație (Iap) = 20 (secunde);

Nodul 1899: VR 1899 t 2t 1

Nodul 26: VR 26 t 2t 1 Iap

Iap 1606 406 1585

1615 609 1595 , 093

VR 1899 VR 26

875 20 0 , 531 (sec unde ) ,

20 0 , 516 (sec unde ) ,

VR

Cazul XMesh:

2

0 , 5235

Interval transmisie aplicație (Iap) = 20 (secunde);

Nodul 13: VR 13 t 2t 1 Iap

Nodul 3: VR 3 t 2 t 1 Iap

513 718 493 203

5156 990 496 453

VR 13 VR 3

20 0 , 515 (sec unde ) ,

20 0 , 537 (sec unde ) ,

VR

2

0 , 5260

Figura 4.3: XSniffer – pachete de date transmise folosind MeshSPF
63

Figura 4.4: XSniffer – pachete de date transmise folosind XMesh

Din rezultatele obținute se observă faptul că pentru o rețea de diametru redus (în acest caz 2), ambele protocoale de rutare oferă aproximativ aceleași viteze de rutare. Totuși MeshSPF are un mic avantaj, care tinde să crească vertiginos pe măsura ce diametrul rețelei crește deoarece rutele calculate de acesta folosind algoritmul Dijkstra sunt întotdeauna optime, în schimb rutele calculate de XMesh fiind optime la nivel local (pe vecinătatea nodului).

4.3.3 Fluxul de Pachete

Monitorizând rețeaua de senzori cu ajutorul XSniffer, se pot oberva cu ușurință pachetele pe care MeshSPF și XMesh l-e folosesc pentru formarea și menținerea topologiilor logice (Figura 4.3, Figura 4.4).

Astfel în cadrul rețelei formate cu ajutorul MeshSPF, în intevalul de timp dintre transmisia a două pachete de date, Nodul 1899 a transmis 5 pachete Hello către părinte și a recepționat 5 pachete Hello de la nodul cu rol de copil (Nodul 26) și un pachet Hello Acknowledge de la părinte (Nodul 0), rezultând o valoare, FP = 11 pachete;

Nodul 13 din cadrul rețelei formate prin intermediul XMesh, a transmis, în intevalul
de timp dintre transmisia a două pachete de date, 5 pachete Route Update și a recepționat 4

64

pachete Route Update emise de nodul bază (id 0) și 5 pachete Route Update emise de nodul 3, rezultând o valoare a FP = 14 pachete.

Se observă avantajul pe care protocolul MeshSPF îl oferă in ceea ce privește numărul de pachete necesare protocolului de rutare, obținșndu-se un mare avantaj și în ceea ce privește consumul de energie. Astfel pentru o rețea de diametru 7, ce poate avea câteva sute de noduri , se diferența dintre cele două protocoale în ceea ce priveșste numărul de pachete de rutare procestae de un nod devine foarte consistentă.

4.3.4 Încărcătura Computațională

În ceea ce privește acest indicator de calitate, urmărind rezultatele obținute cu ajutorul XSniffer (Figura Z), iese în evidență numărul mare de operații de estimare a legăturilor și alegere a părintelui pe care un nod dintr-o rețea XMesh îl relizează. Acestea duc la un consum suplimetar de enregie și implicit la scurtarea perioadei de utilizare a nodului.

Protocolul MeshSPF propune mutarea sarcinii de calcul al rutelor în seama unui calculator și de propagare a acestora în rețea prin intermediul nodului bază. Astfel un nod al rețelei efectuează operații de estimare a legăturilor și de calcul al părintelui doar pe parcursul stării Discover. Din momentul în care nodul recepționeză ruta pe care o va folosii de la nodul Bază, îi rămân doar sarcini de minitorizare a acesteia, care implică un consum mult mai mic de resurse și de energie în comparație cu un nod dintr-o rețea XMesh.

65

5. CONCLUZII

Rețele de senzori wireless au cunsocut o dezvoltare acceuntuată în ultimii ani datorită sarcinilor complexe pe care le pot îndeplinii și a prețului din ce în ce mai scăzut. Datorită numărului mare de noduri pe care le poate avea o astfel de rețea , dezvoltarea unui protocol de rutare care să respecte constrangeriile acesteia devine o temă de cercetare extrem de interesantă dar și de dificilă.

Lucrarea de față și-a propus dezvoltarea unui protocol de rutare care să poată fi
integrat în standardul IEEE 802.15.4 ZigBee. Astfel protocolul MeshSPF a fost proiectat și
dezvoltat astfel încât să asigurare un consum redus de energie și să propună o topologie
logică a rețelei stabilă, care să ofere viteze ridicate de transmitere a datelor preluate de la
senzori.

Cele mai bune rezultate au fost obținute în ceea ce privește reducerea consumului de
energie la nivel de nod, mărind astfel durata de utilizare a acestuia. În această direcție,
dezvoltarea MeshSPF s-a axat pe reducerea numărului de pachete necesare pentru realizarea
și menținerea topologiei logice a rețelei. Au fost create protocoale precum protocolul
Discovery și protocolul Hello, specializate pe îndeplinirea anumitor sarcini pe care un
protocol de rutare l-e presupune. Astfel protocolul Discovery este responsabil de sondarea
vecinătății unui nod pentru ai permite acestuia să pătrundă cât mai rapid în rețea. În schimb
protocolul Hello intervine doar în momentul în care rețeaua este deja formată, fiind
responsabil de menținearea rutelor create și de detecția eventualelor schimbări ale topologiei.

Un alt element foarte important în ceea ce privește reducerea consumului de energie
este utilizarea componentei MeshSPF Router a protocolului dezvoltat. S-a urmărit astfel
privirea dintr-o nouă perspectivă a modului în care sunt calculate rutele foloiste pentru
transmiterea datelor în rețea. S-a urmărit preluarea responsabilității determinării rutelor de la
nodurile rețelei, care dispun de resurse limitate, atribuind-o unei componenete ce se folosește
de puterea de calcul oferită de un calculator. A fost permis astfel rețelei să folosească
algoritmul complex Dijkstra pentru calcularea de rute optime, drumuri de cost minim, din
perspectiva costului de transmisie către bază. Prin interemediul folosirii algoritmului propus
de Dijkstra s-a rezolvat intr-o manieră eficientă și problema formării buclelor de rutare.

66

Dintre dezavantajele folosirii unei metode centralizate de calcul a rutelor, poate cel mai important este mărirea timpului de convergență necesar configurării inițiale a rețelei, diferențele între MeshSPF și XMesh din acest punct de vedere fiind destul de mari.

Pe de altă parte, calcularea de rute la nivel de nod presupune folosirea unor algoritmi mult inferiori lui Dijkstra și provocând astfel generarea de rute suboptimale care necesită o recalculare periodică.

Dezvoltarea viitoare a protocolului MeshSPF poate fi axată atât pe testarea de diferiți
algoritmi ce pot fi folosiți pentru calculuarea rutelor (de exmplu algoritmul DUAL –

Diffusing Update ALgorithm), cât și pe extinderea tabelelor de rutare la nivel de nod pentru a oferii o mai mare stabilitate.

67

6. BIBLIOGRAFIE

[1] Sinem Coleri Ergen, ZigBee/IEEE 802.15.4 Summary,

http://pages.cs.wisc.edu/~suman/courses/838/papers/zigbee.pdf.

[2] “MoteWorks Getting Started Guide”, Crossbow MoteWorks 2.0, Revision E,

Aprilie 2007.

[3] “XMesh User’s Manual”, Crossbow MoteWorks 2.0, Revision D, Aprile 2007.

[4] “XServe User’s Manual”, Crossbow MoteWorks 2.0, Revision E, Aprile 2007.

[5] “MoteWorks Getting Started Guide”, Crossbow MoteWorks 2.0, Revision E,

Aprile 2007.

[6] Philip Lewis, TinyOS Programming, Revison 1.2, Iunie 2006.

[7] David Gay, Philip Levis, David Culler, Eric Brewer, nesC 1.1 Language Reference

Manual, Mai 2003.

[8] Thomas Haenselmann, Sensornetworks, Aprilie 2006.

[9] The PostgreSQL Global Development Group, PostgreSQL 7.3.2 User’s Guide.

[10] http://en.wikipedia.org/wiki/Dijkstra's_algorithm

68