Ma plictisesc…sau stau pe net. Azi in mod special, m-am ocupat de ceea ce urmeaza…

4.6 Quality of Service

 Problemele de QoS sunt discutate în perspective de reţea end-to-end, cu accent pe felul în care se realizează serviciul de QoS între endpoints pe o reţea de tip packet-switched wireless broadband, care în plus faţă de linkul wireless poate include şi alte link-uri conectate prin routere, switch-uri sau alte dispozitivie de reţea. Link-urile dintre nodurile intermediare pot folosi o varietate de tehnologii de nivel 2, precum ATM, frame relay sau Ethernet, fiecare dintre acestea putând avea propriile metode de QoS. Am realizat trecerea in revistă a cerinţelor şi metodelor de QoS în reţele de tip packet-switched şi felul în care se realizează acest QoS cu tehnologiile de nivel 3. Cum WiMAX îşi propune să realizeze servicii IP de tip end-to-end şi este cel mai probabil implementat pe o reţea de tip IP, serviciul de QoS IP şi interacţiunea sa cu nivelul wireless sunt relevante pentru performanţele sistemului.

Prin QoS se înţelege un tip de asigurare a faptului că un serviciu va fi realizat la anumite standarde. Nivelul de performanţă este specificat în termeni de throughput, packet loss, delay şi jitter, iar cerinţele variază în funcţie de aplicaţie şi serviciu. Forma de asigurare variază deasemenea de la măsurători cantitative (garanţia că toate pachetele de voce vor fi trimise în mai puţin de 100ms delay în 99% din timp) la masurători calitative de tipul: anumiţi utilizatori vor avea prioritate în faţa altora. Aceste măsuri se justifică prin accesul concurent la resursele limitate existente în orice reţea: canalul radio, precum şi link-urile intermediare şi nodurile care procesează informaţiile. Fiecare link are nişte limite legate de bandwidth, iar fiecare nod are limitări de memorie pentru buffararea pachetelor pe care le rutează. Contruirea unei infrastructuri permisive la capacităţi şi lăţimi de bandă foarte mari nu este o soluţie din cauza costurilor ridicate. De aceea trebuie realizate metode mai eficiente pentru a face QoS, iar aceste metode trebuie să ia în calcul cerinţele aplicaţiei sau serviciului şi să optimizeze resursele folosite. Aplicaţii diferite cer un ansamblu diferit de resurse. De exemplu, aplicaţiile intolerante la latenţă necesită acces mai rapid la bandă şi nu la memorie, pe când aplicaţiile tolerante la latenţă pot folosi resurse de memorie pentru a evita pierderea de pachete cât timp aşteaptă pentru accesul la resursele de bandă. Aceste informaţii pot fi folosite la realizarea unei politici de QoS eficiente.

Mecanisme de QoS

Se pune problema realizării unui mecanism de QoS pe o reţea, atât pe control plane, cât şi pe data plane. Mecanismele de control plane sunt necesare pentru a permite utilizatorilor şi reţelei să negocieze şi să stabilească specificaţiile de QoS, să identifice care utilizatori şi care aplicaţii au dreptul la ce tip anume de QoS şi să permită reţelei să aloce resurse în mod potrivit fiecărui serviciu. Mecanismele de data plane sunt necesare pentru implementarea de QoS prin controlul cantităţii de resurse pe care fiecare aplicaţie sau utilizator le poate avea alocate.

Mecanismele de control plane includ QoS policy management, semnalizare şi controlul admisiei. Politica de management QoS presupune definirea şi furnizarea de anumite nivele şi tipuri de servicii de QoS, precum şi managementul accesului fiecărui serviciu şi fiecărei aplicaţii la o politică de QoS. Figura de mai jos arată o politică de management de sistem descrisă de IETF care poate fi folosită pentru politici de QoS. Componentele sistemului includ un depozit de politici (în esenţă acesta este un director care conţine date despre politici, precum username, aplicaţii şi resursele reţelei la care aceştia au acces), sisteme de tip PDP – Policy Decision Points (acestea traduc politicile de nivel înalt în informaţii de configurare concrete de la fiecare dintre noduri), PEP – Policy Enforcemente Points ( nodurile de pa calea de transmitere a datelor care realizează acţiunile indicate de PDP) şi protocoale de comunicare între depozitul de date, PDP şi PEP. Exemple de astfel de protocoale sunt LDAP (Lightweight Directory Access Protocol – între depozitul de date şi PDP) şi COPS (Common Open Protocol Services – între PDP şi PEP).

Figura 4.7. Sistem de management al politicii de QoS

 Semnalizarea se referă la felul în care un utilizator comunică cerinţele de QoS către reţea. Mecanismele de semnalizare pot fi statice sau dinamice. În cazul celor statice, sistemele PDP iau datele de politică de informaţii de la nivelul superior şi le traduc în informaţie de configurare care este apoi împinsă pe fiecare PEP ce impune aceste politici. În cazul celor dinamice, cerinţele de QoS sunt semnalizate de către aplicaţie sau utilizator, chiar înainte ca acestea să înceapă transmisia de date. RSVP (Resource Reservation Protocol) este un protocol folosit de acest tip de semnalizare: când sistemul PEP primeşte o cerere pentru un serviciu QoS, acesta verifică pe PDP dacă acel utilizator/serviciu/aplicaţie are dreptul la acel serviciu, iar dacă acest lucru se întâmplă, sistemul PEP alocă resursele necesare cerinţelor de QoS.

Controlul admisiei este a treia funcţie de control plane şi reprezintă capacitatea unei reţele de a permite sau nu accesul la reţea a traficului nou. Funcţia este necesară să asigure ca traficul nou să fie permis în reţea numai dacă această admisie nu va compromite performanţele traficului actual. Controlul admisiei poate fi realizat fie la fiecare nod (per-hop basis), fie la nodul de ingress, fie de către un sistem centralizat care cunoaşte condiţia reţelei.

