Algortimi DE Rutare In Retele Wireless

INTRODUCERE

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țelelor de senzori wireless.

S-a obținut astfel pe de-o parte reducerea 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 într-o 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 realiza 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ă.

CAPITOLUL 1

RETELE DE CALCULATOARE – NOTIUNI GENERALE

1.1. Conceptul de rețea

Rețeaua de calculatoare (network) este un ansamblu de calculatoare (sisteme de calcul) interconectate prin intermediul unor medii de comunicație (cablu coaxial, fibră optică, linie telefonică, ghid de unde) în scopul utilizării în comun de către mai mulți utilizatori a tuturor resurselor fizice (hardware), logice (software de bază și aplicații) și informaționale (baze de date, fișiere), asociate calculatoarelor din rețea.

În general, toate rețelele au anumite componente, funcții și caracteristici comune, printre acestea sunt următoarele:

Servere – calculatoare care oferă resurse partajate pentru utilizatorii rețelei.

Clienți – calculatoare de lucru (terminale, stații de lucru) care accesează resursele partajate în rețea de un server.

Mediu de comunicație – Modul și elementele în care sunt conectate calculatoarele în rețea.

Date partajate – Fișiere puse la dispoziție de serverele de rețea.

Imprimante sau alte periferice partajate.

Resurse – Fișiere, imprimante și alte componente care pot fi folosite de utilizatorii rețelei.

Rolul principal al unei rețele este de a permite partajarea următoarelor trei categorii de resurse:

Resurse fizice

Resurse logice

Resurse informaționale

Partajarea resurselor fizice reprezintă posibilitatea utilizării în comun, de mai mulți utilizatori, a unităților de discuri, imprimante, scanere. Acest lucru înseamnă că se poate instala oricare dintre unitățile enumerate mai sus, după care urmează operațiile de partajare (sharing). În urma declarării partajate a unui echipament, toate calculatoarele din rețea au acces la acest echipament.

Partajarea resurselor logice (programe). Resursele logice ale unui calculator sunt de fapt, ansamblul de programe sistem sau de aplicații.

Partajarea resurselor informaționale (baze de date, fișiere).

1.2. Evoluția rețelelor

Rețelele sunt prezente în aproape toate mediile de lucru. O rețea este un mecanism care permite calculatoarelor distincte și utilizatorilor acestora să comunice și să partajeze resurse.

Rețelele au fost inițial soluții de conectivitate brevetate, parte integrantă a unui pachet de soluții informatice.

Configurațiile tipice includeau terminale simple, care erau cablate la controlere de dispozitiv.

Controlerele de dispozitiv asigurau accesul comun, sau multiplexat, la resursele de comunicare, ce asigurau conectivitatea cu sistemele mainframe. Aceste resurse de comunicare erau reunite într-un procesor front-end (FEP) al sistemului mainframe. FEP permite mai multor resurse să partajeze un singur canal către mainframe. Datorită diferențelor dintre viteza de intrare/ieșire și viteza procesoarelor sistemului mainframe, această soluție era cea mai eficientă din punct de vedere financiar.

Altfel, era utilizată o linie închiriată cu lărgime de bandă mică, pentru traversarea distanței geografice până la mainframe.

În aceste medii, aplicațiile software erau executate doar pe un calculator cu un unic sistem de operare. Sistemul de operare putea fi executat numai pe produsele hardware ale aceluiaș distribuitor. Chiar și echipamentul terminal și conexiunile la calculator făceau parte din aceeași soluție integrată a unui singur producător.

Au apărut apoi două direcții de dezvoltare tehnologică, care au schimbat cursul viitor al informaticii. În primul rând au apărut strămoșii PC-urilor de astăzi.

În al doilea rând a început căutarea de modalități de îmbunătățire a productivității proprii. S-a căutat în special un mijloc de îmbunătățire a partajării datelor și fișierelor între stațiile de lucru.

Soluția lor a fost prima rețea locală (LAN ), pe care au numit-o ethernet. Aceasta era o rețea LAN rudimentară care se baza pe protocoale de nivel superior pentru inter-rețele. Potențialul comercial al acestei tehnologii a devenit imediat evident. Ethernet-ul original, cunoscut acum ca PARC Ethernet, sau Ethernet I, a fost ulterior completat de o versiune cu un comportament mai bun. Această soluție cunoscută ca DIX Ethernet sau Ethernet II, a fost dezvoltată de Xerox, Digital și Intel.

Aceștia au stabilit „standardele” pentru Ethernet II și au produs tehnologiile sale componente.

Împreună, dispozitivele inteligente ale utilizatorilor și rețelele locale vor da naștere unui nou model: prelucrare deschisă, distribuită, în rețea a datelor.

1.3. Organizațiile de standardizare

Succesul pe care l-a avut Ethernet I și Ethernet II a demonstrat că piața era sătulă de abordarea brevetată a pachetelor pentru lucrul în rețea și prelucrarea datelor. Clienții au început să solicite un mediu mai deschis, care să le permită să construiască aplicații pornind de la produse amestecate, provenite de la producători diferiți. Așa cum a arătat Ethernet, interoperabilitatea încuraja competiția, prin inovații tehnice. Prin urmare, obiectivele independente ale deschiderii erau următoarele:

costuri mai mici

posibilități mai mari

interoperabilitatea între producători

Interoperabilitatea între producători presupunea că platformele diferite să se recunoască una pe cealaltă și să știe cum să comunice și să partajeze date. Aceasta a necesitat dezvoltarea de standarde neutre, în întreaga industrie, pentru fiecare aspect al lucrului în rețea.

Nevoia de standardizare a generat un efort considerabil. Astăzi, există numeroase organizații de standardizare, care răspund de definirea standardelor naționale și/sau internaționale pentru diferite aspecte ale tehnologiilor de calcul, inclusiv pentru comunicații de date și lucru în rețea. Deși, frecvent, aceste organizații colaborează sau cooperează pentru a asigura un set de standarde cât mai universal, pot exista totuși anumite confuzii, dar efectul covârșitor este pozitiv. Cele mai importante organizații de standardizare sunt:

American National Standards Institute (ANSI) este o organizație privată, non-profit. Scopul său este să faciliteze dezvoltarea, coordonarea și publicarea de standarde naționale voluntare. Standardele ANSI sunt voluntare în sensul că ANSI nu le impune în mod activ. În schimb, datorită apartenenței sale la organizații de standardizare universale, cum ar fi ISO (International Organization for Standards), IEC (International Electrotechnical Commission) și așa mai departe, nerespectarea standardelor ANSI duce la nerespectarea standardelor universale, ceea ce reprezintă o adevărată pedeapsă în era prelucrării deschise de date.

Institute of Electrical and Electronic Engineers (IEEE) răspunde de definirea și publicarea standardelor pentru telecomunicații și comunicații de date. Cea mai semnificativă realizare a sa a fost definirea standardelor pentru rețelele locale și metropolitane (LAN și MAN).

International Organization for Standardization este o organizație bazată pe activitate voluntară, fără contracte, și este autorizată de Națiunile Unite pentru definirea de standarde internaționale. Cel mai important standard dezvoltat de ISO este modelul de referință OSI (Open Systems Interconnection Reference Model).

4. Tipuri de rețele de calculatoare

În funcție de răspândirea geografică, implicit de dimensiuni, rețelele se clasifică în:

Rețele locale (LAN) – lucrează la nivelul unei clădiri sau al unui grup de clădiri, având distanța între stațiile de lucru de 10 – 1.000 m.

Rețele teritoriale (WAN) – lucrează la nivelul unei regiuni, având distanța între stațiile de lucru de ordinul miilor de km.

Rețele publice (PDN) – lucrează la nivelul unei regiuni sau la nivel mondial și au acces la diverse rețele locale, de exemplu:

Internet

Usenet

Arpanet (cercetare științifică)

Rețelele locale (LAN) se întind pe o suprafață mică, cum ar fi o clădire sau un campus. Acest tip de rețea este destul de dificil de proiectat, deoarece într-o astfel de rețea se pot conecta sute de calculatoare, utilizate de utilizatori cu drepturi foarte diferite.

Retelele locale (LAN) se recomandă pentru aplicații de business și educaționale.

Rețele teritoriale (WAN) cuprind multiple rețele LAN care se află în locuri geografice diferite. Pentru realizarea comunicațiilor există diferite soluții, cum ar fi linii telefonice normale sau închiriate, legături prin satelit, cablu optic, etc.

Rețeaua WAN poate fi de două tipuri :

Simplă – prevăzută cu modemuri și acces la servere de la distanță pentru a permite conectarea utilizatorilor.

Complexă – prin legarea sutelor de domenii de rețea la mare distanță, folosind rutere și filtre pentru micșorarea costurilor și mărirea vitezei de transmisie a datelor.

Rețele bazate pe server – au devenit modelul standard pentru interconectarea în rețea. Un server dedicat este un calculator care funcționează doar ca server, nefiind folosit drept client sau stație de lucru. Acest calculator central controlează toate resursele comune (unități de disc, imprimante, fișiere), asigură securitatea datelor și sistemului, realizează comunicații între stațiile de lucru.

Serverele se numesc „dedicate” deoarece sunt optimizate să deservească rapid cererile clienților din rețea și să asigure securitatea fișierelor și a directoarelor.

Principalul avantaj al rețelelor bazate pe server este partajarea resurselor. Un server este proiectat pentru a oferi acces la mai multe fișiere și imprimante , asigurând în același timp fiecărui utilizator performanțele și securitatea necesare.

Partajarea datelor în cazul rețelelor bazate pe server poate fi administrată și controlată centralizat. Resursele sunt localizate de obicei într-un server central, fiind mai ușor de detectat și de întreținut decât cele distribuite pe diferite calculatoare.