Mecanismele de data plane implementează tipul de QoS agreat, prin clasificarea pachetelor primite în câteva cozi şi alocarea de resurse pentru fiecare coadă. Clasificarea se face prin inspecţia headere-lor acestor pachete, alocarea de resurse se face prin folosirea algoritmilor de alocare şi tehnicilor de buffer management pentru stocarea şi forwardarea pachetelor din fiecare coadă. Sunt două abordări diferite pentru definirea acestor cozi. Prima abordare se numeşte “per-flow handling” şi presupune existenţa cozilor separate pentru fiecare sesiune sau flow de mesaje. În acest caz pachetele care aparţin unei anumite sesiuni sau flux de mesaje trebuie să fie unic identificate. Pentru traficul IP, cele 5 câmpuri din headerul IP identifică unic un mesaj: adresele IP sursă, respectiv destinaţie, porturile sursă şi destinaţie şi câmpurile protocolul de transport.Metodele InitServ definite de IETF folosesc acest tip de abodare pentru pachetele IP. Din perspectiva utilizatorului final, abordarea aceasta este mai bună ca şi calitate a experienţei, de moment ce o anumită sesiune primeşte un set de resurse independent de celelalte sesiuni. Cu toate acestea, abordarea de tip “per-flow” cere ca fiecare nod de reţea să păstreze starea fiecărei sesiuni şi să aplice o procesare independentă, care devine greoie sau nepractică când numărul de fluxuri devine foarte mare, mai ales în partea centrală a reţelei. A doua abordare presupune clasificarea pachetelor în câteva clase generice şi punerea fiecărei clase într-o alta coadă – denumirea ei este “aggregate handling”, deoarece cozile în acest caz vor consta din pachete de la mai multe sesiuni sau fluxuri. Şi aici se realizează o formă de identificare a header-ului pentru a determina cărei clase agregate aparţine respectivul pachet.DiffServ şi 802.1p sunt exemple de mecanisme de agregare de trafic pentru pachetele IP şi Ethernet. Abordarea duce la scăderea necesarului de mentenanţă şi a celui de calcul pe nodurile de reţea şi este mult mai scalabilă decât metodele de clasificare per flux. Calitatea experienţei în cazul utilizatorului este compromisă parţial, de moment ce traficul acestuia este afectat de traficul celorlalţi utilizatori.

Atât mecanismele de control plane, cât şi cele de data plane presupun compromisuri. O complexitate mai mare, în ambele cazuri, poate duce la o calitate mai bună. In control plane, deciziile de control al admisiei şi eficienţa alocării de resurse pot fi îmbunătăţite dacă utilizatorul semnalizeaza cerinţele cu un grad ridicat de detaliere; fapt care măreşte complexitatea mecanismelor de data plane, precum programarea în timp şi managementul bufferelor. Arhitecţii de reţele trebuie să reducă complexitatea redundantă, păstrând un nivel ridicat de QoS.

Tehnologii QoS

Reţelele IP tradiţionale au fost realizate pentru transmiterea datelor la un nivel de best-effort şi nu includeau niciun sistem de tip QoS. O formă incipientă de QoS se putea realiza prin protocoalele ce trec peste IP; de exemplu protocolul TCP asigură faptul că datele sunt transmise la distanţă fără erori. În mod similar, protocolul RTP se asigură de trimiterea la o anumită secvenţă a pachetelor pentru a putea asculta un stream de date fără întreruperi. Aceste protocoale nu au însă niciun mecanism de control pentru delay-ul dintre capetele conexiunii sau al throughput-ului. Pentru asigurarea unui throughput şi a unei latenţe de la un capăt la celălalt, trebuie folosite mecanismele de QoS. IETF a propus 3 astfel de mecanisme:

1. Integrated Services (IntServ);

2. Differentiated Services (DiffServ);

3. Multiprotocol Label Switching (MPLS).

1.      Integrated Services

Arhitectura IntServ este folosită pentru QoS-ul de tip per-flow cu o granularitate mare prin folosirea semnalizării dinamice end-to-end şi a RSVP în toată reţeaua. Arhitectura aceasta suportă trei tipuri de QoS. Guaranteed services furnizează garanţii de calitate hardware, incluzând limite superioare exacte pentru delay-ul end-to-end şi pentru jitter şi zero packet loss din buffer overflow. Acest tip de QoS îşi propune emularea unui serviciu de tip circuit-switched dedicat în IP. Controlled load services furnizează garanţii calitative pentru aproximarea serviciului pe care un utilizator l-ar avea într-o reţea puţin încărcată. Acest serviciu asigură o rată susţinută, dar nu prevede asigură împotriva delay-ului sau pierderii de pachete. Best-effort services nu furnizează nicio garanţie şi nu prevede nicio rezervare de resurse.

IntServ foloseşte RSVP pentru semnalizarea cerinţelor de QoS la nivel end-to-end şi pentru realizarea acestor rezervări. Mesajele RSVP poartă informaţii despre modul cum o reţea poate identifica un anumit flux, parametri cantitativi ai acelui flux, tipul lui de serviciu şi informaţii despre politică: identitatea utilizatorului şi aplicaţiei. Parametri cantitativi care descriu fluxul sunt specificaţi în standardul TSPEC (traffic specifications). Garanţiile de serviciu sunt furnizate dacă şi numai dacă pachetele din flux sunt conform parametrilor din TSPEC. Acest standard caracterizează traficul prin folosirea unui model cu token-uri, prin următorii parametri: p-peack rate (rata maximă de transfer), m-minimum policed unit (unitatea minimală pe care se face o politică de QoS), M-maximum packet size (dimensiunea maximă a pachetului), b-bucket depth şi r-bucket rate. Un flux este considerat conform TSPEC atâta timp cât cantitatea de trafic generat la orice moment de timp t este mai mică decât min[(M+pt),(b+rt)]. În esenţă, utilizatorul poate trimite până la 8 bytes de date ca rată maximă a p, dar trebuie să-şi scadă rata la r după aceea. TSPEC este folosit de emiţător pentru a-şi caracteriza traficul. Un standard asemănător, FlowSpec, este folosit de către receptor pentru a descrie profilul traficului pe care el ar dori să-l primească. Pentru serviciile care controlează încărcarea, parametrii FlowSpec sunt la fel ca cei ai TSpec, desi valorile pot să difere. Pentru serviciile care oferă garanţia unui nivel de calitate se folosesc parametrii FlowSpec, alături de o rată R şi un parametru slack S – unde R este rata cerută, iar S este diferenţa dintre delay-ul dorit şi delay-ul care ar fi obţinut la rata R. Un nod poate folosi perioada S pentru a reduce cantitatea de resurse rezervate pe flux. Modul în care funcţionează RSVP este descris în continuare… Aplicaţia emiţătoare trimite un mesaj PATH către receptor. Mesajele PATH includ o descriere TSpec a datelor pe care emiţătorul doreşte să le trimită şi calea pe care doreşte ca ele să o urmeze. Toate nodurile care ştiu RSVP din calea aceasta stabilesc o stare pentru acel flux şi trimit mesajele următorului router care poate procesa cererea. Stările RSVP trebuie împrospătate. Fiecare router îşi poate face publice capabilităţile, precum delay-ul pe link sau throughput-ul, printr-un alt set de specificaţii, numit ADSpec(advertised specifications). Receptorii răspund unui mesaj PATH prin trimiterea unui mesaj RESV cu o cerere de QoS înapoi către emiţător, pe aceeaşi cale. Mesajul RESV conţine un FlowSpec care arată reţelei şi aplicaţiei emiţătoare profilul de trafic pe care receptorul doreşte să-l primească. Receptorul poate folosi ADSpec pentru a se asigura că nu face o cerere care depăşeşte capabilităţile declarate ale reţelei. Toate nodurile care ştiu RSVP şi primesc un mesaj RESV verifică faptul că ele au resursele necesare pentru a realiza acea cerere de QoS. Dacă resursele sunt disponibile, sunt şi alocate, iar mesajul RESV este trimis mai departe la următorul nod către emiţător. Dacă un anumit nod nu poate rezerva resursele cerute de RSVP, este trimis un mesaj de reject către receptor. Fiecare nod ia propriile decizii de control al admisiei. Protocolul RSVP facilitează controlul admisiei bazându-se pe politicile de reţea: nodurile pot extrage informaţia de politică şi din mesajele PATH/RESV şi verifică faptul că ele acţionează conform politicii reţelei. Această verificare poate fi realizată folosind protocolul COPS.

Politicile de QoS sunt specificate de receptor. Acest lucru se întâmplă nu mai pentru că receptorul plăteşte pentru respectivul serviciu, ci şi pentru a putea folosi QoS şi pe recepţia de tip Multicast, unde mai mulţi utilizatori pot primi diferite porţiuni sau versiuni ale serviciului. Serviciul Multicast este facilitat prin permiterea agregării mesajelor RESV de la mai mulţi receptori către acelaşi emiţător. Deasemenea, protocolul RSVP face rezervări într-o singură direcţie, de aceea fiind nevoie de două rezervări separate dacă se doreşte QoS în ambele direcţii. Deşi arhitectura IntServ cu RSVP furnizează cel mai înalt nivel de QoS pe IP, are câteva limitări majore. În primul rând, managementul traficului se face la nivel de flux, fiind afectat de limitările de scalabilitate (controlul fluxurilor de la un milion de utilizatori ar fi foarte greu de realizat). În al doilea rând, acesta prezintă nevoia de actualizare periodică a stărilor conexiunilor, fapt care aduce un overhead foarte mare în reţea. În al treilea rând, cum RSVP nu foloseşte un protocol de încredere de tipul TCP, mesajele de semnalizare pot fi pierdute. În al patrulea rând, IntServ şi RSVP sunt protocoale relativ complexe şi greu de implementat. În al cincilea rând, RSVP are nevoie şi de o infrastructură de autentificare pentru a asigura validitatea cererilor de rezervare. Deşi unele dintre aceste limitări pot fi rezolvate, ele au facut din IntServ o arhitectură greu de implementat pe core-le reţelelor IP, rămânând eficient în reţelele mici. Unele dintre limitările IntServ au fost rezolvate prin arhitectura DiffServ.

2.      Differentiated Services

Identificând problemele de scalabilitate care împiedică folosirea pe scară largă a IntServ, IETF a început dezvoltarea unui nou model în 1997, pentru a furniza QoS fără overhead-ul semnalizării şi nevoii de menţinere a stării, specifice IntServ. Noul model împarte traficul într-un număr mic de clase şi tratează fiecare clasă în mod diferit. DiffServ foloseşte câmpul de TOS din pachetul de IP pentru marcarea pachetelor dintr-o anumită clasă. Marcajul este un label de 6 biţi numit DSCP – DiffServ Code Point. Figura de mai jos arată o colecţie de routere care fac parte dintr-un domeniu DiffServ. În mod normal, un utilizator sau o aplicaţie care trimit trafic printr-un domeniu DiffServ marchează fiecare pachet trimis cu label-ul DSCP dorit. Routerul de tip ingress-edge clasifică aceste pachete în diferite cozi, pe baza DSCP, apoi măsoară traficul submis pentru a fi conform cu profilele stabilite, iar dacă pachetele nu sunt conform acestor profile, schimbă valoarea DSCP a acelor pachete. Routerul ingress poate face şi traffic-shaping prin întârzierea sau aruncarea pachetelor. Într-o reţea DiffServ, routerul de hotar face controlul admisiei în reţea şi se asigură că numai traficul acceptat este injectat în reţea. Toate celelalte routere din reţeaua DiffServ folosesc DSCP pentru a aplica diferite metode de încadrare în cozi sau programare pentru livrare a pachetelor – comportament numit PHB – per hop behavior, al unei anumite clase. Într-o reţea DiffServ pot fi definite mai multe sisteme PHB. De exemplu, un PHB poate garanta un nivel minim al benzii disponibile pentru o anumită clasă. IETF a standardizat două sisteme PHB.