Principalul motiv pentru care se recurge la o rețea bazată pe server îl reprezintă nevoia de securitate. Politica de securitate este stabilită de un administrator, care o aplică pentru fiecare calculator și utilizator din rețea. O rețea bazată pe server poate avea mii de utilizatori.

1.5. Bazele lucrului în rețele de calculatoare

Rețelele au numeroase componente, atât hardware, cât și software.

Rețelele au evoluat în două categorii distincte: rețele locale (LAN-local area network) și rețele de mare suprafață (WAN – wide area network). Rețelele LAN sunt utilizate pentru interconectarea dispozitivelor care se găsesc într-o vecinătate relativ restrânsă. Rețelele WAN sunt necesare pentru a interconecta rețelele LAN aflate la distanță din punct de vedere geografic.

1.5.1 Componente hardware

Componentele hardware elementare includ trei tipuri de disacces la diverse rețele locale, de exemplu:

Internet

Usenet

Arpanet (cercetare științifică)

Rețelele locale (LAN) se întind pe o suprafață mică, cum ar fi o clădire sau un campus. Acest tip de rețea este destul de dificil de proiectat, deoarece într-o astfel de rețea se pot conecta sute de calculatoare, utilizate de utilizatori cu drepturi foarte diferite.

Retelele locale (LAN) se recomandă pentru aplicații de business și educaționale.

Rețele teritoriale (WAN) cuprind multiple rețele LAN care se află în locuri geografice diferite. Pentru realizarea comunicațiilor există diferite soluții, cum ar fi linii telefonice normale sau închiriate, legături prin satelit, cablu optic, etc.

Rețeaua WAN poate fi de două tipuri :

Simplă – prevăzută cu modemuri și acces la servere de la distanță pentru a permite conectarea utilizatorilor.

Complexă – prin legarea sutelor de domenii de rețea la mare distanță, folosind rutere și filtre pentru micșorarea costurilor și mărirea vitezei de transmisie a datelor.

Rețele bazate pe server – au devenit modelul standard pentru interconectarea în rețea. Un server dedicat este un calculator care funcționează doar ca server, nefiind folosit drept client sau stație de lucru. Acest calculator central controlează toate resursele comune (unități de disc, imprimante, fișiere), asigură securitatea datelor și sistemului, realizează comunicații între stațiile de lucru.

Serverele se numesc „dedicate” deoarece sunt optimizate să deservească rapid cererile clienților din rețea și să asigure securitatea fișierelor și a directoarelor.

Principalul avantaj al rețelelor bazate pe server este partajarea resurselor. Un server este proiectat pentru a oferi acces la mai multe fișiere și imprimante , asigurând în același timp fiecărui utilizator performanțele și securitatea necesare.

Partajarea datelor în cazul rețelelor bazate pe server poate fi administrată și controlată centralizat. Resursele sunt localizate de obicei într-un server central, fiind mai ușor de detectat și de întreținut decât cele distribuite pe diferite calculatoare.

Principalul motiv pentru care se recurge la o rețea bazată pe server îl reprezintă nevoia de securitate. Politica de securitate este stabilită de un administrator, care o aplică pentru fiecare calculator și utilizator din rețea. O rețea bazată pe server poate avea mii de utilizatori.

1.5. Bazele lucrului în rețele de calculatoare

Rețelele au numeroase componente, atât hardware, cât și software.

Rețelele au evoluat în două categorii distincte: rețele locale (LAN-local area network) și rețele de mare suprafață (WAN – wide area network). Rețelele LAN sunt utilizate pentru interconectarea dispozitivelor care se găsesc într-o vecinătate relativ restrânsă. Rețelele WAN sunt necesare pentru a interconecta rețelele LAN aflate la distanță din punct de vedere geografic.

1.5.1 Componente hardware

Componentele hardware elementare includ trei tipuri de dispozitive:

Echipamente de transmisie

Dispozitive de acces

Dispozitive ce repetă semnalele transmise

Echipamentele de transmisie reprezintă mediul utilizat pentru a transporta semnalele unei rețele către destinație. Tipurile de medii includ cabluri coaxiale, cabluri torsadate și chiar fibre optice.

Tipurile de medii LAN pot fi, de asemenea, intangibile. Ele pot fi semnale luminoase, radio, și chiar microunde, transmise prin aer.

Dispozitivele de acces răspund de:

formatarea corectă a datelor

plasarea datelor în rețea

acceptarea datelor care îi sunt adresate

Într-o rețea locală, dispozitivul de acces este cunoscut ca placă de interfață cu rețeaua (NIC – network interface card).

NIC este o placă de circuite instalată într-un calculator și ocupă un slot de intrare/ieșire de pe placa de bază a acestuia. Rețeaua este cablată apoi la portul pus la dispoziție de această placă. NIC formează cadrele de date care trebuie transmise de către aplicațiile calculatorului, pune datele în forma binară și acceptă intrarea cadrelor adresate calculatorului respectiv.

Într-o rețea WAN, dispozitivul de acces este un ruter. Ruterele operează la nivelul trei al modelului de referință OSI și includ două tipuri de protocoale: de rutare (routing) și rutabile (routable). Protocoalele rutabile, ca IP, sunt utilizate pentru a transporta datele dincolo de limitele domeniilor de nivel doi.

Protocoalele de rutare furnizează toate funcțiile necesare realizării următoarelor operații:

determinarea căilor optime prin rețeaua WAN pentru orice adresă de destinație dată

acceptarea și trimiterea pachetelor prin aceste căi la destinațiile lor

Repetoarele sunt dispozitive care acceptă semnalele trimise, le amplifică și le plasează din nou în rețea. Într-un LAN, un repetor – cunoscut mai mult sub numele de concentrator (hub) – permite conectarea în rețea a mai multor dispozitive, prin furnizarea mai multor puncte de intrare în rețea.

Capacitatea concentratorului de a regenera semnalele este la fel de vitală pentru succesul unui LAN ca și capacitatea de a asigura mai multor puncte de intrare în rețea. Semnalele transmise sunt afectate de mediul care le transportă. Această deteriorare poate lua una din următoarele două forme: atenuare sau distorsionare.

Atenuarea este scăderea puterii semnalului. Distorsionarea este modificarea nedorită a semnalului în timpul transferului. Fiecare din aceste forme trebuie să fie abordată și rectificată separat.

Atenuarea poate fi compensată prin dimensionarea cablurilor la o lungime minimă, pentru a garanta că semnalul este suficient de puternic pentru a ajunge la toate destinațiile din lungul cablului. În cazul în care cablul trebuie să fie relativ lung, poate fi instalat pe linie un repetor. Distorsionarea este o problema mai gravă în transmiterea semnalelor. Semnalele distorsionate pot altera orice date transportate. Repetoarele sunt incapabile de a face diferența dintre semnalele corecte și cele distorsionate; ele repetă semnalele fără deosebire.

1.5.2 Componente software

Componentele software necesare într-o rețea includ următoarele elemente:

Protocoale (definesc și reglează modul în care comunică două sau mai multe dispozitive)

Software la nivel hardware (microcod/drivere) – controlează modul de funcționare al dispozitivelor individuale

Software pentru comunicații

Protocoalele reprezintă mijloacele de comunicare standard pentru calculatoare și alte dispozitive atașate la rețea. Protocoalele pentru rețelele LAN sunt numite frecvent arhitecturi LAN, pentru că sunt incluse in NIC. Ele predetermină în mare măsură forma, dimensiunea și mecanica rețelei.

Protocoalele pentru rețelele WAN sunt furnizate de obicei în pachete și răspund pentru o mare varietate de servicii.

Driverele de dispozitiv sunt programe de nivel hardware care controlează un anumit dispozitiv. Un driver de dispozitiv poate fi privit ca un sistem de operare în miniatură pentru o singură componentă hardware. Fiecare driver conține toată logica și toate datele necesare pentru a asigura funcționarea corectă a dispozitivului respectiv. În cazul unei plăci de interfață cu rețeaua (NIC), driverul include furnizarea unei interfețe pentru sistemul de operare al gazdei.

Software pentru comunicații

Componentele hardware și software de rețea descrise anterior nu au capacitatea de a-i permite unui utilizator să folosească efectiv rețeaua. Ele nu fac decât să asigure infrastructura și mecanismele care permit utilizarea acesteia. Sarcina utilizării efective a rețelei cade în seama aplicațiilor software specializate, care controlează comunicațiile.

CAPITOLUL 2

Arhitectura rețelelor de calculatoare

Componentele necesare construirii unei rețele:

Placa de rețea (placa de interfață cu rețeaua) este constituită dintr-o placă instalată în calculator, care suportă funcții de partajare a mediului fizic și de sincronizare.

Cabluri de rețea Majoritatea rețelelor actuale folosesc cablul coaxial, cablul torsadat sau fibrele optice.

Cablul coaxial constă dintr-un miez de cupru înconjurat de un înveliș izolator, apoi de un strat de ecranare format dintr-o plasă metalică și o cămașă exterioară de protecție.

Cablul este de două tipuri: neecranat și ecranat. Fibrele optice transportă semnale de date digitale sub forma unor impulsuri luminoase modulate.

Cutia centrală a rețelei Hub-ul este un concentrator de cabluri, ce oferă administratorului rețelei un punct central de monitorizare și control de la distanță și, în același timp, un punct de conectare a unei rețele la o magistrală de mari dimensiuni. În timp, s-au adăugat noi funcții în hub, ca de exemplu: de asigurare a securității comunicațiilor, de procesare a semnalelor de alarmă, de operare ca servere, de acționare ca porți, etc. Astfel s-a introdus noțiunea de hub administrat. La nivel general, hub-urile pot fi caracterizate ca: hub-uri Ethernet cu configurație fixă, hub-uri Ethernet cu configurație modulară și multislot, hub-uri multifuncție și mixte.