PHB Expedited forwarding – EF este RFC 2598: Pachetele marcate pentru trimitere primesc cea mai mare prioritate. Fiecare router trebuie să aloce o bandă fixă pe fiecare interfaţă pentru traficul de tip EF şi să routeze aceste pachete cu delay minim. EF este folosit în principal la emularea unui circuit virtual pentru aplicaţii sensibile la întârzieri. Pentru a evita ca traficul EF să fie aruncat sau întârziat, routerul de hotar trebuie să se asigure că are destule resurse pentru admisia în reţeaua DiffServ. Pachetele pot fi aruncate dacă utilizatorul depăşeşte rata maximă agreată anterior.

PHB Assured forwarding – AF este un grup de PHB definit în RFC 2597: are 4 clase independente, fiecare cu câte trei nivele de precedenţă. Fiecare clasă are bandă alocată separate, dar niciuneia nu i se garantează această bandă. Dacă bufferele alocate pentru o clasă se umplu, pachetele din acea clasă vor fi aruncate, pe baza nivelului de precedenţă. Şi aici este treaba routerului de ingress să marcheze traficul cu clasa necesară şi nivelurile de precedenţă corespunzătoare. De exemplu, routerul de ingress pot marca pachetele cu nivele diferite de precedenţă, bazându-se pe nivelul de conformanţă al acestora pe nivelul de SLA – service level agreements. Trebuie menţionat faptul că grupul PHB este un set de reguli de routare aplicate pe fiecare router, iar ele singure nu oferă nicio garanţie pentru QoS de tip end-to-end. Este posibilă asigurarea de QoS end-to-end într-un domeniu DiffServ prin concatenarea routerelor cu acelaşi PHB şi limitarea ratei la care pachetele sunt submise pentru un PHB. De exemplu, concatenarea de PHB-uri de tip EF pe o rută pre-specificată, cu controlul admisiei, poate duce la un serviciu similar cu un circuit virtual de telefonie. Alte agregări de PHB pot duce la un bit rate propice transmisiei video…etc.

Figura 4.8. DiffServ şi DSCP

Deşi îi lipseşte nivelul de siguranţă şi granularitatea oferită de IntServ, sistemul DiffServ oferă un nivel ridicat de QoS care este scalabil şi uşor de implementat. Mecanismele DiffServ sunt folosite pe core-le IP. Este posibilă construirea unei reţele din regiuni IntServ la capetele reţelei şi cu DiffServ în interiorul ei, pentru a obţine avantajele furnizate de fiecare arhitectură. În acest caz, semnalizarea IntServ, definirea serviciului şi controlul admisiei sunt menţinute, cu toate flluxurile mapate pe câteva clase DiffServ la hotarele dintre margini şi centru. Din punctul de vedere al IntServ, tot core-le DiffServ este tratat ca un singur link logic, realizat prin tunelarea întregului trafic IntServ prin core-le de DiffServ.

3.      MPLS

MPLS a fost realizat pentru îmbunătăţirea performanţelor reţelelor IP. El a fost dezvoltat iniţial ca o metodă de îmbunătăţire a vitezei de forwardare a routerelor, dar acum este folosit pe post de mechanism separat care oferă servicii diferenţiate. MPLS permite şi mai buna integrare de IP şi ATM, îmbunătăţind performanţele IP peste reţelele ATM. Ideea de bază din spatele MPLS este inserarea între nivelul 2 şi header-ul IP a unui pachet de lungime fixă, un “label” care poate fi folosit ca şi scurtătură pentru felul în care pachetul trebuie să fie tratat în reţeaua MPLS. 

            Figura 4.9. Reţea MPLS

Într-o reţea MPLS, pachetele nu sunt routate conform headerului IP, ci sunt forwardate folosind numai informaţia din acest label. Figura de mai jos arată componentele unei reţele MPLS. Routerul de ingress al unei reţele MPLS este numit LER – Label-Edge Router şi este responsabil pentru inserarea acestui label în pachetele care intră în reţea şi maparea pachetului pe o clasă de echivalenţă de forwardare FEC. Toate pachetele care aparţin unui FEC sunt routate pe aceeaşi cale, numită LSP – Label Switched Path şi primesc acelaşi tratament QoS. Calea LSP este fixă înainte de transmiterea datelor pe bază de configuraţii manuale sau folosind protocoale de semnalizare. Routerele intermediare, numite LSR – Label Switching Routers, menţin o bază de informaţii de forwardare FIB – Forward Information Base şi forwardează pachetele MPLS uitându-se la următorul hop din FIB. Acest label are numai importanţă locală şi este înlocuit de către LSR cu un nou label pe măsură ce pachetele sunt forwardate de la un nod la altul pe LSP. Acest sistem este asemănător identificatorului de cale virtuală sau circuit virtual – VPI/VCI din ATM. Defapt, switchul ATM poate fi folosit pe post de LSR, iar labelul este acest VPI/VCI. Mutarea şi forwardarea labelului continuă până în momentul în care pachetul ajunge la routerul egress, unde labelul este şters înainte ca pachetul să fie trimis până la un nod non-MPLS. Având căi predeterminate, sistemul MPLS măreşte rapiditatea procesului de forwardare, cu singurul cost al necesarului suplimentar de procesare la routerul de hotar, cel care converteşte pachetele IP în pachete MPLS. Acest sistem poate fi folosit şi pentru a uşura congestiile de trafic. Spre deosebire de reţelele tradiţionale IP care rutează traficul automat pe calea cea mai scurtă, MPLS poate ruta pe anumite căi determinate care balansează încărcarea anumitor link-uri, routere sau noduri din reţea. Alături de protocoale de semnalizare ca RSVP-TE sau LDP-CR, este posibilă calcularea căilor cu o varietate mare de condiţii şi rezervarea resurselor în mod corespunzător. Managementul dinamic al traficului permite reţelei să opereze la o eficienţă ridicată. Este posibilă deasemenea realizarea de căi speciale pentru anumite aplicaţii – de exemplu setarea de circuite dedicate prin configurarea de căi LSP permanente pentru traficul de voce sau aplicaţiile VPN. Deşi nu este în sine un mecanism de QoS de tip end-to-end, MPLS realizează o infrastructură peste care poate fi implementat mecanismul de QoS dorit. Atât IntServ, cât şi DiffServ pot fi implementate peste MPLS, deşi MPLS-DiffServ este mai des întâlnit. Sistemul MPLS nu respectă principiul de adresare end-to-end al protocoalelor IP şi pune controlul reţelei în mâna administratorului acelei reţele. 

4.7 Managementul mobilităţii

            Pentru a permite unui subscriber să comunice din diferite locaţii în timp ce se deplasează au fost dezvoltate 2 mecanisme. În primul rând, pentru transmiterea pachetelor către subscriberul mobil trebuie să existe un mechanism de localizare a staţiilor mobile, inclusiv a celor inactive, la orice moment, indiferent de localizarea lor în reţea. Acest proces de identificare a locaţiei curente a unui Mobile Station, punctual de ataşare în reţea, se numeşte location management. În al doilea rând, pentru menţinerea unei sesiuni continue în timp ce MS se deplasează prin reţea de la un Base Station la altul, este necesar un mecanism de tranziţie sau de hand off. Setul de proceduri pentru managementul tranziţiei este numit handoff management, iar conceptele de location şi hand off management constituie mobility management.

            Location management implică două procese. Primul proces este numit location registration sau location update, în care un MS informează în periodic reţeaua asupra locaţiei lui curente, care face reţeaua să autentifice utilizatorul şi să actualizeze profilul locaţiei sale în baza de date. Bazele de date sunt în mod normal localizate în zone centralizate din reţea. Locaţia aceasta este în mod normal identificată de o arie care cuprinde aria de acoperire a uneia sau mai multor Base Stations. Realizând o arie de localizare largă se reduce numărul de update-uri de locaţie care trebuie realizate. Ştiind că orice MS, inclusiv acele MS inactive, trebuie să raporteze reţelei de fiecare dată când se mută dintr-o locaţie de acoperire a unui BS către altă locaţie, are loc un load de semnalizare inacceptabil în reţea, mai ales când BS-urile sunt microcelule, iar numărul de subscriber este foarte mare. Pentru a micşora această încărcare, furnizorii de servicii defines de obicei arii de localizare mai largi care acoperă câteva BS-uri. Frecvenţa actualizărilor de locaţie este deasemenea important. Dacă acest fenomen apare rar, sistemul MS riscă să îşi modifice locaţia curentă fără ca reţeaua să fie notificată în vreun fel anume, ceea ce duce la inconsistenţa informaţiei de localizare despre acel dispozitiv mobil. Pentru a suporta roaming global, managementul locaţiei trebuie făcut nu numai în reţeaua unui singur operator, dar şi în reţelele vecine, participante ale contractului de roaming.

            Al doilea proces implicat în managementul locaţiei este numit paging. În momentul în care are loc o cerere de iniţiere de sesiune, cum ar fi un call care ajunge în reţea, se realizează o căutare în baza de date de locaţii pentru a determina locaţia curentă a receptorului, apoi se paginează toate BS-urile din aria subscriberului şi din jurul acesteia. Binenţeles, cu cât numărul de BS-uri dintr-o anumită aria de localizare este mai mare, cu atât resursele de paginare ale reţelei sunt mai mari. Operatorii de reţea trebuie să facă un compromis între a folosi resursele pentru semnalizarea actualizării locaţiei de către toţi MS, versus paginarea pe o arie mai largă.

            Prin comparaţie cu managementul locaţiei, managementul de hand off are cerinţe de performanţă real-life mai restrictive. Pentru multe aplicaţii, precum sunt cele de VoIP, procesul de hand-off trebuie să fie insesizabil la nivel de delay sau packet loss. Pentru a susţine aceste aplicaţii, WiMAX are cerinţa de mobilitate completă (full mobility) – până la 120kmph – latenţa de hand off trebuie să fie mai mică de 50ms cu un packet loss mai mic de 1%. Procesul de hand off poate fi descris în 2 faze. În prima fază, sistemul detectează cerinţa de hand off şi ia decizia transferului către alt BS. În a doua fază are loc hand off-ul efectiv, asigurând faptul că MS-ul şi BS-urile implicate sunt sincronizate şi toate pachetele sunt livrate în mod correct, folosind protocoalele potrivite. Deciziile de hand off pot fi luate de către MS sau de către reţea, pe baza metricilor de calitate a link-ului. În WiMAX, MS-ul ia decizia finală, iar BS-ul doar face o recomandare sau candidează la statutul de staţie de bază destinaţie pentru hand-off, decizia bazându-se pe măsurătorile de calitate a semnalului colectate şi raportate periodic de către MS. Acesta ascultă un semnal de control de la toate staţiile de bază din apropiere în raza lui de acţiune şi măsoară calitatea acestui semnal. În WiMAX, staţia de bază poate să ajute staţia mobilă în acest proces, furnizându-i acesteia o listă cu staţiile de bază vecine şi parametrii asociaţi pentru scanarea acestor staţii. Pentru acest proces se ia în calcul parametrul RSS – Received Signal Strength sau SINR – Signal-to-Interference plus Noise Ratio. SINR este o unitate de măsură mai bună pentru celulele cu o densitate mare, dar este mai greu de calculate decât RSS. Figura de mai jos arată un caz simplu care implică două staţii de bază şi o staţie mobilă care se deplasează de la staţia de bază A (serving base station) spre staţia de bază B (target base station).

                        Figura 4.10. Detectarea hand-off pe baza puterii semnalului