Punți. Puntea interconectează rețele ce utilizează tehnici de transmisie diferite și/sau metode de control al accesului la mediu diferite, pe baza mecanismului „memorează-și-retransmite” (store-and-forward). Puntea conectează două sau mai multe rețele la nivelul de control al accesului la mediu (MAC – Medium Access Control), care este un subnivel ce face parte din nivelul Legăturii de Date, din stiva de protocoale OSI. Ea asigură o conectare rapidă și ieftină pentru platforme de calcul cu construcție și arhitectură asemănătoare. Puntea partiționează rețeaua, fizic și logic, echilibrând astfel traficul între segmentele separate. O punte de filtrare elimină traficul non-local, mărind performanțele din fiecare segment. Punțile pot fi cu trecere (conectează rețele cu nivele MAC identice, asigurând reformatarea electrică a semnalelor și retransmiterea cadrelor, filtrarea cadrelor și administrarea cozilor de cadre) sau cu conversie (conectează rețele cu nivele MAC diferite, făcând conversia începutului <header> și sfârșitului <trailer-byte de control> cadrelor recepționate). Punțile pot fi conectate local, direct (IEEE 802.1D), folosind aceeași structură de adrese în cele două rețele, chiar dacă au MAC-uri diferite sau pot fi conectate la distanță (IEEE 802.1G), printr-un mediu de interconectare (linie T1, Frame Relay, etc.). Standardul de interconectare cu punți include un algoritm de arbore divizat (spanning – tree algorithm), care asigură faptul că topologia rețelei este fără bucle, oferind totuși redundanță, ceea ce permite rețelei să continue să asigure serviciul în cazul defectării unei componente sau punți a rețelei. Există punți ce au și facilități de dirijare a traficului în rețea, numite broutere.

Switch-ul este un echipament ce se folosește în rețele de trafic mare de date și poate gestiona mai multe legături deodată.

Ruter-ul asigură dirijarea optimă a pachetelor de date de la un sistem la altul, acolo unde există căi multiple între sisteme. Spre deosebire de punți, ruter-ele izolează rețelele între ele. Ele se pot folosi pentru interconectarea unor rețele ce utilizează același protocol de comunicație sau protocoale de comunicație diferite (ruter-e multiprotocol). Un ruter operează la Nivelul Rețea al modelului OSI. Algoritmii de dirijare guvernează modul în care ruter-ele obțin informația necesară pentru a determina căile prin care va fi dirijat traficul. Din motive de securitate sau de cost, diferite pachete de date pot fi dirijate prin segmente de rețea diferite. Ruter-ele se pot folosi cu succes atât la interconectarea LAN-urilor aflate la distanță, cât și a LAN-urilor cu WAN-uri.

Ruter-ul funcționează la nivelul rețea al modelului ISO/OSI și este utilizat pentru interconectarea mai multor rețele locale de tipuri diferite, dar care utilizează același protocol de nivel fizic. Utilizarea lor asigură o mai mare flexibilitate a rețelei în ceea ce privește topologia.

Diferența între o punte și un ruter este că în timp ce puntea operează cu adresele fizice ale calculatoarelor (luate din cadrul MAC) ruterele utilizează adresele logice, de rețea, ale calculatorului.

Ruterul permite rutarea mesajelor de la sursă la destinație atunci când există mai multe posibilități de comunicare între cele două sisteme.

Sistem 1                                                    Sistem 2

Figura 1 (Capitolul 2) – Ruter-ul în raport cu modelul OSI.

          În general un ruter utilizează un singur tip de protocol de nivel rețea, și din acest motiv el nu va putea interconecta decât rețele la care sistemele folosesc același tip de protocol. De exemplu dacă există două rețele, una utilizând protocolul TCP/IP și alta protocolul IPX, nu vom putea utiliza un ruter care utilizează TCP/IP. Acest ruter se mai numește ruter dependent de protocol. Există însă și rutere care au implementate mai multe protocoale, făcând astfel posibilă rutarea între două rețele care utilizează protocoale diferite, și care se numesc rutere multiprotocol. Bruter este un echipament care combină calitățile unei punți și ale unui repetor. El poate acționa ca ruter pentru un anumit protocol și ca punte pentru altele.

Modem-ul are rolul de a converti semnalele digitale în semnale analogice și invers.

Transceiner – dispozitiv ce conectează calculatorul în rețea. El transformă fluxul de date paralel folosit pe magistrala internă a calculatorului, într-un flux de date serial, folosit pe cablurile care conectează calculatoarele.

CAPITOLUL 3

Protocoale și algoritmi de rutare

O rețea de calculatoare este alcătuită dintr-un ansamblu de mijloace de transmisie și de sisteme de calcul, pentru a realiza atât funcții de transport a informației cât și funcții de prelucrare a acesteia. O rețea de calculatoare care interconectează diferite sisteme de calcul poate funcționa în bune condiții numai dacă există o convenție care stabilește modul în care se transmite și se interpretează informația, convenție numită protocol.          

În concluzie un protocol este un set de reguli și convenții ce se stabilesc între participanții la o comunicație în vederea asigurării bunei desfășurări a comunicației respective; sau protocolul este o înțelegere între părțile care comunică asupra modului de realizare a comunicării.

Pentru a realiza comunicația sunt necesare mai multe reguli (protocoale) care se stabilesc între membrii de pe același nivel și între membrii din cadrul aceluiași grup. Acest concept se numește familie de protocoale (stivă) și reprezintă o listă de protocoale utilizate de către un anumit sistem, câte un protocol pentru fiecare nivel.

3.1. Modelul de referință OSI

Modelul ISO/OSI este un model organizat pe șapte nivele:

1. nivelul fizic – se ocupă de transmiterea biților printr-un canal de comunicație;

2. nivelul legăturii de date – fixează o transmisie a biților fără erori în jurul unei linii de transmisie;

3. nivelul rețea – se ocupă de controlul funcționării subrețelei;

4. nivelul transport – rolul principal al acestui nivel este să accepte date de la nivelul superior (nivelul sesiune), să le descompună, dacă este cazul, în unități mai mici, să transfere aceste unități nivelului inferior (nivelului rețea) și să se asigure că toate fragmentele sosesc corect la celălalt capăt;

5. nivelul sesiune – gestionează dialogul între aplicații sau utilizatori;

6. nivelul prezentare – se ocupă de sintaxa și semantica informațiilor transmise între aplicații sau utilizatori;

7. nivelul aplicație – se ocupă de interfața comună pentru aplicațiile utilizator, de transferul fișierelor între programe.

Modelul OSI este doar un model de arhitectură de rețea, deoarece spune numai ceea ce ar trebui să facă fiecare nivel, și nu specifică serviciile și protocoalele utilizate la fiecare nivel.

În cadrul unui același sistem între două nivele succesive există o legătură fizică iar schimbul de informații se face pe baza unor alte convenții, care se numesc servicii. Schimbul efectiv de semnale are loc numai la nivelurile fizice ale celor două sisteme care comunică.

ISO a dezvoltat modelul de referință OSI (Open Systems Interconnection – interconectarea sistemelor deschise), pentru a facilita deschiderea interconexiunii sistemelor de calculatoare. O interconexiune deschisă este o interconexiune care poate fi acceptată într-un mediu multiproducător. Acest model a stabilit standardul universal pentru definirea nivelurilor funcționale necesare acceptării unei astfel de conexiuni între calculatoare.

Puține produse respectă în totalitate modelul OSI, în schimb, structura sa elementară, pe niveluri, este frecvent adaptată noilor standarde.

Modelul OSI clasifică diversele procese necesare într-o sesiune de comunicare pe șapte niveluri funcționale. Organizarea acestor straturi are la bază secvența naturală de evenimente care apare în timpul sesiunii de comunicare.

3.2. Protocolul TCP/ IP

Modelul TCP/IP este mult mai vechi decât modelul OSI și a fost utilizat drept model de referință de către ARPANET, și apoi de către Internet. ARPANET a fost o rețea de cercetare sponsorizată de către DoD (Department of Defense – Departamentul de Apărare al Statelor Unite).

Deși nu există un model universal acceptat pentru a descrie structurat arhitectura protocolului TCP/IP, acesta este văzut ca fiind compus din mai puține straturi decât modelul OSI.

3.2.1 Scopul protocolului Internet

Protocolul care definește acest mecanism de distribuire nefiabil și neorientat pe conexiune se numește „Internet Protocol”, cunoscut sub inițialele IP. IP oferă:

Protocolul IP definește unitatea de bază pentru transferul de date în rețelele bazate pe TCP/IP. Acesta specifică formatul exact al tuturor datelor ce traversează o rețea TCP/IP;

Software-ul IP realizează și funcția de rutare, alegând o cale pe care datele vor fi trimise;

Pe lângă specificațiile formale pentru formate și rutare, IP include un set de reguli ce încapsulează ideea de transmisie nefiabilă. Aceste reguli caracterizează modul în care o stație sau un gateway ar trebui să proceseze pachetele primite: de ce și când trebuie generate mesaje de eroare și în ce condiții pachetele pot fi eliminate.

3.2.2 Diferențe dintre modelul de referință ISO/OSI și modelul TCP/IP.

Din figura care urmează se va observa diferența dintre modelul de referință ISO/OSI și modelul TCP/IP.

  Modelul OSI Modelul TCP / IP

Figura 1 (Capitolul 3) – Comparație între modelele ISO/OSI și TCP/IP.