Nivelul minim de semnal MSL – Minimum Signal Level este punctul cel mai de jos la care calitatea link-ului devine inacceptabilă şi, în absenţa procesului de hand-off, ar duce la pierdere excesivă de pachete şi la întreruperea sesiunii. Valoarea MSL poate varia, în funcţie de tipul particular de QoS cerut de aplicaţia din acea sesiune. De exemplu, o aplicaţie cu cerinţe mari de throughput poate avea o valoarea MSL acceptată mai mare decât o aplicaţie cu rată mică de date. Procedurile de hand-off sunt iniţiate în momentul în care semnalul scade sub un nivel acceptat, considerat de “x” ori mai mare decât acest MSL. Deasemenea, procesul de hand-off are loc numai dacă în apropiere se găseşte un alt BS pentru care puterea semnalului este de “x” ori mai mare decât valoarea MSL. Folosind un factor “x” de multiplicare mai mare va minimiza posibilitatea ca semnalul să scadă sub MSL pe durata procesului de hand-off.

            Un algoritm de hand-off performant ar trebui să minimizeze eşecurile de hand-off şi să evite procesele de hand-off inutile. Două metrici sunt folosite cel mai adesea pentru determinarea performanţei algoritmilor de hand-off: dropping probability şi handoff rate. Primul indicator măsoară numărul de eşecuri de hand-off care are loc în momentul în care semnalul scade sub MSL pentru o anumită durată de timp. Rata de hand-off măsoară frecvenţa deciziilor de hand-off, care depind parţial şi de cât de frecvent au loc şi sunt raportate măsurătorile către reţea. Măsurătorile consumă resurse radio şi reduc capacitatea disponibilă. Pentru a minimiza probabilitatea de aruncare a pachetelor, procedurile de hand-off trebuie să aibă loc rapid, iar valoarea factorului de multiplicare a MSL trebuie setată mai mare, pentru a micşora şansele ca puterea semnalului să scadă sub MSL. Totuşi, setarea unui factor prea mare implică un cost de design a celulei mai mare, cu un necesar de suprapunere a celulelor mai mare. Decizia prea rapidă de hand-off poate duce la realizarea inutilă şi excesivă a acestui proces, mai ales în momentul în care sunt fluctuaţii mari de semnal; avem de a face cu un compromis între probabilitatea de aruncare a pachetelor şi rata de hand-off. Folosirea prea rară a acestui proces poate duce la terminarea conversaţiilor, iar prea multe procese de hand-off cauzează overloadul de semnalizare şi degradează calitatea serviciului. Natura acestui compromis este determinată de modelul de fluctuaţie al semnalului şi de algoritmul de decizii de hand-off. Tabelul alăturat ilustrează compromisul între cei doi factori pentru trei algoritmi care îşi bazează deciziile de hand-off pe valori instantanee ale nivelului de semnal (1), pe nivelul de semnal mediu din ultimele 10 interogări (2), respectiv pe valoarea de semnal aşteptată (3). Aceste rezultate se bazează pe simulări MatLab ale unui MS care se deplasează cu 20m/s de la un BS la altul, la distanţă de 1km. S-a folosit o descompunere exponenţială şi o slăbire logaritmic normală cu corelarea distanţei de 50m. Mostrele de semnal s-au luat la 0.5s.

 Tabelul 4.1. Compromis între probabilitatea de aruncare şi rata de hand-off

Selectând un BS pe baza valorii instantanee cea mai puternică oferă cea mai bună valoare pentru probabilitatea de aruncare, cu costul unui număr mare de procese de hand-off. Pe de altă parte, luând decizii de hand-off pe baza valorii aşteptate duce la mărirea probabilităţii de aruncare de pachete, deşi ţine numărul de procese hand-off la minimum. Este dificilă realizarea unui model de slăbire care să se potrivească tuturor tipurilor de medii. O altă metodă comună, folosită pentru minimizarea proceselor de hand-off în timpul condiţiilor dificile de slăbire de semnal este construirea unui sistem nedeterminist în acest algoritm. În momentul în care are loc procesul de hand-off de la staţia A la staţia B, nivelul de hand-off pentru iniţierea unui hand-off înapoi de la B la A este setat la o valoare superioară. Luarea deciziei de hand-off trebuie să ia în considerare şi faptul că resursele radio sunt disponibile la target BS pentru a se realiza sesiunea. Pentru a minimiza riscul de întrerupere a sesiunilor din cauza lipsei de resurse pe target BS, unele arhitecturi de sistem pot rezerva o parte din resursele reţelei numai pentru acceptarea sesiunilor de hand-off, cărora li se acordă de multe ori prioritate din perspectiva controlului admisiei. Furnizarea de rezervare de resurse şi prioritizare pentru sesiunile de hand-off consumă resurse radio şi scade eficienţa spectrală. O abordare mai bună, mai ales pentru proiectele cu o densitate mare, în care e cel puţin un candidat BS pentru a primi un anumit hand-off, este de a incorpora informaţia despre resursele radio în decizia de hand-off. Prin realizarea unei scheme care favorizează staţiile de bază cu o anumită calitate a semnalului şi mai multe resurse disponibile în faţa celor cu cea mai bună calitate a semnalului, dar cu resurse limitate, este posibilă rezolvarea problemei pierderii de pachete în eficienţa spectrală. În WiMAX, staţiile de bază îşi pot prezenta resursele disponibile între ele ăe backbone, iar acest fapt poate fi folosit pentru a ajuta staţia mobilă în selectarea celei mai potrivite staţii de bază pentru handover. În momentul în care este luată decizia de a face hand-off pentru o sesiune către un target BS, trebuie urmaţi un număr de paşi pentru a realiza cu succes acest proces. Aceşti paşi presupun stabilirea conectivităţii fizice cu un nou BS – ranging, sincronizare, achiziţie de canal…etc – realizarea funcţiilor de securitate necesare pentru reasocierea la un nou BS şi transferarea stării MAC-ului de la vechiul BS către noul BS. Pentru a face procesul de handover transparent, rapid şi fără erori, sunt câteva mecanisme care pot fi implementate. Realizarea procedurii de ranging iniţial şi sincronizare cu staţiile de bază vecine înainte de a face hand-off este unul dintre aceste mecanisme; stabilirea conexiunilor la nivel fizic cu mai mult de un BS la un moment dat, astfel încât transferul de date să se poată face fără a executa toată procedura de handoff este un alt mecanism. IEEE 802.16e-2005 are suport pentru această funcţionalitate, numită FBSS (fast base station switching). În acest caz, dacă toate staţiile de bază cu care staţia mobilă are o conexiune primesc pachete de downstream de la reţea destinate acelui MS, se poate reduce semnificativ pierderea de pachete. Un al treilea mecanism este transferul tuturor pachetelor de nivel 2 nelivrate în cozile de la vechiul BS către noul BS pe backbone, pentru reducerea pierderii de pachete sau pentru a satisface cerinţele de retransmisie de la nivelele superioare. Transferul stărilor ARQ de la nivelul MAC către staţia de bază destinaţie poate reduce deasemenea retransmisiile de la nivelul 2.

             Mobile IP

            Întreaga teorie despre managementul mobilităţii a plecat de la premisa că, în momentul în care un MS se mută din aria de acoperire a unui BS către alt BS, tot ceea ce trebuie să menţină este conexiunea fizică, pentru ca pachetele să poată circula. Aceasta însă nu este suficient. Pentru ca o sesiune de aplicaţie să rămână intactă, adresa IP a staţiei mobile trebuie să rămână neschimbată pe durata acelei sesiuni. Dacă întreaga reţea wireless ar fi construită pentru a aparţine unui aceluiaşi subnet, adresa IP a staţiei mobile ar putea să rămână neschimbată. Pe o arhitectură plată, staţia de bază acţionează ca un router IP, iar mutarea către un alt BS ar însemna schimbarea adresei IP. Chiar şi în momentul în care o staţie de bază nu este configurată să fie router IP, o staţie mobilă se poate muta între staţii de bază care fac parte din subnet-uri diferite: acesta este cazul de mutare între două reţele de acces în WiMAX. În momentul în care se întâmplă acest lucru, adresa IP a staţiei mobile trebuie să se schimbe, conexiunea IP de până în acel moment care, iar sesiunile care urmează sunt terminate, deşi conectivitatea fizică pe aer este păstrată. Mutarea către un alt subnet mai are loc la întâlnirea unor reţele eterogene:  la mutarea din reţele WiMAX către reţele Wi-FI sau către reţele celulare 3G. De aceea este necesară o soluţie pentru menţinerea intactă a sesiunii chiar şi în momentul în care un MS schimbă subnetul. Mobile IP (MIP) este soluţia propusă de IETF pentru managementul mobilităţii la nivel IP. Acest sistem este realizat ca o soluţie suprapusă peste IPv4, pentru suportul mobilităţii utilizatorilor de la un subnet la altul. Cerinţa este ca MIP să fie transparent pentru aplicaţie, în sensul că aceasta nu trebuie să ştie că utilizatorul a schimbat subnetul. MIP este deasemenea transparent pentru reţea în ideea că protocoalele de rutare sau routerele nu trebuie schimbate.

            Clientul de MIP este implementat în terminalul care se deplaseaza (MS în WiMAX) şi este numit mobile node (MN). Hostul IP cu care nodul mobil comunică este numit CN – correspondent node. MIP defineşte două adrese pentru fiecare MN. Prima adresă, dată nodului mobil de către reţeaua sa mamă, este numit home address – HoA; acest IP identifică nodul către reţeaua IP. A doua adresă, numită care-of address – CoA, este un IP temporar atribuit nodului mobil de către reţeaua vizitată; acest IP oferă informaţii despre locaţia curentă a nodului mobil.

            Pentru managementul mobilităţii este nevoie de mapare dinamică între identificatorul IP fix-HoA şi CoA. Această cerinţă este satisfăcută prin folosirea agentului mobil, numit home agent – HA, localizat în reţeaua-mamă, alături de un alt agent mobil, numit foreign agent – FA, localizat în reţeaua vizitată. Ambii agenţi mobili pot fi consideraţi nişte routere specializate. Există şi obţiunea colocalizării agentului mobil FA în nodul mobil MN, scenariu denumit colocated foreign agent. Adresa CoA a MN este adresa agentului străin FA. De fiecare dată când un nod mobil îşi părăseşte reţeaua-mamă şi se găseşte într-o reţea vizitată, această deplasare este detectată prin utilizarea protocoalelor de location-discovery, agenţii mobili publicându-şi prezenţa pentru a facilita detectarea nodurilor mobile. În momentul în care se află într-o reţea vizitată, nodul mobil obţine o nouă adresă şi trimite un mesaj de update către HA, spunându-i noua adresă a FA. Această actualizare se poate face direct de către MN pentru un CoA colocat sau este trecută prin FA dacă adresa din subreţeaua vizitată a lui FA este folosită ca şi CoA.

            Figura 4.11. Componentele Mobile IP

            În momentul în care sistemul HA este actualizat cu noua adresă CoA, toate pachetele destinate acelui nod mobil care ajung în reţeaua de bază sunt trimise către adresa de CoA a agentului străin FA prin încapsularea lor într-un protocol de tunelare. Încapsularea IP-în-IP este descrisă în RFC 2003 şi este folosită ca şi protocol de tunelare. Sunt suportate şi protocoalele Minimal Encapsulation (RFC 2004) şi GRE – Generic Routing Encapsulation (RFC 1701). Agentul străin FA deîncapsulează pachetele şi le trimite către MN; adresa de bază HA acţionează ca un punct de legătură pentru toate pachetele destinate nodului mobil MN, IP-ul mobil fiind capabil să trimită toate pachetele către MN indiferent de locaţia acestuia. Mobile IP este necesar numai pentru trimiterea pachetelor destinate nodului mobil MN, pachetele care pleacă de la MN pot fi trimise direct la destinatar, fără a necesita utilizarea mecanismului de Mobile IP, cu excepţia cazului în care sistemul CN este deasemenea mobil (în acest caz pachetele trebuie să treacă prin adresa HA a CN). Pachetele adresate sistemului MN au altă cale decât cele cu sursa MN. Acest procedeu este numit triangular routing, el fiind unul din punctele slabe ale arhitecturii de Mobile IP.

            Figura 4.12. Rutare triangulară