Despre nivelul gazdă la rețea modelul TCP/IP nu  spune  mare  lucru, singura mențiune este aceea că gazda trebuie să se lege la rețea, pentru a putea transmite date, folosind un anumit protocol. Acest protocol nu este definit și variază de la gazdă la gazdă și de la rețea la rețea.

Nivelul Internet are rolul de a permite gazdelor să emită pachete în orice rețea și de a face ca pachetele să circule independent până la destinație. Nivelul Internet definește oficial un format de pachet și un protocol numit IP – Internet Protocol care asigură un serviciu de transmitere a datelor fără conexiune.

Nivelul transport asigură comunicația între programele de aplicație. Sunt definite două protocoale: TCP – Transmission Control Protocol este un protocol punct-la-punct, orientat pe conexiuni care permite ca un flux de octeți trimiși de pe un sistem să ajungă fără erori pe oricare alt sistem din inter-rețea (asigură livrarea corectă, în ordine a mesajelor). Al doilea protocol, UDP – User Datagram Protocol este un protocol nesigur, fără conexiuni.

Nivelul aplicație asigură utilizatorii rețelei, prin intermediul programelor de aplicație, o varietate de servicii.

3.2.3. Datagrame IP

Pentru Internet unitatea care stă la baza tuturor transferurilor este datagram-ul Internet sau datagram-ul IP. La fel ca un cadru transmis pe o rețea fizică, un datagram IP este împărțit în header și zona de date (fig. 2):

Figura 2 (Capitolul 3)

Header-ul conține:

versiunea IP folosită (VERS);

lungimea header-ului (HLEN);

tipul serviciului (SERVICE TYPE);

lungimea totală a datagram-ului (TOTAL LENGTH);

numărul de identificare al datagram-ului (IDENTIFICATION);

două câmpuri folosite la fragmentare (FLAGS, FRAGMENT OFFSET);

durata de viață (TIME TO LIVE);

protocolul (PROTOCOL);

suma de control a header-ului (HEADER CHECKSUM);

adresa IP a sursei;

adresa IP a destinației;

biți pentru opțiuni (IP OPTIONS).

Figura 3 (Capitolul 3)

Spre deosebire de cadrele rețelelor fizice, dimensiunea unui datagram nu este limitată de nici o caracteristică hardware. Pentru IPv4 lungimea maximă a unui datagram poate fi 216. Un datagram care circulă de la o mașină la alta trebuie să fie transportat pe o rețea fizică (sau mai multe). Ideea de a transporta un datagram într-un cadru de rețea se numește „încapsulare” (encapsulation) (fig 4).

Figura 4 (Capitolul 3)

În cazul ideal întregul datagram IP încape într-un singur cadru fizic, făcând astfel transmisia eficientă. Pentru a obține această eficiență a fost introdus termenul de „unitate de transfer maximă” (maximum transfer unit – MTU), astfel încât orice datagram să încapă într-un cadru fizic.

3.2.4. Adresele IP. Subrețele.

Se spune despre un sistem de comunicație că oferă un serviciu de comunicație universal dacă permite fiecărui sistem gazdă (host) să comunice cu orice alt sistem. Pentru a face sistemul nostru de comunicație să fie universal, trebuie să stabilim o metodă global acceptată de identificare a calculatoarelor.

Identificarea unei stații se poate face prin:

nume (ce este un obiect);

adresă (unde se găsește obiectul);

rută (cum se poate ajunge la el).

Fiecare dintre atributele de mai sus se reduc la niște simpli identificatori. Pentru om cel mai simplu mod de identificare îl reprezintă numele. Însă în alegerea (pentru Internet) a unui identificator universal putea fi ales oricare dintre atributele amintite. Totuși a fost ales modul de identificare binară prin adresă a unei anumite stații pentru a eficientiza luarea deciziilor de rutare.

Clasele de adrese IP

Internet-ul se poate gândi ca și orice altă rețea fizică, cu diferența că Internet-ul este o structură virtuală implementat în întregime în software. Astfel proiectanții nu au fost constrânși în alegerea formatului și dimensiunii pachetelor, a adreselor, de nici o caracteristică (limitare) hardware. Pentru adrese, proiectanții TCP/IP au ales o schemă analoagă cu modul de adresare din rețelele fizice, în care fiecare stație are atribuit un unic număr întreg numit „adresă Internet” sau „adresă IP”. Însă aceste adrese au fost alese astfel încât să facă rutarea pachetelor cât mai eficientă. Și anume, o adresă IP codifică informația despre rețeaua fizică de care aparține o anumită stație și informația de identificare a stației în cadrul rețelei.

Fiecare stație gazdă din Internet are atribuită o unică adresă Internet pe 32 de biți care este folosită în toate comunicațiile cu stația respectivă. Această adresă este o pereche de tipul (netid, hostid) unde netid este un identificator de rețea, iar hostid identifică o stație din cadrul rețelei netid.

Pentru o anumită adresă IP dată se poate determina clasa din care face parte pe baza celor mai semnificativi trei biți din adresă. Adresele de clasă A sunt folosite pentru rețelele de dimensiuni foarte mari, care au mai mult de 216 stații, au 7 biți pentru netid și 24 biți pentru hostid. Adresele de clasă B, care sunt folosite pentru rețelele de dimensiuni medii având un număr de stații între 28 și 216, au alocați 14 biți pentru netid și 16 biți pentru hostid. Iar adresele de clasă C, folosite în rețelele de dimensiuni mici cu până la 28 stații, au alocați 21 biți pentru netid și 8 biți pentru hostid. Trebuie să remarcăm că adresele IP au fost astfel concepute pentru a se putea extrage cât mai simplu și rapid identificatorii netid și hostid.

Adresele specifică conexiunile la rețea.

Orice adresă IP identifică o unică stație din rețea, dar o stație poate avea alocate mai multe adrese IP. Astfel pentru fiecare conexiune a unei stații la o anumită rețea trebuie alocată o adresă IP distinctă. Acest lucru este impus de codificarea adresei rețelei în adresa IP.

Adresele de rețea, de broadcast și de loopback.

Un alt avantaj al codificării informației de rețea în adresa IP este acela că se poate face referire la o rețea în același mod ca și la o stație. Prin convenție o valoare „0” de hostid nu este atribuită nici unei stații dintr-o rețea. Însă o adresă IP cu câmpul hostid „0” este folosită pentru a identifica rețeaua.

Un alt avantaj semnificativ al acestui tip de adresare este că include o „adresă de broadcast”, care identifică toate stațiile unei rețele. Astfel o adresă a cărei hostid are „1” pe toate pozițiile este rezervată pentru broadcast. Acest tip de adresare se numește adresare de broadcast directă, deoarece conține atât adresa de rețea cât și cea de stație.

Un alt mod de adresare de tip broadcast, numită adresare de broadcast limitată, oferă o adresă de broadcast pentru rețeaua locală, indiferent de adresa IP alocată ei. Adresa de broadcast locală este formată din 32 biți de „1”. Acest tip de adresare poate fi folosit în rutina de boot-are pentru a afla adresa IP a rețelei locale.

Notația zecimală cu punct

În interfața cu utilizatorul adresele IP sunt scrise ca patru numere întregi zecimale separate prin punct, unde fiecare întreg reprezintă valoarea zecimală a unui octet din adresa IP. Astfel adresa IP

11000001.11100010.00001000.01101111

se scrie

193.226.8.111

Slăbiciunile adresării Internet

Codificarea informației despre rețea în adresa IP are câteva dezavantaje. Primul mare dezavantaj este că o adresă este atribuită unei conexiuni și nu unei stații. Astfel, dacă o stație se mută de pe o rețea pe alta, trebuie să i se modifice și adresa IP.

O altă slăbiciune a acestui mod de adresare apare în cazul unei rețele de clasă C, dacă numărul de stații din rețea depășește 253 (numarul maxim de IP-uri). În această situație trebuie obținuta o adresă de clasă B și trebuie modificate toate adresele IP din rețea la noua adresă. Această operație este destul de mare consumatoare de timp.

Cea mai importantă lipsă a adresării Internet apare în procesul de rutare. Deoarece rutarea folosește porțiunea de rețea din adresa IP, calea pe care o urmează un anumit pachet IP în drumul lui către o anumită stație cu adresare IP multiplă depinde de adresa folosită în comunicație. Astfel pentru situația din figura 2.2 dacă stația A transmite un pachet stației B, identificată prin adresa corespunzătoare conexiunii I4, pachetul va urma următoarea cale:

Stația A -> Conexiunea I3 -> Rețeaua 1 -> Conexiunea I4 -> Stația B.

Iar dacă stația A transmite un pachet stației B la adresa corespunzătoare conexiunii I5, acesta va urma calea:

Stația A -> Conexiunea I3 -> Rețeaua 1 -> Conexiunea I1 -> Gateway -> Conexiunea I2 ->Rețeaua 2-> Conexiunea I5 -> Stația B

Subrețele

Structura standard a unei adrese IP poate fi modificată local prin folosirea biților pentru adresa stației ca biți suplimentari pentru adresa de rețea. Prin aceasta se creează mai multe rețele, prin reducerea numărului maxim de stații ce aparțin fiecărei rețele nou create. Aceste rețele nou create se numesc subrețele.

Folosirea subrețelelor:

permite un management descentralizat al adresării stațiilor;

rezolvarea diferențelor hardware și a limitării distanțelor.

Din punct de vedere conceptual, împărțirea în subrețele schimbă doar interpretarea unei adrese IP. Astfel, în loc de a împărți adresa IP într-un prefix corespunzător rețelei și un sufix pentru adresa stației, adresa se împarte într-o porțiune corespunzătoare rețelei și una corespunzătoare stației. Partea de rețea fizică se tratează doar local; doar gateway-ul local știe că sunt mai multe rețele fizice și rutează traficul între ele.

Standardul specifică că pentru un site care folosește subrețelele trebuie specificată câte o mască pentru fiecare subrețea. În această mască sunt setați pe „1” biții corespunzători adresei rețelei și sunt pe „0” pentru porțiunea corespunzătoare adresei stației.

Organizațiile mari care au mai multe rețele de calculatoare cu acces la Internet au întâmpinat probleme la atribuirea mai multor adrese dintr-o clasă.

Traficul prin router-ul organizației era foarte mare iar comunicația avea astfel de suferit în orele de vârf. Pentru a mări viteza de transfer a datelor și a nu supraîncărca un router, organizațiile mari și-au reorganizat rețeaua ierarhic folosind mai multe routere.

Astfel rețeaua a fost divizată în subrețele pentru care accesul la Internet și la celelalte rețele este asigurat de un dispozitiv „gateway” (un router sau un calculator gateway).

Pentru a face posibilă această divizare se utilizează adresarea pe subrețele. Așa cum se cunoaște, o adresă IP are o zonă alocată rețelei și o zonă în care se alocă adresă pentru calculatoarele gazdă. Conform acestei arhitecturi avem clasele A,B,C și D pentru multicast.

Pentru a gestiona mai eficient spațiul de adresare alocat unei organizații mari cu mai multe rețele proprii, s-au creat subrețelele.

Utilizând o mască de rețea (Net-mask) binară, se poate stabili porțiunea alocată rețelei și porțiunea alocată gazdei. Astfel biții 1 din net-mask indică zona alocată rețelei iar biții 0 specifică zona alocată gazdei. Avem astfel pentru clasele A,B,C cunoscute următoarele măști de rețea predefinite:

A: 255.0.0.0 – în format zecimal cu punct

11111111.00000000.00000000.00000000 – în binar

B: 255.255.0.0

11111111. 11111111.00000000.00000000

C: 255.255.255.0

11111111. 11111111. 11111111.00000000

Folosind același mecanism, se pot defini subrețele în cadrul unei clase de adrese alocate, folosind pentru aceasta primii biți din cadrul spațiului alocat gazdei.

Putem stabili prin numărul de biți rezervați subrețelei numărul de subrețele disponibile pentru o anumită clasă de adrese și numărul de gazde alocabile în fiecare subrețea.

Astfel pentru clasa B avem următoarele configurații posibile:

Observație: Utilizarea unui singur bit pentru subrețea nu este permisă deoarece pentru subrețea biții nu pot fi cu toții simultan 1 sau 0. Aceste adrese se utilizează pentru comunicarea între subrețele și pentru identificarea subrețelei.

3.3. Rutarea datelor

Rutarea este procesul de determinare, comparare și selectare a căilor prin rețea către orice adresă IP destinație. De obicei funcția de rutare este încorporată în dispozitive special construite pentru acest lucru, denumite routere. Dar poate fi suportată și de alte dispozitive sau chiar de servere cu soft de rutare corespunzător. Astfel rutarea este o funcție a unei rețele.

Rutarea se bazează pe protocoale definite astfel încât să îndeplinească funcțiile esențiale ale rutării:

schimbul de informații despre calculatoarele gazdă și rețelele conectate local

compararea căilor potențial redundante

convergența către un acord asupra topologiei unei rețele

Principiile fundamentale ale rutării

Routerele pot ruta (dirija) pachete în două moduri:

1. utilizând rute statice programate în prealabil

2. calculând dinamic rutele folosind unul din protocoalele de rutare dinamică.

3.3.1. Rutarea statică

Rutele statice sunt cele mai simple forme de rutare. Un router programat static redirecționează pachete spre exterior folosind porturi predefinite. Sarcina administrării rutelor rămâne în grija administratorului care va trebui să cunoască perfect topologia rețelelor pentru a programa rutele statice corect. La orice modificare a rețelei, există riscul ca unele rute programate să nu mai funcționeze, iar administratorul trebuie să intervină să reprogrameze rutele. Rutarea statică prezintă însă avantaje ca:

drumul spre o rețea este întotdeauna același ceea ce duce la creșterea siguranței comunicației;

resursele consumate sunt mai mici, nefiind nevoie de calcularea rutei și nici de comunicații suplimentare între routere.

Dezavantajele rutării statice:

la orice avarie pot apare rute nefuncționale ceea ce implică un efort continuu de programare a rutelor din partea administratorului,

la schimbarea topologiei rețelei trebuie reprogramate rutele pe toate routerele implicate în topologie.

3.3.2. Rutarea dinamică

Există două categorii de principale de rutare dinamică:

protocoale bazate pe vectori de distanțe (distance-vector)

bazate pe starea legăturii (link-state)

Principala diferență între aceste categorii este modul în care ele descoperă și calculează noi rute către destinație.

Rutarea bazată pe vectori de distanțe

Acest tip de rutare se bazează pe algoritmi care lucrează cu vectori de distanțe, numiți și algoritmi Bellman-Ford. Acești algoritmi se bazează pe trimiterea periodică a propriei tabele de rutare către vecinii din imediata apropiere. Fiecare destinatar adaugă în tabelă un vector de distanță, sau propria valoare pentru distanță și retrimite tabela în imediata vecinătate. Acest proces are loc în toate direcțiile, între toate routerele care se învecinează direct. Astfel fiecare router află informații despre celelalte routere și își formează o perspectivă cumulativă asupra distanțelor din rețea. Tabela cumulativă este folosită apoi pentru a-și actualiza propria tabelă de rutare.

Inconveniente ale rutării bazate pe vectori de distanțe:

defecțiune în rețea sau o altă schimbare necesită din partea routerelor un anumit timp pentru a converge către o nouă reprezentare a topologiei rețelei. În timpul procesului de convergență, rețeaua este vulnerabilă la rutări inconsistente sau chiar la rutări în buclă. Din acest motiv aceste protocoale nu sunt recomandate în rețele WAN mari și complexe.

Acești algoritmi nu țin cont de distanța fizică între noduri și nici de lățimea de bandă pentru o anumită rută. Singurul criteriu de apreciere a distanței este numărul de hopuri până la destinație

Avantaje ale protocoalelor bazate pe distanțe:

sunt protocoale simple, ușor de configurat și de utilizat. Din acest motiv sunt utilizate în rețele mici cu puține rute redundante și prezintă cerințe stringente de performanță.

Reprezentativ pentru acest tip de protocoale este RIP (Routing Information Protocol). RIP folosește o singură funcție de distanță pentru a determina cea mai bună cale de urmat: costul.

Rutarea bazată pe starea legăturilor

Acest tip de rutare se bazează pe algoritmii SPF (Shortest Path First). Aceștia mențin o bază de date complexă a topologiei rețelei. Acest protocoale bazate pe starea legăturilor construiesc și actualizează un set complet de cunoștințe despre routerele rețelei și despre modul lor de interconectare. Acest lucru se realizează prin schimbul de anunțuri de stare a legăturilor (Link-State Advertisements LSA) cu alte routere din rețea. Pentru calcularea apoi a accesibilităților destinațiilor în rețea, va fi folosit un algoritm SPF.

Inconveniente ale rutării bazate pe starea legăturilor:

În timpul procesului de descoperire, protocoalele bazate pe starea legăturilor pot inunda mediile de transmitere ale rețelei scăzând prin aceasta semnificativ performanțele rețelei.

Deteriorarea performanțelor este doar temporară dar notabilă.

Rutarea bazată pe starea legăturilor este consumatoare de memorie și de timp procesor, ca atare este nevoie de routere bine echipate pentru a suporta acest tip de rutare.

Avantaje ale rutării bazate pe starea legăturilor:

Se adaptează ușor la orice tip și dimensiune de rețea,

Într-o rețea bine proiectată, un astfel de protocol va trece cu bine peste orice schimbare neașteptată de topologie,

Aceste protocoale permit o mai bună scalabilitate a rețelei.

Cel mai utilizat protocol bazat pe starea legăturilor este OSPF (Open Shortest Path First). OSPF a fost proiectat pentru a fi utilizat exclusiv pentru rutarea datagramelor IP. Nu este indicat în cazul în care rețeaua trebuie să suporte și alte protocoale rutabile (ex: IPX sau AppleTalk). Fiecare ruter OSPF menține o bază de date identică ce urmărește stările legăturilor din rețea. Pe baza acestor date sunt „calculate” deciziile de rutare. Actualizările tabelelor de rutare se fac prin LSA (Link-State Advertisement) iar procesul se numește inundare (flood), dar protocolul converge foarte rapid a.î. inundarea nu duce la scăderea drastică a performanțelor rețelei.

3.3.4 Tabela de rutare

Algoritmul de rutare uzual folosit folosește o „tabelă de rutare Internet” (Internet routing table) pe fiecare mașină care stochează informații despre posibilele destinații și cum se ajunge la ele. Deoarece atât stațiile cât și gateway-urile rutează datagram-e, ambele vor avea tabele de rutare.

Pentru a ascunde informațiile despre stațiile destinație, pentru a menține tabela de rutare de dimensiuni mici și pentru a face rutarea eficientă, software-ul de rutare IP păstrează doar informații despre adresele de rețea pentru destinații și nu despre stațiile destinație. Tipic, un tabel de rutare conține perechi (N, G), unde N este adresa IP a rețelei destinație, iar G este adresa IP a următorului gateway în calea spre destinație. Acest gateway trebuie să fie legat la aceeași rețea fizică cu stația în a cărei tabelă de rutare este prezent.

Folosirea adreselor de rețea în tabelele de rutare are următoarele consecințe:

Tot traficul pentru o anumită rețea destinație va urma aceeași cale, deci chiar dacă există mai multe căi acestea nu vor fi folosite concurent și nici nu țin seama de întârzierea pe celelalte căi care ar exista;

Deoarece doar ultimul gateway poate comunica direct cu destinația, numai acesta poate determina dacă stația destinație există sau nu și dacă este operațională.

Deoarece fiecare gateway rutează datagram-ele independent este posibil ca datagram-ele trimise de o stație A spre o altă stație B să urmeze altă cale decât cele trimise de stația B spre stația A.

O altă tehnică de a ascunde informația și de a păstra tabela de rutare mică constă în strângerea intrărilor multiple într-o intrare „default”. Se va folosi un gateway implicit pentru acele destinații care nu apar în tabela de rutare. Aceste rute implicite sunt utile în cazul site-urilor cu un număr mic de adrese locale și cu o singură conexiune cu exteriorul.

În tabela de rutare pot exista și intrări pentru adrese de stații destinație, numite rute specifice. Acestea oferă administratorului de rețea un control mai mare asupra folosirii rețelei și pot fi folosite și pentru securitate.

 CAPITOLUL 4

Rețelele de senzori wireless: fundamente teoretice

4.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 între ele permițând monitorizarea diferitelor condiții fizice ale mediului precum temperatura, sunetul, vibrațiile, presiunea, mișcarea și poluarea. Inițial ele au fost dezvoltate în scopuri militare, dar datorită costului redus, al mobilității oferite si a posibilității de extindere practic nelimitate, rețele au ajuns sa fie folosite in multe domenii civile și industriale.

Pe lângă 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 constituie într-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:

Multi-hop: posibilitatea transmiterii datelor peer-to-peer (de la nod la nod) către
nodul care are rolul de „Bază a rețelei”, conferind astfel o scalabilitate sporită;

Auto Configurare: rețeaua se poate configura fără intervenție umană;

Auto Regenerare: caracteristica rețelei de a accepta sau pierde noduri dinamic,
fără a fi necesară o oprire sau o repornire a acestia in ansamblu;

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.

Interacț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:

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

Nivelul Server: reprezintă o entitate situată intre rețea și utilizator și care este
desemnată să înmagazineze permanent sau provizoriu informațiile transmise de
nodurile rețelei si să le transmit clientului în momentul în care acesta le solicită;

Nivelul Nodurilor: este constituit din software-ul aflat pe nodurile rețelei și care
gestionează preluarea și transmisia datelor la nivel de nod.

4.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 bazează 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 către 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 operează în banda Frecventelor Radio nelicențiate la nivel global (2.4GHz global, 915 MHz în SUA, 868 MHz în Europa), având 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 întregii 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 încheind cu nivelul
Aplicație) astfel încât să permită interoperabilitate intre rețelele de date, crearea de servicii de

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 oferă elementele necesare dezvoltării a trei tipuri elementare de rețele, stea, peer-to-peer și 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” în cadrul topologiilor peer-to-peer.

4.3 Platforma hardware

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

Procesor Intel Pentium M 740 (1.7GHz)

Memorie RAM 1GB

Hard disk cu o capacitate de 100GB

Port USB 2.0 cu posibilitatea de virtualizare în port serial

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

4.3.1 Modulul IRIS

Modulul IRIS (Fig. 1) este produs de către firma Crossbow Technology Inc și funcționează în standardul IEEE 802.15.4 la 2.4 GHz, având o rată de transfer de 250Kbps. El poate 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 1 (Capitolul 4) : 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/Ieșiri Digitale, I2C, SPI si UART. Aceste interfețe permit conectarea ușoară la o gamă variată de periferice.

4.3.2 Placa de interfațare MIB520

Dispozitivul MIB520 (Fig 2) 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 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 (Capitolul 4): Placa de interfaț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ă.

4.4 Platforma software

4.4.1 TinyOS și nesC

4.4.1.1TinyOS

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.

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:

Comenzi

Evenimente

Task-uri (sarcini)

Comenzile și 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ă neapărat în pereche cu evenimentul ce semnalizează terminarea furnizării serviciului.

Taskurile sunt folosite pentru amâna execuția calculelor ample din interiorul 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.

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ță.

4.4.1.2. 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:

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 un a
implementării.

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 își execută sarcina.

Interfețe sunt bidirecționale: ele specifică un set de comenzi pe care le 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.

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.

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.

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.

4.4.2 Cygwin, XServe și PostgreSQL

4.4.2.1. 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:

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

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

4.4.2.2. XServe

XServe este o aplicație care rulează in Windows sub Cygwin și care reprezintă legătura principală dintre aplicația utilizatorului și rețeaua de senzori. Funcția elementară a XServe este de a transfera date de la și la rețea, permițând în același timp analizarea și interpretarea datelor de către 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 (Fig 3) se evidențiază următoarele două:

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

Server pentru aplicație: în această 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.

Figura 3 (Capitolul 4): Arhitectura XServe

4.4.2.3 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.

4.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:

.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

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.

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 realizarea componentei protocolului de rutare ce
se ocupă de calcularea și gestionarea efectivă a rutelor , precum și de menținerea și actualizarea informațiilor despre starea rețelei la un moment dat, a fost influențată de facilităț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ănătoare cu cea a limbajului nesC.

4.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 Fig 4.

Figura 4 (Capitolul 4) : XSniffer

CAPITOLUL 5

Protocolul de rutare MeshSPF

5.1 Caracteristicile protocolului MeshSPF

Protocolul MeshSPF operează la nivelul Rețea din cadrul stivei de protocoale 802.15.4 ZigBee, fiind situat intre subnivelul MAC al standardului 802.15.4 și nivelurile aplicație 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 utilizarea resurselor sporite oferite de către un calculator conectat la nodul bază al rețelei de senzori wireless pentru folosirea unui algoritm complex 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, evitâ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 prelevate de la senzori către aplicația creată de utilizator.

Componenta DROther operează la nivelul nodurilor ce compun rețeaua (exceptând
nodul Bază), sub forma unei 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 recepționării
pachetelor Route Update de la nodul Bază, stabilește, menține și monitorizează 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 evidențiază ca importanță transmiterea pachetelor Neighbors Advertisment, ce conțin informații despre vecinii nodurilor, dinspre nodurile rețelei spre Bază și recepționarea 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 îndeplinește rolul de Bază a rețelei de senzori wireless. DRBase este aplicația
care rulează pe acest nod, aplicație care are doar sarcina 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ționării pachetelor Neighbors Advertisment, și pe care le solicită după transmiterea de Route Update.

Componenta MeshSPF Router, constituie 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 celelalte două componente care sunt implementate sub forma de librării sau aplicații scrise în limbajul nesC, MSPFRouter este o aplicație C# realizată folosind Microsoft .NET 2.0.

MSPFRouter interacționează direct doar cu DRBase, legătura 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 , provenită
de la rețea.

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

5.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 pachetului TinyOS.

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

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

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

Group: specifică id-ul asignat grupului de noduri ce formează rețeaua de senzori wireless. Acest atribut permite existența mai multor rețele în aceeași zonă geografică.

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

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.

5.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

Semnificația câmpurilor pachetului Multi-hop UpStream sunt următoarele:

SourceAddr: adresa ultimului nod expeditor al pachetului;

OriginAddr: adresa nodului care a generat pachetul;

SeqNo: numărul de secvență al pachetului;

Socket: id-ul aplicație căreia pachetul îi este destinat;

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

5.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

Figura 1 (Capitolul 5) : Arhitectura MeshSPF

Semnificația câmpurilor pachetului Multi-hop DownStream sunt următoarele:

Socket: id-ul aplicație căreia pachetul îi este destinat;

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

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 destinație (șir
de tipul părinte-copil)

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

5.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 către 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.

Funcțiile principale ale componentei Designated Router Other a potocolului MeshSPF sunt:

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

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 legăturilor
dintre nod și vecinii acestuia;

recepționarea unui mesaj Route Update de la bază prin care nodul este informat că
poate pătrunde în rețea și care conține „părintele” nodului curent (părintele nodului
va fi nodul cu rol de router prin care nodul curent va transmite pachetele de date și de
protocol destinate bazei);

monitorizarea legăturilor dintre un nod al rețelei și nodurile cu rolul de copil sau părinte al acestuia.

Fiecăreia 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 protocoale de comunicare folosite.

5.2.1 Starea Discover și Protocolul Discovery

5.2.1.1. 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 această 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ăturilor 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.

5.2.1.2. 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ăturilor dintre nodul curent si vecinii acestuia,
algoritmul de calcul folosit pentru calcularea calității legăturii dintre noduri precum și
algoritmul de calcul al costului total de transmisie către bază și de alegere al unui părinte
inițial.

Trebuie evidențiată importanța procesului Discover pentru întregul protocol MeshSPF, deoarece acest proces permite o estimare calitativă foarte bună a legăturilor dintre
nodul care dorește să intre în rețea ș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 în 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:

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;

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.

De asemenea, pe parcursul stării Discover, la fiecare interval de puls, nodul transmite broadcast un pachet Discovery Beacon, a cărui rol și structură sunt prezentate în 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ționează să pătrundă în 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 legăturilor cu aceștia (se formează astfel perechi discovery beacon – discovery beacon ackwoledge).

Din perspectiva nodului care recepționeza un pachet Discovery Beacon, putem identifica alte două situații: nodul receptor se află deja in rețea (starea Route), caz ce va fi prezentat in subcapitolul 5.2.4 Starea Route și Protocolul Hello; nodul receptor nu face parte din rețea. În acest al doilea caz, receptorul va folosii datele incluse de către emițător pentru a iniția sau actualiza înregistrarea 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.

Semnificațiile câmpuriilor acestuia sunt următoarele:

Type: indică tipul pachetului din perspectiva protocolului de rutare (pentru discovery
beacon fiind specificat tipul DISCOVERY_BEACON, care are valoarea 0x73)

Parent: indică id-ul părintelui nodului emitent la un moment dat.

Cost: indică costul de transmisie upstream către bază, pentru a putea permite altor
noduri care nu fac încă parte din rețea să aleagă un părinte cât mai bun.

Listă vecini: nodul emitent precizează mai întâi numărul 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 această
situație vor fi incluse in pachet, secvențial, porțiuni succesive din Tabela Vecinilor.

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 înregistrare 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 (numărul
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 privind starea înregistrării.

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.

5.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 încapsulat 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 recepționării unui pachet primit de la unul dintre copii săi, părintele analizează antetul TinyOS al pachetului pentru a determină 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.

Î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 transmise sub forma unei secvențe de astfel de pachete. Pentru a putea identifica un anumit pachet din această secvență, în antetul Neighbors Advertisment a fost inclus câmpul AdvertiseNo. Transmimsia efectivă a Tabele Vecinilor unui nod se încheie prin transmiterea unui pachet care are în câmpul Număr Advertisment valoarea 254.

Transmiterea pachetelor Neighbors Advertisment de la un anumit nod către bază este
realizată într-o manieră sigură, pentru fiecare pachet recepționat de la un anumit nod , baza trebuie să transmită DownStream un pachet Neighbors Acknowledge. Recepționarea unei secvențe este considerată încheiată doar după primirea pachetului cu AdvertiseNo egal cu
254. Privind din perspectiva nodului, acesta așteaptă , după transmiterea unuia dintre 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 către 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 pachetelor Neighbors Advertisment către bază eșuează dacă este depășit numărul maxim de retransmisii permise pentru un pachet.

5.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 pachetele primite de la alte noduri (sunt ignorate inclusiv pachetele Discovery Beacons). De altfel singurele pachete pe care nodul le 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 punct de vedere pentru nod prezintă interes câmpurile Road și
RoadLen a căror verificare permite nodului să decidă dacă pachetul îi este destinat 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

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.

5.2.4 Starea Route și Protocolul Hello

5.2.4.1 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ă le 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 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 pachetele î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 copii 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 le 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

utile să le recepționeze.

5.2.4.2. 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).

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ăturii 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 secvență 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ă această 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 recepționat. Astfel dacă acest număr depășeș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 pierderea legăturii cu unul dintre vecinii săi

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

5.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, 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 interfaț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 5.3.2 și 5.3.3.

5.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.

5.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 pentru 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ă le genereze în momentul în care recepționează 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ărcinat 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 semnale Discovery Beacon, transmis de un nod care sondează vecinătatea, să transmită o serie de cinci semnale 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 simplificată 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ă.

5.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 spre aplicația utilizatorului 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ținerea rutelor și detectarea eventualelor schimbări ale topologiei. DRBase folosește o Tabelă a Copiilor, similară cu cea de pe nodurile ce folosesc modulul DROther, prin intermediul căreia monitorizează situația legăturilor 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 acesta, un câmp idlePeriod, care contorizează numărul de intervale de puls care au trecut fără ca baza să primească un pachet Hello de la nod, si un byte de flag-uri care evidențiază 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 pachete ș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ă pierderea 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.

5.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 secvență 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ă.

Î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.

5.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 algoritmul 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 Fig 2 este prezentată arhitectura MeshSPF Router sub forma interacțiunii dintre obiectele ce o compun (fiind vorba de o dezvoltare a acesteia în limbajul orientat pe obiecte C#, fiecărei componentă îi este asociat un obiect) .

Figura 2 (Capitolul 5) : Arhitectura MeshSPF Router

5.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] ).

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.

5.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, 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 (Capitolul 5) : Tabelele PostgreSQL

5.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.

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 această conexiune este deschisă.

5.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 realizată prin intermediul serviciului XServe și respectând specificațiile protocolului Seria Forwarder. Tipul principal de pachete pe care acesta le generează și le 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ă.

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 le 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.

5.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ă operațiile prezentate în paragrafele următoare.

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 le 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.

CAPITOLUL 6

Studiu de caz: Proiectarea unei rețele wireless pentru un campus universitar

6.1. De ce wireless?

În ultimii 10 ani, impactul rețelelor wireless asupra învățământului, dar mai ales asupra sectorului business, a fost probabil depășit doar de evoluția Internetului. Rețelele wireless, prin sporul de mobilitate și de autonomie oferit fac conceptul de E-learning mai puternic și îi lărgesc perspectivele.

În ciuda acestui avânt, se consideră că rețelele wireless sunt încă la început, următorul pas în evoluția lor fiind suplimentarea sau înlocuirea tuturor structurilor anterior construite cablat.

De la internet-café-uri, până la sisteme comerciale pentru controlul inventarului, în restaurante sau aeroporturi, accesarea informațiilor publice sau comunicația între utilizatori sau echipamente, începe să devină posibilă.

Foarte multe industrii și companii migrează către zona wireless. Trei dintre industriile ce își dezvoltă foarte mult capabilitățile wireless sunt industria hotelieră, aeroporturile pentru a acoperi nevoia de comunicație a celor ce întreprind călătorii de afaceri, precum și sistemele de educație ce urmăresc crearea unor infrastructuri de comuncație în campusuri.

Dacă nevoia de conectivitate este acoperită la serviciu sau acasă prin folosirea conexiunilor deja existente, o noapte sau chiar o săptămâna petrecută la un hotel oferă puține opțiuni: fie se poate folosi o conexiune via modem de 56kbps, fie poate fi folosită o conexiune wireless. Hotelul poate pune la dispoziție informațiile necesare privind configurația, precum și o unelte software, astfel încât clientul ce desfășoară o călătorie de afaceri să poată fi satisfăcut.

Aeroporturile oferă astfel de servicii pentru a crește productivitatea călătorilor, care ar fi altfel separați de resursele informatice ale companiei. Tehnologiile wireless permit accesul la Internet, e-mail și chiar la site-urile de intranet ale companiilor folosind soluții de rețea virtuală privată (VPN). Această creștere de productivitate devine tot mai interesantă pentru companii a căror forță de muncă devine din ce in ce mai mobilă.

Universitățile își dezvoltă structurile wireless pentru a permite accesul informațional de tip oriunde/oricând pentru studenți în interiorul campusurilor. Întrucât o mare cantitate de material didactic devine tot mai mult accesibil numai pe Internet, o astfel de facilitate devine necesară.

Aceste deziderate sunt împlinite prin următoarea metodă:

hotelul, aeroportul sau universitatea încheie un contract cu un Wireless Internet Service Provider (WISP);

WISP instalează Access-Point-uri și Access-Servere astfel încât acoperirea wireless să fie completă în instituția respectivă.

6.2. Proiectarea unei rețele wireless pentru un campus universitar

Există numeroase avantaje în folosirea unei rețele wireless într-un astfel de mediu, în detrimentul unei rețele cablate tradițional. Aceste avantaje vizează atât aspectul financiar întrucât se elimină costurile săpării șanțurilor pentru instalarea cablurilor, cât și cel temporar prin timpul economisit prin eliminarea acestor instalări. Tehnologiile wireless permit introducerea unei arhitecturi a rețelei cu dinamicitate crescută și totodată măresc eficiența costurilor, lucru esențial în ideea asigurării unui management flexibil. Tehnologiile evoluează mai rapid decât tehnologiile tradiționale ce folosesc infrastructuri cablate. Având la dispoziție tehnologii noi, este mult mai simplu de modificat o arhitectură wireless, pentru a rezolva problemele ce vizează nevoile crescânde ale organizației.

Aceste avantaje pot fi foarte considerabile nu numai pentru acoperirea scopurilor unei rețele a unui campus universitar (dacă luăm în considerare posibilele schimbări ale structurii departamentale), ci chiar pentru orice companie cu dinamicitate ridicată.

Primul pas în proiectarea unei rețele wireless ce va deservi un campus universitar constă în determinarea departamentelor ce solicită servicii de date, precum și determinarea nevoilor lor curente. Dacă considerăm nevoile unei universități cu o organizare similară universităților românești, există 4 sectoare ce vor solicita astfel de servicii: sectorul administrativ al universității, sectorul academic, organizațiile studențești și studenții îșiși. Dacă considerăm un model organizatoric al unei universități americane, ar putea exista un al 4-lea departament cu nevoi de comunicație, și anume departamentul atletic.

În continuare vom analiza nevoile actuale și viitoare ale grupurilor funcționale menționate.

6.2.1. Nevoile sectorului administrativ al universității

Departamentul Administrativ al universității are 3 funcții principale:

contabilitate;

recrutare;

marketing.

În ce privește funcția de contabilitate, contabilii fac în fiecare zi înregistrări privind încasările, cheltuielile și bugetul. Înregistrările corespunzătoare fiecărui student sunt păstrate în zona de recrutare. Responsabilii cu marketing-ul pot fi foarte interesați de noua arhitectură de rețea, întrucât se poate dezvolta un site prin care sa se poată anunța noile tehnologii disponibile în cadrul universității. Acesta poate deveni un lucru pozitiv pe termen lung, prin creșterea atractivității universității pentru viitorii studenți. Așadar, nevoile complete ale departamentului administrativ se înscriu în următoarele linii:

rețea de viteză mare care sa servească fiecare nivel al clădirii administrative;

conectivitate de viteză mare între etajele clădirii administrative pentru a preîntâmpina nevoile de comunicație între elementele funcționale ale departamentului administrativ;

conectivitate de viteză mare între etajele clădirii și camera serverelor pentru a suporta transferuri frecvente de fișiere mari;

acces la Internet în scopul promovării imaginii universității.