Limitări şi soluţii

Mobile IP are mai multe limitări, cele mai multe datorate folosirii sistemului de routare triangulară, care este o soluţie de management de mobilitate suboptimă. Limitările principale sunt următoarele: routarea ineficientă – routarea triangulară poate irosi resurse, mai ales dacă utilizatorul mobil se deplasează către o locaţie care se află departe de reţeaua-mamă. De exemplu, dacă o persoană care are o reţea-mamă în US ar accesa un site web din Coreea, cât timp ea se află în Europa, pachetele de la site-ul web din Coreea ar trebui să ajungă în agentul de bază HA din US înainte de a fi tunelate şi livrate înapoi în Coreea. O soluţie propusă pentru această problemă este extensia opţională a Mobile IP, numită route optimization – optimizare de rute, care permite sistemului CN să trimită pachete direct către MN, ca răspuns la o actualizare de legături – binding update din partea HA-ului, informându-l pe CN asupra noii adrese CoA a sistemului MN. Implementarea extensiei de optimizare de rute implică însă modificări pe stack-ul CN, care nu sunt practice în multe scenarii.

O altă limitare este reprezentată de problemele de filtrare la intrarea în reţea – ingress filtering issues. Multe sisteme firewall nu acceptă pachetele care vin spre reţea de la o adresă sursă incorectă din punct de vedere topologic. De moment ce sistemul MN îşi foloseşte adresa din reţeaua-mamă ca adresă-sursă chiar şi în momentul în care se găseşte în reţeaua vizitată, sistemel firewall din reţeaua vizitată pot arunca pachetele venite de la aceste noduri mobile. O soluţie pentru această problemă este aceea de reverse tunneling, o altă extensie opţională la Mobile IP. Această soluţie necesită ca nodul mobil să stabilească un tunel de la adresa CoA la HA, unde să fie deîncapsulat şi trimis către sistemul CN corect.

Figura 4.13. Reverse tunneling

Problemele legate de adresele private sunt deasemenea o limitare. Arhitectura Mobile IP nu permite adresarea privată şi NAT-ul. Cum pachetele sunt tunelate de la HA (sau CN, în cazul optimizării de rute), folosind încapsularea IP-în-IP până la adresa publică rutabilă a nodului mobil (anume CoA), un server de NAT nu ar putea să translateze această adresă în CoA, de moment ce numărul portului este pierdut. O soluţie propusă este folosirea încapsulării IP-în-UDP, unde headerul UDP poate purta şi informaţia despre numărul portului. O altă problemă este limitarea numărului de adrese IPv4. Arhitectura Mobile IP necesită ca fiecare nod mobil MN să primească o adresă de bază permanentă. În reţeaua vizitată, acest nod poate primi o adresă asignată prin DHCP sau o adresă privată, dacă există un FA în reţea care se poate conecta la diverse mobile. În cazul unui FA colocat, fiecare nod mobil va avea nevoie de o adresă IP publică unică, de moment ce va trebui să deîncapsuleze un tunel IP-în-IP. Mai mult, un FA colocat va avea dezavantajul de a avea un tunel pe wireless, care introduce un overhead mare.

Nevoia de FA: Pentru că un FA este necesar susţinerii sistemului de Mobile IP, se cere ca fiecare reţea în care se deplasează nodul mobil să aibă un FA, iar acest FA să aibă o relaţie de încredere cu HA, fapt greu de realizat în practică. Alternativa – folosirea unui FA colocat pe MN are dezavantajul nevoii de IP public rutabil, creând overhead pe wireless şi încetinind procesul de handover. Pierderea informaţiei de QoS – tunelarea folosită în Mobile IP poate pune probleme implementării de QoS. De moment ce headerele pachetelor IP care furnizează QoS pot fi ascunse în tunel, routerele intermediare pot să nu implementeze cerinţele de QoS din pachetul tunelat. Alte situaţii pot apărea în cazul aplicaţiilor IP. De moment ce traficul trimis către un MN trebuie să fie tunelat individual, se pune problema realizării scenariilor de multicast, la fel ca şi cea a caching-ului web. Web caching se poate face numai în afara tunelului, de aceea utilizarea Mobile IP poate reduce flexibilitatea operatorilor în termeni de funcţionarea a sistemelor de caching. Mobile IP necesită notificarea HA-ului de fiecare dată când terminalul se mută de la un subnet la altul. Aceasta poate crea un overhead de semnalizare, mai ales când mutările au loc des: mutări între o microcelulă BS, cu HA-ul localizat departe de reţeaua vizitată. Această problemă poate fi rezolvată prin folosirea unui proxy local de mobilitate, astfel încât mesajele de semnalizare să rămână locale. De moment ce un nod mobil trebuie să notifice pe HA că şi-a schimbat adresa CoA, procesul de handover de la o reţea la alta poate fi încetinit, mai ales când HA-ul se găseşte departe de reţeaua vizitată. Procesul de handover poate duce şi la pierderea pachetelor deja aflate în tranzit care sunt livrate cu adresele anterioare.

Deşi furnizează un mecanism de a trimite pachetele IP la un dispozitiv care se deplasează de la o reţea la alta, sistemul Mobile IP de unul singur nu este suficient pentru a avea o sesiune continuă. Mobile IP a fost conceput ca soluţie pentru macromobilitate, unde procesele de handover sunt rare, iar trecerea neobservabilă de la un BS la altul nu este o cerinţă atât de pretenţioasă în termeni de calitatea serviciului. Există limitări pentru cazul aplicaţiilor care necesită un handover neobservabil. Cu toate acestea, au fost realizate mai multe soluţii pentru a rezolva aceste limitări.

Tags: interesant, passion, security