6.2.2. Nevoile sectorului academic al universității

Departamentele de Inginerie, Biologie si Arte solicită servicii similare. Instructorii vor putea accesa fiecare sală și fiecare birou din cadrul departamentului lor. Totodată posibilitățile de cercetare ar crește substanțial în condițiile în care este pus la dispoziție și accesul la Internet. Fiecare din aceste departamente va avea de asemenea nevoie de conectivitate cu clădirea administrativă pentru a se putea face update-uri cu notele studenților. Iată nevoile concrete ale departamentului academic:

conectivitate mobilă la toate etajele clădirii fiecărui departament pentru a servi nevoia instructorilor de a avea acces virtual în fiecare sală sau birou;

acces la Internet pentru colaborarea cu alte universități și proiecte de cercetare; acest lucru va veni în ajutorul întregului sector academic prin accesul la materiale de studiu;

conexiune dedicată cu clădirea administrativă pentru a se putea face înregistrări privind notele studenților, prezența, și încheierea cursurilor.

6.2.3. Nevoile organizațiilor studențești

Organizațiile studențești își doresc posibilități de comunicație pentru angajații lor și pentru studenți, și de aceea solicită o rețea de viteză ridicată care să ofere mobilitate în interiorul propriei clădiri.

6.2.4. Nevoile studenților

Studenții își doresc conectivitate în camerele de cămin, în interiorul organizațiilor studențești și la toate etajele clădirilor academice. Așadar, următoarele puncte adresează nevoile lor:

acces la Internet din interiorul clădirilor academice și din camerele de cămin;

conectivitate mobilă la toate etajele clădirilor academice;

conectivitate mobilă de viteză mare în interiorul căminului;

conectivitate de viteză mare între cămine și clădirea organizației studențești din care fac parte.

6.2.5. Premizele de proiectare

Având în vedere cerințele definite mai sus, se pot face o serie de presupuneri ce vor ușura procesul de proiectare. Astfel:

rețeaua va folosi protocolul Internet (IP). Alocarea IP-urilor se va face dinamic, în funcție de locul în care se află respectiv, și va include și o procedură de autentificare. Se poate face o analiză statistică care să evidențieze numărul maxim de studenți ce se vor afla la un moment dat într-una din clădirile administrative, pentru a determina dimensiunea spațiului adresabil;

tehnologiile noi, cu potențial de risc în ce privește pierderile de date vor fi folosite numai pentru construirea rețelelor non-critice;

întrucât fiecare etaj al unei clădiri are funcționalitate bine determinată, va fi tratat ca un domeniu logic sau sub-rețea separată. Acest lucru este valabil doar pentru sectorul administrativ. Conectivitatea studenților va fi tratată ca o singură sub-rețea întinsă în întregul cămin. Cu alte cuvinte, etajele căminelor studențești vor fi conectate într-o arhitectura Layer 2, și nu ca sub-rețele diferite.

vor fi folosite tehnologii wireless pentru aplicații orizontale (conectarea etajelor individuale și conexiunile între clădiri) și legături cablate pentru aplicațiile verticale (conexiunile între etaje).

Acestor premize li se adaugă obstacolele de natură fizică (dificultăți legate de interferențe, de obstacole, sau distanțe între clădiri) sau logică (privind spațiul de adresare, licențierea a spectrului folosit, etc.) întâmpinate ce vor fi specifice universității ce reprezintă subiectul proiectului și vor trebui analizate și documentate minuțios.

6.2.6. Proiectarea rețelei departamentului administrativ

Departamentul administrativ solicită conectivitate locală de viteză ridicată la fiecare nivel al clădirii, astfel că se va putea folosi tehnologia 802.11a. Acest lucru permite conectivitate mobilă pentru angajații departamentului la nivelul întregului etaj. Aceste rețele wireless vor fi conectate la backbone-ul clădirii prin legături Fast Ethernet (100 Base T) prin intermediul unor routere care vor separa domeniile adresabile ale fiecărui etaj. Întinderea și funcțiile fiecărui sub-departament vor determina spațiul adresabil necesar. Totodată routerele arondate fiecărui etaj vor avea rolul de a rezolva conectivitatea logică între sub-grupurile funcționale ale departamentului administrativ. Tehnologia Fast Ethernet aleasă pentru interconectarea etajelor clădirii are avantajul sporului de viteză și al costului redus.

Solicitării departamentului administrativ de a dispune de o legătură rapidă între etaje și camera serverelor, i se va răspunde prin proiectarea unei legături Fast Ethernet dedicate fiecărui etaj. Vom avea astfel trei legături Fast Ethernet între routerele corespunzătoare fiecărui etaj și routerul ce deservește serverele universității. Conectarea serverelor cu routerul corespunzător se va face printr-o legătură Gigabit Ethernet.

Presupunând că punctul de demarcație pentru conexiunea la Internet se află în clădirea administrativă, accesul la Internet pentru angajații departamentului se va face sub protecția unui firewall ce va fi situat între punctul de demarcație și routerele fiecărui sub-departament.

Figura 3.1

6.2.7. Proiectarea rețelei departamentului academic

Departamentul academic solicită conectivitate de viteză ridicată fiecare nivel al clădirilor pentru accesul virtual al instructorilor în fiecare sală și birou, de aceea se va alege aceeași tehnologie 802.11a. Rețeaua folosită de personalul catedrelor va avea un caracter privat, nefiind accesibilă studenților, în ideea păstrării confidențialității și securității anumitor date cum ar fi notele sau conținutul testelor de evaluare. Etajele fiecărei clădiri academice vor fi conectate prin switch-uri constituind astfel o singură entitate logică. Acest lucru va permite corpului profesoral să se poată deplasa între etaje fără să fie nevoie de repornirea conexiunilor TCP și realocarea unei noi adrese IP.

Conexiunea la Internet cerută de departamentul administrativ se va face prin proiectarea unei legaturi radio (folosind 802.1q, având în vedere distanța relativ mică între clădiri) către clădirea administrativă. Studiul amănunțit al potențialului trafic între sectorul academic și cel administrativ pentru înregistrarea notelor sau a altor observații referitoare la studenți, va evidenția necesitatea proiectării unei alte legături între aceste două clădiri.

Figura 3.2

6.2.8. Proiectarea rețelei organizației de studenți

Întrucât cerințele de conectivitate sunt asemănătoare cu cele formulate de departamentul academic, se va folosi aceași arhitectură (fiecare etaj al clădirii este acoperit de un Access-Point 802.11a, iar etajele sunt conectate prin Fast Ethernet switching). Pentru conexiunea la Internet se va proiecta deasemenea un link radio 802.11a cu clădirea administrativă.

Figura 3.3

6.2.9. Proiectarea rețelelor studențești

Accesul studenților la Internet și la alte resurse ale universității din camerele de cămin se va face printr-o legătură dedicată 802.11a cu clădirea organizației stundețești. Rețele ce vor deservi căminele vor avea o arhitectură bazată pe comutare (Layer 2), folosindu-se tehnologii wireless 802.11a la fiecare etaj, iar etajele fiind interconectate prin Fast Ehernet. Se poate opta pentru această arhitectură deoarece este dezirabil să nu fie necesară refacerea conexiunilor IP odată cu deplasarea în interiorul căminului. Totodată, alocarea adreselor IP pentru mașinile din interiorul căminelor se va face dinamic (prin DHCP), folosindu-se și o metodă de autentificare (via RADIUS). Fiecare cămin va avea alocată o adresă IP ce va fi rutată către routerul din clădirea organizației stundențești pentru accesul la Internet.

Figura 3.4

6.2.10. Standardul 802.11a

Fiind tehnologia pe care am amintit-o cel mai frecvent în proiectarea rețelei imaginare a unui campus universitar, voi detalia câteva aspecte ale 802.11a.

Datorită cererii tot mai mare de bandă și a numarului tot mai mare de tehnologii ce operau în banda nelicențiată de 2,4GHz, standardul 802.11a a fost creat ca un upgrade al standardului 802.11b, oferind posibilități de transfer de 25 până la 50Mbps în spectrul de 5GHz (unlicensed national information infrastructure – U-NII). Fiind un spectru relativ liber în momentul de față, posibilitățile de interferență sunt reduse. Standardul specifică OFDM (Orthogonal Frequency Division Multiplexing) ca metodă de multiplexare și are asociate 3 benzi de frecvență fiecare de câte 100MHz (5.15GHz – 5.25GHz, 5.25GHz – 5.35GHz și 5.725GHz – 5.825GHz).

Figura 3.5

CONCLUZII

Rețele de senzori wireless au cunoscut o dezvoltare accentuată î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 constrângerile 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 le 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ținerea 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 folosite 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 componente 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 intermediul folosirii algoritmului propus
de Dijkstra s-a rezolvat intr-o manieră eficientă și problema formării buclelor de rutare.

A

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 exemplu algoritmul DUAL Diffusing Update ALgorithm), cât și pe extinderea tabelelor de rutare la nivel de nod pentru a oferii o mai mare stabilitate.

BIBLIOGRAFIE

1 Sinem Coleri Ergen, ZigBee/IEEE 802.15.4 Summary, Septembrie 2004.

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 Addison Wesley, OSPF. Anatomy of an Internet Routing Protocol, Februarie 1998.

11 James Macfarlane, Network Routing Basics, Understanding Ip Routing in Cisco Systems, 2006

12 Jeff Doyle, Jennifer Carroll, CCIE Professional Development Routing TCP/IP, Volume I, Second Edition, Octombrie 2005

13 Henry Benjamin, CCNP Practical Studies: Routing First Edition, Aprilie 2002

14 http://en.wikipedia.org/wiki/Dijkstra's_algorithm

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